<div dir="ltr"><div>Scott,</div><div><br></div><div>Thank you.</div><div><br></div><div>This is more like the information that I was looking for.</div><div><br></div><div>Let me do some testing and talk to management...see how they have the project set up.</div><div><br></div><div>Happy New Year!</div><div>Mike</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 29, 2017 at 12:16 PM, Scott Koranda <span dir="ltr"><<a href="mailto:skoranda@gmail.com" target="_blank">skoranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I have set up a new Service Provider that imports the data from our<br>
> remote Identity Provider.  This morning, the team supporting the<br>
> Identity Provider let me know that they had successfully imported the<br>
> Service Provider metadata.<br>
><br>
> So at this point the Service Provider and Identity Providers are<br>
> initially set up and configured.<br>
><br>
> How do I test the operations?<br>
<br>
</span>Browse to<br>
<br>
https://<your server>/Shibboleth.sso/Login<br>
<br>
The path /Shibboleth.sso/Login is a Shibboleth-specific mechanism to<br>
"manually" initiate a Service Provider (SP) session if you do not<br>
already have one.<br>
<br>
Assuming you do not have a valid session, the SP will then consult its<br>
configuration to determine how to initiate a session.<br>
<br>
Most likely you configured shibboleth2.xml so that your SP is only<br>
federated with the single IdP. The SP will then consult the metadata for<br>
that IdP and determine how to redirect your browser to the IdP. It will<br>
then send your browser a 302.<br>
<br>
You should be directed to the IdP and asked to authenticate. After<br>
authenticating your browser will be redirected back to the SP with a<br>
SAML assertion. If the SP successfully consumes the assertion it will<br>
start a new SP session (tracked by a cookie) and redirect your browser to<br>
https://<your server>.<br>
<br>
At that point you should browse to<br>
<br>
https://<your server>/Shibboleth.sso/Session<br>
<br>
and see some details about your session.<br>
<br>
If that all works then you have proven that your SP and the IdP are<br>
federated. Your next step is then to "protect" an "application". An<br>
application can be anything from a simple static web page to a Java<br>
servlet running in Tomcat and proxied by the Apache HTTP Server on which<br>
the SP is running.<br>
<br>
You can then study<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPProtectContent" target="_blank" rel="noreferrer">https://wiki.shibboleth.net/<wbr>confluence/display/SHIB2/<wbr>NativeSPProtectContent</a><br>
<br>
to understand how to protect various types of content. The approach will<br>
depend on the details of the application or content. See also<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication" target="_blank" rel="noreferrer">https://wiki.shibboleth.net/<wbr>confluence/display/SHIB2/<wbr>NativeSPEnableApplication</a><br>
<br>
If the process above does not work, you should<br>
<br>
1) Turn logging up to DEBUG for the SP, restart both shibd and httpd,<br>
and go through the process again. Examine the log files for hints about<br>
what is going wrong.<br>
<br>
2) Install the SAML-Tracer plugin for Firefox and use it to investigate<br>
the flow details to understand where in the flow the error is happening.<br>
<span><br>
> How do we actually use this?<br>
<br>
</span>You will configure some combination of Apache HTTP Server, your<br>
application(s), and Shibboleth SP so that when you attempt to access<br>
content and you do not have a valid SP session the SP will redirect your<br>
browser to the IdP to authenticate.<br>
<br>
The details depend on your application(s).<br>
<span><br>
> My assigned task was to set up a Service Provider...not sure where we<br>
> go from here.<br>
<br>
</span>The above process will determine whether the basic configurations for<br>
the SP and IdP, including SAML metadata, are correct and the SP and IdP<br>
are federated.<br>
<br>
After that the details of how you configure the Shibboleth SP will<br>
depend on the application or content you are protecting and the user<br>
experience you need to support (for example, session lifetime).<br>
<span><br>
> Any links to documentation would be very much appreciated.<br>
<br>
</span>The Shibboleth IdP and SP support the SAML 2 Web Browser SSO Profile.<br>
You should endeavor to understand the basics of that profile.<br>
<br>
See the section "Web Browser SSO Profile" at<br>
<br>
<a href="https://en.wikipedia.org/wiki/SAML_2.0#Web_Browser_SSO_Profile" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/<wbr>SAML_2.0#Web_Browser_SSO_<wbr>Profile</a><br>
<br>
In particular examine "SP Redirect Request; IdP POST Response" and the<br>
diagram<br>
<br>
<a href="https://en.wikipedia.org/wiki/SAML_2.0#/media/File:Saml2-browser-sso-redirect-post.png" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/<wbr>SAML_2.0#/media/File:Saml2-<wbr>browser-sso-redirect-post.png</a><br>
<br>
Once you understand the basics of that profile and have reproduced it<br>
yourself using the SP, the IdP, and the SAML-Tracer plugin, you will<br>
find understanding the Shibboleth SP specific documentation in the wiki<br>
easier to understand.<br>
<br>
Scott K<br>
<div class="HOEnZb"><div class="h5">--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" target="_blank" rel="noreferrer">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Michael NeSmith<br>Senior Linux Administrator<br>Earth Resources Technology, Inc.<br></div></div>
</div>