Web Authentication
https://docs.rc.uab.edu/
Please use the new documentation url https://docs.rc.uab.edu/ for all Research Computing documentation needs.
As a result of this move, we have deprecated use of this wiki for documentation. We are providing read-only access to the content to facilitate migration of bookmarks and to serve as an historical record. All content updates should be made at the new documentation site. The original wiki will not receive further updates.
Thank you,
The Research Computing Team
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.
- The user has an active web sso session in their browser but no active session with the web app.
- 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).
- 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.
- The browser does an HTTP GET to vo where the shibboleth IdP service recognizes the existing web sso session. The shibboleth IdP creates a new authn handle for the galaxy app and returns a special page to the browser (a 200 response). The response page contains a bit of javascript which causes the browser to POST this authn handle to galaxy app.
- 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
- 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).