SAML2 and STS Convergence
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.
- 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.