Hi Oli, > I assume that CXF 2.4 ignores the Issuer element in the IssuedToken > assertion, right?
Correct. I plan on enforcing provider side policy validation of the sp:IssuerName, so that if it is specified in the policy it is compared to the Issuer String of the received SAML Assertion. I'm not sure there is much validation we can do with the sp:Issuer though. > 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. That seems a reasonable enhancement. Could you open a JIRA for it? Colm. On Thu, May 5, 2011 at 11:34 AM, Oliver Wulff <[email protected]> wrote: > 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 > > >
