The blog you reference is about the the "validate binding" of WS-Trust where the SAML token is sent in the ValidateTarget element of the request to the STS.
How does your use case look like: - Issue binding request, saml token sent in OnBehalfOf element - Issue binding request, saml token sent in ActAs element - Issue binding request, saml token sent in WS-Security header - Validate binding request, saml token sent in ValidateTarget element Check the following blog which describes how to configure different certificates per realm: http://coheigea.blogspot.com/2012/01/apache-cxf-251-sts-updates.html The SAMLRealmCodec is required to figure out the realm based on a incoming SAML token. Thanks ------ Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com ________________________________________ From: Urmila & Sunil Bapat [[email protected]] Sent: 09 May 2012 23:42 To: [email protected] Subject: Re: STS questions Thanks for the information. It was very helpful. I had a followup question regarding the SAML token validation. The StaticSTSProperties class has a signaturePropertiesFile property which is used for signing the issued SAML assertions. What property would we use to configure the certificate for the validation of the incoming SAML assertion from a different domain. This incoming SAML assertion has been signed with a different certificate which would be in a local truststore. The following blog entry http://coheigea.blogspot.com/2011/11/apache-cxf-sts-documentation-part-vi.html, says that the signature of the Assertion is validated using the Crypto object retrieved from the STSPropertiesMBean. However the StaticSTSProperties which implements the STSPropertiesMBean interface seems to initialize the signatureCrypto with the signature properties. How do we configure separate keystores for signing the issued assertion and validating the incoming assertion (signed by a different domain)? Thanks Sunil. On Wed, Apr 25, 2012 at 2:08 AM, Oliver Wulff <[email protected]> wrote: > 1) > The STS uses the CXF WS-SecurityPolicy engine which supports policy > alternatives. Usually, I configure a separate endpoint per policy > alternative thus the client decided based on the choosen URL which policy > is enforced. The question is what the STS client does if several policy > alternatives are provided. > > The security domain is called "realm" in the CXF STS. You can customize > how the target realm is figured out - especially if you several domains > activated in one CXF STS instance (JVM) (see RealmParser). > > How do you differentiate whether a SAML token has been issued from domain > A or domain B? In the CXF STS, this can be customized by implementing > SAMLRealmCodec: > > http://svn.apache.org/viewvc/cxf/trunk/services/sts/sts-core/src/main/java/org/apache/cxf/sts/token/realm/SAMLRealmCodec.java?view=markup > > One option is that a different certificate/pk is used to sign the SAML > assertion in each realm. > > Do you use the issue binding in all cases? > > > If you want to customize SAML token creation (custom authstatement, > attributstatement, condition, subject, ...) have a read through this blog: > > http://coheigea.blogspot.com/2011/10/apache-cxf-sts-documentation-part-iv.html > > > The SAML token validator validates (signature, trusted cert, condition) > SAML tokens in OnBehalfOf, ValidateTarget, RenewTarget. > > 2) > I think the following use case describes what you want to achieve: > > http://owulff.blogspot.com/2012/03/ws-federation-across-several-companies.html > > > 3) > Where is the SAML token passed, WS-Security header/OnBehalfOf? > > If you want to customize token validation, you can get more information > here: > > http://coheigea.blogspot.com/2011/11/apache-cxf-sts-documentation-part-v.html > > > HTH > > > ------ > > Oliver Wulff > > Blog: http://owulff.blogspot.com > Solution Architect > http://coders.talend.com > > Talend Application Integration Division http://www.talend.com > > ________________________________________ > Von: Urmila & Sunil Bapat [[email protected]] > Gesendet: Dienstag, 24. April 2012 23:25 > Bis: [email protected] > Betreff: STS questions > > In CXF 2.5.1, we are trying to implement a scenario similar to the Broker > Trust STS scenario from Metro ( > http://metro.java.net/2.1.1/guide/Example_Applications.html#ahiex) using > CXF STS. > > We had several questions: > > 1. Does the CXF STS support multiple security policy alternatives, where > the STS from a domain A, can be called with either a username token, or a > SAML token issued by STS from domain B? The SAML STS will handle either > call depending from which domain it is called. If the STS is called from > the same domain, it will get a username token, whereas if it is called from > another trusted domain, it will get a SAML token issued by a trusted STS > from the other domain. > > 2. Is this scenario commonly used? Or is this type of a configuration not > typically used. All examples we ran across, the STS was configured with > just a single policy alternative. For example, in NetBeans, the Metro > wizard seems to support only one security mechanism for a service. > > 3. If the STS is configured to require a SAML token for authentication, how > is the SAML validation performed, and is there a way to configure a custom > handler to validate the incoming SAML assertion, before issuing the STS > SAML assertion? > > Any help is appreciated. > > Thanks > Sunil. >
