[JBoss JIRA] Created: (JBID-140) JBoss STS - add a ClaimsHandler interface that allows for pluggable claims interpreters
by Stefan Guilhen (JIRA)
JBoss STS - add a ClaimsHandler interface that allows for pluggable claims interpreters
---------------------------------------------------------------------------------------
Key: JBID-140
URL: https://jira.jboss.org/jira/browse/JBID-140
Project: JBoss Identity
Issue Type: Task
Components: Identity-Federation
Affects Versions: IDFED-1.0.0.alpha3
Reporter: Stefan Guilhen
Assignee: Stefan Guilhen
Fix For: IDFED-1.0.0.alpha4
A WS-Trust request may contain a set of claims that must be included in the issued token. The claims syntax is not specified, so it must be inferred from the Dialect attribute of the Claims element. We must create a ClaimsHandler or ClaimsProvider interface in the STS system to allow for pluggable configuration of claim handlers.
A possible default implementation could handle claims as specified by the Identity Metasystem Interoperability 1.0 (http://docs.oasis-open.org/imi/ns/identity-200810) and use the JBoss IDM API to obtain the necessary information.
The configuration of the ClaimsHandlers would be similar to the TokeProviders and should also allow for the specification of general properties:
<ClaimsHandlers>
<ClaimsHandler HandlerClass="...." ClaimsDialect="http://....">
<Property name="prop" value="value"/>
</ClaimsHandler>
</ClaimsHandler>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBID-138) JBoss STS - implement proof-of-possession token logic
by Stefan Guilhen (JIRA)
JBoss STS - implement proof-of-possession token logic
-----------------------------------------------------
Key: JBID-138
URL: https://jira.jboss.org/jira/browse/JBID-138
Project: JBoss Identity
Issue Type: Task
Components: Identity-Federation
Affects Versions: IDFED-1.0.0.alpha3
Reporter: Stefan Guilhen
Assignee: Stefan Guilhen
Fix For: IDFED-1.0.0.alpha4
The WS-Trust specification defines the concept of a proof-of-possession token, that is, a token that can be used to verify the association between a security token and a subject. We must add support for proof tokens, both symmetric (secret key) and assymetric (certificate based). The proof must no only be included in the WS-Trust response, but also in the security tokens being generated by each token provider.
Once this has been implemented, we must change the SAML20TokenProvider so it adds the appropriate proof token to the assertion being created.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBID-137) JBoss STS - improve the configuration to allow for general properties to be specified for each token provider
by Stefan Guilhen (JIRA)
JBoss STS - improve the configuration to allow for general properties to be specified for each token provider
-------------------------------------------------------------------------------------------------------------
Key: JBID-137
URL: https://jira.jboss.org/jira/browse/JBID-137
Project: JBoss Identity
Issue Type: Task
Components: Identity-Federation
Affects Versions: IDFED-1.0.0.alpha3
Reporter: Stefan Guilhen
Assignee: Stefan Guilhen
Fix For: IDFED-1.0.0.alpha4
JBoss STS does not currently provide a way to specify general properties for a token provider. A token provider may be configurable (for example, a provider may take an URL of a third-party service or repository) and the configuration schema must be changed to allow the specification of properties.
The token providers should also be associated with the token element (namespace and local name) besides the token type. The reason for doing this is that validation/renewing/cancellation requests do not specify the token type explicitly so it must be inferred by the token element. The only way for the STS to figure out which provider should be used to validate the token is by having an association between token elements and providers. Something like:
<TokenProvider ProviderClass="...." TokenType="..." TokenNamespace="urn:...." TokenName="Assertion">
<Property name="..." value="..."/>
<Property name="..." vluae="..."/>
</TokenProvider>
A final note about configuration is about the need for the TruststoreAlias attribute of the ServiceProvider. The alias of each service provider can be configured through the ValidatingAlias element of KeyProvider, so we may just make the TruststoreAlias attribute optional.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 4 months