You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Urmila & Sunil Bapat <su...@gmail.com> on 2012/04/24 23:25:59 UTC
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.
RE: STS questions
Posted by Oliver Wulff <ow...@talend.com>.
I've created a multi-realm STS which is available here:
https://github.com/owulff/sts_wsfed
I've configured individual signing certificates for the two realms "REALMA" and "REALMB". I've moved the certs of the two keystores into a separate truststore. The Relationship between the two is configured to "FederatedIdentity" which means the IdentityMapper is called.
You can find a soapui project as well.
HTH
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Colm O hEigeartaigh [coheigea@apache.org]
Sent: 16 May 2012 10:40
To: users@cxf.apache.org
Subject: Re: STS questions
> 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 <su...@gmail.com> 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 <ow...@talend.com> 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 [subapat@gmail.com]
>> Sent: 09 May 2012 23:42
>> To: users@cxf.apache.org
>> 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 <ow...@talend.com> 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 [subapat@gmail.com]
>>> Gesendet: Dienstag, 24. April 2012 23:25
>>> Bis: users@cxf.apache.org
>>> 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
Re: STS questions
Posted by Colm O hEigeartaigh <co...@apache.org>.
> 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 <su...@gmail.com> 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 <ow...@talend.com> 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 [subapat@gmail.com]
>> Sent: 09 May 2012 23:42
>> To: users@cxf.apache.org
>> 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 <ow...@talend.com> 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 [subapat@gmail.com]
>>> Gesendet: Dienstag, 24. April 2012 23:25
>>> Bis: users@cxf.apache.org
>>> 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
Re: STS questions
Posted by Urmila & Sunil Bapat <su...@gmail.com>.
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 <ow...@talend.com> 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 [subapat@gmail.com]
> Sent: 09 May 2012 23:42
> To: users@cxf.apache.org
> 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 <ow...@talend.com> 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 [subapat@gmail.com]
>> Gesendet: Dienstag, 24. April 2012 23:25
>> Bis: users@cxf.apache.org
>> 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.
>>
RE: STS questions
Posted by Oliver Wulff <ow...@talend.com>.
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 [subapat@gmail.com]
Sent: 09 May 2012 23:42
To: users@cxf.apache.org
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 <ow...@talend.com> 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 [subapat@gmail.com]
> Gesendet: Dienstag, 24. April 2012 23:25
> Bis: users@cxf.apache.org
> 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.
>
Re: STS questions
Posted by Urmila & Sunil Bapat <su...@gmail.com>.
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 <ow...@talend.com> 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 [subapat@gmail.com]
> Gesendet: Dienstag, 24. April 2012 23:25
> Bis: users@cxf.apache.org
> 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.
>
AW: STS questions
Posted by Oliver Wulff <ow...@talend.com>.
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 [subapat@gmail.com]
Gesendet: Dienstag, 24. April 2012 23:25
Bis: users@cxf.apache.org
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.