Members: Join   Log In
« Fake Social Networking Profiles Still Big Problem, But Don't Expect Social Networking Sites to Care | Home | The Great Enterprise 2.0 Smackdown: Round 2 »
Conv Mike Roeder - Oh man, let this be the last of the testing.
Rank_guide 		Primer: SAML and Single Sign On (SSO) for the BSG Platform
belongs to Apps Team  , Architecture Review Team  
by Mike Roeder on Jan 08, 2008 - 11:15 AM read 2310 times 		 

Below find a diagram and detailed description of how the BSG Platform User Service implements Single Sign On (SSO) via SAML Bindings (passive and non-passive)

Non-passive, UI based SSO 

What does 'Non-Passive' mean in this context?

  • Non-passive SSO indicates that the user attempting to sign on to an application (bsgalliance.com or e.laborate, for example) will be provided a user interface in order to sign on. It requires human interaction with a browser.

saml_flow_diagram.gif
(Click image to enlarge)
For detailed API documentation including sample XML please see the BSG Platform User Service API documentation.
  1. A user attempts to login to a Service Provider (for example, bsgalliance.com) by clicking a 'login' link
  2. The Service Provider (SP) generates a SAML Login request. At this point, no user-specific information is included in the SAML, however, an Assertion Consumer Service (ACS) URL* is part of the SAML request. A Relay State URL is also included, which will be carried through the entire process unchanged for eventual handling by the SP. 
  3. The SP requests a browser redirect to the Identity Provider (IDP) URL, with the encoded** SAML request and Relay State URL as part of the request (on the query string).
  4. At the IDP, the SAML request is decoded and parsed. In the event that the IDP cannot parse the request, an error is given to the user and no further action can be taken. After a successful parse, the IDP presents a login form to the user (typically a e-mail address / password combination). This form is POSTed to the IDP - if the IDP cannot authenticate the user, an error screen is presented to the user and they are allowed to retry the login. 
  5. After a successful authentication, the IDP generates a SAML Response (including the Globally Unique ID (GUID) of the authenticated user and an XML representation of their profile) and digitally signs (using XML dsig) and Base64 encodes it.
  6. The browser is requested to POST the SAML Response (along with the initial Relay State URL provided by the SP) to the ACS URL that was originally sent as part of the SAML Request from the SP. In the BSG Platform implementation, this POST is handled indirectly via JavaScript.
  7. Code located at the Service Provider ACS URL decodes and verifies the digital signature of the SAML Response and then parses it. The SAML Response includes the user GUID and user profile. If the ACS method can find the user by this GUID, then their local profile is updated based on the profile returned by the IDP, and logged in. In this way, the IDP acts as a master user-profile repository.
    • If the user can not be found by the given GUID, the Service Provider decides whether to create this new user locally and then log the user in. In this way 'Single Registration' or 'Single Sign-Up' can be achieved by copying the shared profile from the IDP to the SP, effectively creating a new user at the SP. If the SP disallows the user to have a local account, an error message is presented to the user.
  8. The user, now logged in to the SP, is redirected to the Relay State URL (which has performed a full round trip from SP to IDP)
(*) The ACS URL is the URL that the Identity Provider eventually POSTs back to with a SAML Response. This URL is responsible for any log-in procedures specific to the Service Provider (these procedures may include putting the user in a session object, applying access control list values (roles/memberships) and any other procedures deemed necessary by the SP)
(**) the SAML request is ZLib deflated and Base64 encoded, in that order. The SAML Response from the IDP is Base64 encoded.
Passive, REST based SSO
What does 'Passive' mean in this context?
  • 'Passive' SSO interaction means that there is no user interface provided. Some application requests login status 'behind the scenes' on a user's behalf. For example, while logged in to bsgalliance.com, a user may request to view a document found in a conversation. Unbeknownst to this user, this document is served through the BSG Platform Storage Service. When this request is made, the application hands the originally generated SAML Request ('token') from your login to the Storage Service. This remote service 'passively' requests a User Service authentication of your login token in order to ascertain whether you have access to said document. All of this happens without direct user interaction.

saml_flow_diagram_passive.gif
    (Click image to enlarge)
  1. A Service Provider (SP), such as the Storage Service, is requested to verify the login status of a given user. The SP has the users' previous SAML Response ('token'), which includes a user-specific SessionIndex value.
  2. The SessionIndex value is POSTed via a REST call to the IDP. The body of the POST has the SessionIndex value as a parameter named 'auth_session_index'
  3. The IDP retrieves the auth_session_index and verifies that there is a user with that SessionIndex value, and that the initial SAML Response that was generated when the user logged in is still valid.
  4. If the original SAML Response is still valid, that same SAML Response will be used. If the original SAML response is no longer valid (session expired, for example), or no user could be found for the given SessionIndex, a failure SAML Response is generated.
  5. The SAML Response (whether it be the still-valid original SAML response, or a failure SAML Response) is REST-fully returned to the SP.
  6. The SP retrieves the SAML Response, decodes and verifies the digital signature. It is the responsibility of the SP to determine whether the SAML Response is a success or failure, and act accordingly. In the BSG reference architecture, a success will allow the user to move forward. A failure will require the user to log in before they may continue.

Apps Team, Architecture Review Team, Platform, Primer, SOA, User Service
Rating (0.0) 
Rt-00-16

Log In to Reply | Log In to Copy | Tell a Friend | Feed_small Secure_feed_16 Abuse_16x16

Featured

nGen Collaboration v7.1
Project CBS
Project LIM
Project ITM
Wiki Archive
Concours Archive

Author Profile

Mike Roeder  Feed_small Secure_feed_16

Mike Roeder

Guide Rank_guide

Tag Cloud

academia advertising Apps Team Blogs branding Brian Magierski BSG business model citizen participation cloud computing Collaboration collective intelligence Communication Community connectivity content copyright crowd sourcing customer co-creation customer experience customer innovations Data Demand Maturity dilbert Documentation e.laborate Education election Elmore Enterprise 2.0 environment Espen Andersen Facebook Financial Services Frank Capek gaming GenX Globalization Google gov 2.0 government Industry Innovations internet Irregulars IS Management IT Infrastructure IT Management IT Maturity Jeff Milne Julien Dionne Katie Tierney Leadership Marketing mash-ups mashups mass collaboration Media & Articles N-Gen Net Generation New Paradigm News Next Generation Enterprise nGenera Product Management Office 2.0 Open Source Openness Outsourcing platforms policy politics Privacy prosumers Recruiting RSS SaaS Security SOA Social Media social networking Supply Maturity Talent Talent Management Tammy Erickson Technology Tom Steinthal transparency twitter Uncategorized user-created Vaughan Merlyn Web 2.0 wiki workplace Wikinomics wikipedia Wikis YouTube

Subscribe

Feed for nGenera Community:
Feed_small Public Secure_feed_16 Secure

Why subscribe? What is RSS?