This chapter diagrams and describes common use case request and response flows.
The figure below illustrates a sample flow with a description of each request from the browser to the back end application. This flow is taken from the Tutorial With WordPress. Try the tutorial yourself to learn how OpenIG works. The Flat-File attribute store contains only one set of credentials. OpenIG makes the assumption this user is logging into the sample application. In a real deployment OpenIG would look up the user credentials using its own session, a SAML2 assertion, or a header from an OpenAM policy agent. Use cases that follow show examples of these types of deployments.
User accesses the Portal.
Gateway intercepts request, finds no login page and passes it through.
Portal finds no local session and redirects to its login page for authentication.
Gateway intercepts the redirect, finds a match for the login page, fetches the credentials from the flat file.
Gateway creates the login form and POSTs it to the Portal login page.
Portal validates the credentials and redirects to the user's home page.
Gateway passes the request through to the browser.
The figure below illustrates OpenIG integrated into an OpenAM deployment. In this deployment OpenIG is running in a container that is protected by an OpenAM policy agent. The agent is configured to forward a header, with the subject (user) of the single sign-on session, to OpenIG. OpenIG then uses the subject as the login credentials, or uses the subject as a reference to look up the login credentials in a database or directory. The HR application is integrated into the SSO deployment without an agent or any modification to the application or its deployment configuration.
User browses to the Portal.
OpenAM plugin intercepts the request, finds no valid OpenAM session, redirects the user to the OpenAM login pages.
OpenAM logs in the user and redirects back to the Portal.
OpenAM plugin finds a valid session, request goes through, OpenIG passes the request through to the Portal.
Portal finds no local session, redirects to the Portal login page.
OpenIG inspects the redirect, finds a match for the login page, creates the login form, and POSTs it to the Portal.
Portal validates the credentials and redirects to the Portal page.
Gateway passes the request through to the browser.
The figure below illustrates the OpenIG Federation Gateway providing SAML2 endpoint features acting as Service Provider in an SP initiated single sign-on configuration. In this sample, company myHR is an outsourced provider of HR services and has started seeing increased demand for SAML2 support in their core application. The companies to which they outsource are refusing proprietary means of authentication and demanding the widely accepted SAML2 standard. myHR is not in a position to modify their application to support SAML2 nor do they have the time or money to integrate and deploy all of OpenAM. With OpenIG Federation Gateway, myHR deploys OpenIG in front of their HR application, configures it as a SAML2 endpoint for SP initiated SSO, and configures it to log users into the HR application upon successful verification of the SAML2 assertion from their customers.
The user accesses the HR application through a bookmark in the browser.
Federation Gateway inspects the request, no match is found for the HR application's login page so the request goes through.
HR application finds no HR session, sends a redirect to its login page.
Federation Gateway intercepts the redirect, finds a match for the login page, issues an SP initiated SSO SAML2 request to Company.com's IDP.
The IDP at Company.com receives the SAML2 AuthN request and authenticates the user.
After authenticating the user the IDP sends a SAML2 POST to OpenIG.
Federation Gateway validates the assertion and makes the assertion attributes available to the OpenIG login chain.
OpenIG login chain gets the user credentials and POSTs the login form to the application.
The HR application verifies the credentials and redirects to its home page.
The figure below illustrates the Federation Gateway providing SAML2 endpoint features acting as a Service Provider in a IDP initiated single sign-on configuration.
User clicks the HR link on the company portal and is redirected to the company IDP for authentication.
IDP sends an AuthN Response to the HR application.
Federation Gateway receives the POST, validates the assertion, and makes the attributes available to the OpenIG login chain.
OpenIG login chain retrieves the user credentials and POSTs the login form to the myHR application.
HR application validates the credentials and redirects to the main page of the application.
The figure below illustrates the Federation Gateway as a standards based replacement for OpenAM policy agents.
The user accesses an internal Payroll application.
Federation Gateway inspects the request, no match is found for the Payroll application's login page so the request goes through.
Payroll application finds no Payroll session, sends a redirect to its login page.
Federation Gateway intercepts the redirect, finds a match for the login page, issues an SP initiated SSO SAML2 request to OpenAM at Company.com.
OpenAM at Company.com receives the SAML2 AuthN and authenticates the user.
After authenticating the user OpenAM sends a SAML2 POST to OpenIG.
Federation Gateway validates the assertion and makes the assertion attributes available to the OpenIG login chain.
OpenIG login chain gets the user credentials and POSTs the login form to the application.
The Payroll application verifies the credentials and redirects to its home page.