View source for SAML2 and STS Convergence

{{#eclipseproject:technology.higgins}}
The [[SAML2 IdP]] is one of the Higgins [[Solutions]]. It can authenticate users against IdAS contexts and issue SAML 2.0 assertions.

The [[STS IdP]] is one of the Higgins [[Solutions]]. It can authenticate users against IdAS contexts and issue tokens in various formats, including SAML 1.1 assertions.

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". The common framework will be known as the [[Higgins Server Framework]].

The [[Higgins Server Framework]] is a multiprotocol capable server application which be used to host the [[SAML2 IdP]] and/or the [[STS IdP]] and in the future, the [[OpenId IdP]].

== Concrete ideas ==

* Currently, the [[STS IdP]] contains many classes that could be useful in issuing tokens using protocols other than WS-Trust. The WS-Trust specific logic is isolated into the [[WS-Trust Protocol Binding]].

* The non-WS-Trust specific parts of the current [[STS IdP]] should be renamed as [[Higgins IdP]] to reflect their more general usage.

* The [[SAML2 IdP]] should be refactored to to separate the protocol specific parts (i.e. parsing requests, HTTP GET redirection, Form POST redirection) into a [[SAML2 Protocol Binding]] and replace the token issuance components with an invocation of the [[Higgins IdP]].

* The [[SAML2 IdP]] contains code 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. 

* A [[SAML2 Token Generator]] implementation of the ITokenHandler interface should be developed to generate SAML 2.0 assertions. 

* Currently, user authentication happens in the [[SAML2 IdP]]. This should be done by the [[Higgins IdP]] instead. This is the first step in the workflow of the [[Higgins IdP]]. Currently this is done in the [[Digital Identity Handler]].

* 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 [[Higgins IdP]] by creating specialized implementations of IDigitalSubject, perhaps using an alternative to the [[Digital Identity Handler]].