(Describe initial sequence of redirects during login)
Revision as of 10:33, 2 November 2011
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 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).