> I was able to configure wss4j as follows. This seemed to work, it > validated the incoming SAML assertion and issued the new token. Does > the following make sense?
You don't need to specify the "ws-security.saml2.validator" property as "org.apache.ws.security.validate.SamlAssertionValidator", as this is the default validator for SAML Assertions. You only need to specify it if you want to handle things differently from the default behaviour. Colm. On Tue, May 15, 2012 at 9:36 PM, Urmila & Sunil Bapat <[email protected]> wrote: > The usecase was where the saml token was sent in WS-Security header as > it was used as the security mechanism for the STS. > > I was able to configure wss4j as follows. This seemed to work, it > validated the incoming SAML assertion and issued the new token. Does > the following make sense? > > <bean id="wss4jSAMLValidator" > class="org.apache.ws.security.validate.SamlAssertionValidator" /> > > <jaxws:endpoint id="STS" implementor="#stsProviderBean" > address="/STS" wsdlLocation="/WEB-INF/wsdl/STS.wsdl" > xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"; > serviceName="ns1:SecurityTokenService" endpointName="ns1:Port"> > <jaxws:properties> > <entry key="ws-security.saml2.validator" value-ref="wss4jSAMLValidator"/> > <entry key="ws-security.signature.properties" > value="truststore.properties"/> > </jaxws:properties> > </jaxws:endpoint> > > I also had a followup question regarding how to configure the > corresponding STSClient. I am not sure which properties and callback I > should use to insert the existing SAML assertion in the security > header when using STSClient. I tried setting the property > ws-security.saml-callback-handler, to my custom class which sets the > assertion in the SAMLCallback.setAssertionElement, but that did not > seem to work. Any ideas? > > I posted this client question on a separate thread at > http://cxf.547215.n5.nabble.com/STSClient-configuration-td5707925.html. > (Sorry...I did not see your reply before i posted that question, > otherwise I would have posted that question in this thread). > > Thanks > Sunil. > > > On Fri, May 11, 2012 at 9:22 AM, Oliver Wulff <[email protected]> wrote: >> 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. >>> -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
