Web Authentication

Web apps in the UABgrid environment rely on a web single sign-on for their authentication. This framework uses the Shibboleth software components to implement a SAML attribute exchange to allow fine-grain access control decisions for web apps.

We'll use the galaxy web app as an example in these scenarios.

There are two redirect scenarios that occur when accessing the galaxy web app.

1. The user has an active web sso session in their browser but no active session with the galaxy web app:
   1. The browser accesses the galaxy web app via an HTTP GET will result in a connection to https://galaxy.uabgrid.uab.edu/ (the desired target).
   2. The lack of an application session cookie is detected (by mod_shib) causing an HTTP 302 response redirect to the client browser that points to the login service at https://vo.uabgrid.uab.edu/shibboleth-idp/SSO.
   3. The browser does an HTTP GET to vo where the mod_shib service protecting the IdP recognizes the existing web sso session. It let's the request pass through to the shibboleth IdP which creates a new authn handle for the galaxy app and returns a special page to the browser (a 200 response).
   4. The response page contains a bit of javascript which causes the browser to POST this authn handle to galaxy app.
   5. The user browser POSTS to https://galaxy.uabgrid.uab.edu/Shibboleth.SSO/SAML/POST. The POST is processed by mod_shib and causes the shib daemon on the galaxy host to perform a callback to https://vo.uabgrid.uab.edu:8443/shibboleth-idp/AA. This is a SAML packet exchange with vo, where the authn handle is passed back to vo.uabgrid which verifies it an releases attributes to the application (user, email, and groups in our config). The application session is populated with the returned attributes and an associated app session cookie is set in the browser with a final redirect back to the original application URL
   6. The user browser repeats the original GET request (https://galaxy.uabgrid.uab.edu/) but now has a valid app session cookie in the browser. Now the request is processed and if the user has the correct identity or other attributes they are allowed into the galaxy web app. At this point, all subsequent requests to the web app process the app session cookie from the browser directly without any further redirects (until the app session expires).
2. The user does not have an active web sso session in their browser and no active session with the galaxy web app. This repeats the sequence of steps in scenario 1, but this time without the active web sso session the user browser is directed to further authenticate at step 1.3 above. The following steps describe the additional redirects that occur at this point:
   1. The browser does an HTTP GET to vo where the mod_shib service detects the lack of a web sso session. Mod_shib responds with a redirect to the browser, initiating authentication. At this point, authentication is provided by UABgrid's participation as an application in InCommon. So the user browser is redirected to the discovery service that let's the end user select which identity they want to use for login.
   2. The browser redirects to https://apps.uabgrid.uab.edu/login which prompts the user with choices for an identity provider to use for this session. (It is possible that the user is automatically redirected to a pre-selected identity provider if they have this setting cached in their browser.)
   3. Selecting an identity provider redirects the user to that identity provider. In cases where this is UAB, the browser is redirected to https://shib.dpo.uab.edu/shibboleth-idp/SSO. This triggers a repeat of steps 1.3 and 1.4, except now with UAB's Shibboleth and Web SSO infrastructure. That is, shib.dpo.uab.edu determines if an active session exists and if not redirects the user to https://cas.dpo.uab.edu where they are prompted for their BlazerID and password. After successful authentication, they are redirected to back to shib.dpo.uab.edu, which sets up an app handle for UABgrid and directs the browser to POST the response to https://vo.uabgrid.uab.edu/Shibboleth.SSO/SAML/POST.
   4. After the POST we return to the sequence in scenario 1, completing the same actions as in steps 1.4 through 1.6.