Skip to main content
Jump to: navigation, search

SAML2 and STS Convergence

Revision as of 17:22, 30 January 2008 by Markus.sabadello.gmail.com (Talk | contribs) (New page: The SAML2 IdP is one of the Higgins Solutions. It can authenticate users against IdAS contexts and issue SAML 2.0 assertions. The Security Token Service (STS) is an extensible...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The SAML2 IdP is one of the Higgins Solutions. It can authenticate users against IdAS contexts and issue SAML 2.0 assertions.

The Security Token Service (STS) is an extensible framework that can issue tokens in various formats.

Since there is conceptual overlap in the functionalities of these two components, Mike, Markus and Paul have repeatedly spent time on thinking about how to integrate them. The general idea is that the SAML2 IdP should re-use existing STS code instead of "inventing everything by itself".

Concrete ideas

  • The STS should be used to generate SAML 2.0 tokens (assertions). Right now this is done by code in the higgins.saml2idp.saml2 project and by the SAMLUtil classes in the higgins.saml2idp.server and higgins.saml2idp.test projects. The way to move this functionality into the STS is to create an ITokenHandler implementation that can generate SAML 2.0 tokens.
  • The protocol implementation itself (i.e. parsing requests, HTTP GET redirection, Form POST redirection) should remain in the SAML2 IdP projects. Mike, is this correct?
  • Right now user authentication happens in the SAML2 IdP. This should be done by the STS instead. This is the first step in the workflow of the STS. Mike, what again is the name of that first step? I forgot..
  • In some use cases of the SAML2 IdP (see SAML2_IdP_Overview#Security) assertions are issued without actually authenticating the user against IdAS. These cases can also be handled by the STS by creating specialized implementations of IDigitalIdentity. Mike, is this correct?

Back to the top