Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SAML2 and STS Convergence"
(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...) |
|||
| Line 1: | Line 1: | ||
The [[SAML2 IdP]] is one of the Higgins [[Solutions]]. It can authenticate users against IdAS contexts and issue SAML 2.0 assertions. | The [[SAML2 IdP]] is one of the Higgins [[Solutions]]. It can authenticate users against IdAS contexts and issue SAML 2.0 assertions. | ||
| − | The [[ | + | 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". | + | 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 == | == Concrete ideas == | ||
| − | * The STS should be | + | * 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. |
| − | * 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 | + | |
| + | * 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]]. | ||
Revision as of 20:20, 31 January 2008
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.