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.
>>
