...
The SAML Single SignOn protocols exchange data between the Application and Shibboleth through the Browser. We do not use the protocols where the Application talks to Shibboleth directly.The simplest Shibboleth SSO solution is what is called
IdP Initiated Logon
About 95% of the applications that use Shibboleth support "IdP Initiated" (that is, Shibboleth sends an unsolicited login SAML message to the application). The user triggers this by sending clicking on a link or pasting a URL into the Browser logon, where the Browser starts with a URL that points to Shibboleth and Shibboleth sends a SAML Response unsolicited to the Application. The starting URL is of the form:
https://auth.yale.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=nobody.yale.edu
This URL points directly to a Shibboleth instance, which could be auth, auth-test, auth-dev, or localhost:8080 in the Sandbox. The string after the providerId= parameter is the entityId string for the application. Shibboleth searches the attribute-filter.xml for attributes released to that entityId, and it searches the Metadata for a definition of that entityId. It then generates a SAML login and sends it to the configured default AssertionConsumerService URL in the Metadata. The Metadata must exist and the hostname in the AssertionConsumerService URL must exist on the network in order for Shibboleth to generate and attempt to send the SAML.
The other approach is that the user can go to an application that has been configured with a URL of Yale Shibboleth. Typically the user selects from a pulldown list or presses a button, although some applications simply redirect back to Shibboleth immediately. The application sends a SAML Request, and there are two ways that Request can be transmitted. Both involve sending data to the Browser, and then having the Browser forward that data to the configured Shibboleth URLWhen the Browser generates a GET to this URL, the handler for profile/SAML2/Unsolicited/SSO searches the Metadata files for an EntityId that matches the value in the providerId at the end of the URL. There has to be a matching Metadata to supply the URL of the AssertionConsumerService to which the login will be sent, and the hostname in the ACS URL has to exist. Shibboleth also searches the attribute-filter.xml for a policy that releases attributes to this EntityId. It then builds a SAML Response message with the released attributes, writes it to a Form on the Browser screen where JavaScript submits the form and sends everything on to the ACS URL.
The first thing the Application sees is a Form POST to the ACS URL containing the SAML Response as data. This Response will have been generated and digitally signed by the Shibboleth you sent the IdP Initiated URL to in the first place. It could be auth, auth-test, auth-dev, or localhost:8080 in the Sandbox. If the Application has not been configured to trust the Shibboleth that generated the message, it will generate an error message and fail to log you on. However, if you have been tracing the HTTP messages in the Browser, you will have captured the SAML message sent to the application. You can display it and verify that the Attributes and Subject are correct for that particular Application, and that is 99% of the testing you typically need to do.
SP Initiated Login
The user can start by going to the application. A Browser that starts with "yale.service-now.com", "yale.box.com", "mail.bulldogs.yale.edu", or the Comcast IPTV URL will in some cases get immediately sent to Shibboleth and in some cases will push a button or select Yale University from a dropdown list before being Redirected back to Shib.
Some applications that support SP Initiated also support IdP Initiated. You can test all the attributes and subject and the basic login using IdP Initiated, but when something changes that might affect it, you also have to be sure that when the Application sends a Request to Shibboleth then that Request is accepted.
There are two ways an application can send its Request to Shibboleth:
- (SAML Browser POST Protocol) writes a Form to the screen containing a pre-loaded text box containing the SAML Request, then uses JavaScript to Submit the data to https://auth.yale.edu/idp/profile/SAML2/POST/SSO
- (SAML Browser Redirect Procol) redirects the Brower to "https://auth.yale.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=" followed by the character encoded SAML Request
The Browser (and therefore your computer) is always in the middle
So the three options are:
...