Hi there
Thinking out loud here...
Imagine the following use case. There is a service consumer and a service
provider using SOAP/HTTPS. Both understand SAML tokens. An identity known in
the security domain of the service consumer is not known to the domain of the
service provider.
To address this I see the following approach. The IssuedToken assertion in the
WS-SecurityPolicy document of the service provider defines the Issuer he trusts
which is the so called Relying Party STS. The service consumer configures the
STSClient bean where you define the URL of the STS.
The URLs should be equal for the use cases supported by CXF right now. If they
are not I'd say we have the use case I described above. I assume that CXF 2.4
ignores the Issuer element in the IssuedToken assertion, right?
<sp:IssuedToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ...>
<sp:Issuer>wsa:EndpointReferenceType</sp:Issuer>
<sp:RequestSecurityTokenTemplate TrustVersion="xs:anyURI"? >
...
If yes, we should consider to check the Issuer element. If it is the same as in
the STSClient we proceed as the current functionality of CXF 2.4. If they are
different, I'd say that the service consumer first goes to the STS configured
in the STSClient and gets a SAML token. Then the service consumer sends the
previously issued token to the Relying Party STS and let's issue a new token
based on the data in the RequestSecurityTokenTemplate element of the policy. As
far as I understand the WS-Federation spec this is the idea of the active
requestor profile. It's then up to the Relying Party STS do implements claims
transformation (like principal mapping, role mapping and other claims)
What are your thoughts?
Thanks
Oli
