Glen,
<<<
Since you're using ADFS as the STS, the above setting wouldn't be relevant
for the STS *but it would be proper on the CXF WSP*, so the ADSF SAML
assertion (which is missing the TokenType field) in the WSC's request will
still be accepted by the CXF WSP.
>>>
It would be proper WSP configuration, if I use CXF STS, correct? I prefer
that I control through client configuration since usually I don't have much
control over either WSP(If it is a .NET web service) or STS(ADFS2.0) config.

Gina

On Mon, Jun 11, 2012 at 3:38 PM, Glen Mazza <[email protected]> wrote:

> Sorry for the confusion, I dislike the naming
> "ws-security.is-bsp-compliant"**, it's misleading and should be called
> "ws-security.enforce-bsp-**compliance".  A CXF STS is always BSP
> compliant (at least in this regard), that setting is just about whether
> it's to complain when it gets a WSC request that doesn't provide the
> BSP-required TokenType.
>
> Since you're using ADFS as the STS, the above setting wouldn't be relevant
> for the STS but it would be proper on the CXF WSP, so the ADSF SAML
> assertion (which is missing the TokenType field) in the WSC's request will
> still be accepted by the CXF WSP.
>
> Glen
>
>
> On 06/11/2012 03:10 PM, Gina Choi wrote:
>
>> Hi Glen,
>> So, if I set up "ws-security.is-bsp-compliant" in STS config, STS will
>> generate a token without TokenType attribute, but in WSP side, I still need
>> to set up "ws-security.is-bsp-compliant"**=false to turn off checking
>> "ws-security.is-bsp-compliant" attribute, correct?
>> Thanks.
>> Gina
>> On Mon, Jun 11, 2012 at 1:10 PM, Glen Mazza <[email protected] <mailto:
>> [email protected]>> wrote:
>>
>>    The STS syntax for it (also good for WSP) is as line #75 here:
>>    https://github.com/gmazza/**blog-samples/blob/master/cxf_**
>> sts_tutorial/sts-war/src/main/**webapp/WEB-INF/cxf-servlet.xml<https://github.com/gmazza/blog-samples/blob/master/cxf_sts_tutorial/sts-war/src/main/webapp/WEB-INF/cxf-servlet.xml>
>>
>>    This worked for me with Metro clients that don't provide a TokenType.
>>
>>    Glen
>>
>>
>>    On 06/11/2012 11:31 AM, Gina Choi wrote:
>>
>>        Hi Colm,
>>
>>        <<<
>>        You can turn this off by setting the following jax-ws property
>>        "ws-security.is-bsp-compliant" to "false" for the service
>>        provider.
>>        Does setting "ws-security.is-bsp-compliant" to "false" make
>>        Service
>>        Provider not to check wsse11:TokenType attribute? ADFS2.0
>>        doesn't enforce
>>        wsse11:TokenType attribute, so the security token that I got
>>        from ADFS2.0
>>        wouldn't contain wsse11:TokenType attribute. I set
>>        "ws-security.is-bsp-compliant" through client configuration
>>        file like
>>        bellow, but it didn't change any result. I am getting same
>>        exception.
>>
>>
>>        <jaxws:client name="{
>>        
>> http://www.example.org/**contract/DoubleIt}DoubleItPort<http://www.example.org/contract/DoubleIt%7DDoubleItPort>
>>        
>> <http://www.example.org/**contract/DoubleIt%**7DDoubleItPort<http://www.example.org/contract/DoubleIt%7DDoubleItPort>
>> >"
>>
>>        createdFromAPI="true">
>>        <jaxws:properties>
>>        <entry key="ws-security.is-bsp-**compliant" value="false"/>
>>        <entry key="ws-security.sts.client">
>>        <bean class="org.apache.cxf.ws
>>        <http://org.apache.cxf.ws>.**security.trust.STSClient">
>>
>>        <constructor-arg ref="cxf"/>
>>        <property name="wsdlLocation" value="adfs_new_simple.wsdl"/>
>>        ........
>>
>>
>>        Gina
>>        On Mon, Jun 11, 2012 at 5:02 AM, Colm O
>>        hEigeartaigh<coheigea@apache.**org <[email protected]>
>>        <mailto:[email protected]>>**wrote:
>>
>>
>>            CXF enforces the Basic Security Profile 1.1 spec:
>>
>>            
>> http://www.ws-i.org/profiles/**basicsecurityprofile-1.1.html<http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html>
>>
>>            "R6611 Any SECURITY_TOKEN_REFERENCE to a SAML_V1_1_TOKEN
>>            MUST contain a
>>            wsse11:TokenType attribute with a value of "
>>            http://docs.oasis-open.org/**wss/oasis-wss-saml-token-**
>> profile-1.1#SAMLV1.1<http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1>
>> ".
>>            "
>>
>>            You can turn this off by setting the following jax-ws property
>>            "ws-security.is-bsp-compliant" to "false" for the service
>>            provider.
>>
>>            Colm.
>>
>>            On Sat, Jun 9, 2012 at 12:00 AM, Gina
>>            Choi<[email protected] <mailto:[email protected]>>
>>
>>             wrote:
>>
>>                I did some research and looked at oasis specification(
>>
>>
>>            https://www.oasis-open.org/**committees/download.php/16768/**
>> wss-v1.1-spec-os-**SAMLTokenProfile.pdf<https://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf>
>>
>>                ),
>>                it looks like that wsse11:TokenType attribute is
>>                optional for SAML 1.1,
>>
>>            but
>>
>>                should contain
>>                http://docs.oasis-open.org/**wss/oasis-wss-saml-token-**
>> profile-1.1#SAMLV1.1<http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1>
>>
>>            .
>>
>>
>>                <<<
>>
>>                Now I am getting 'An invalid security token was
>>                provided (Bad TokenType
>>                "")'. I debugged through code again and following is
>>                the issue.
>>                org.apache.ws.security.str.**BSPEnforcer.java(wss4j-1.6.6.
>> **jar)
>>                class Line
>>
>>            162
>>
>>                - 169
>>
>>                       String tokenType = secRef.getTokenType();
>>                       if (assertion.getSaml1() != null&&
>>                !WSConstants.WSS_SAML_TOKEN_**TYPE.equals(tokenType)) {
>>                           throw new WSSecurityException(
>>                               WSSecurityException.INVALID_**
>> SECURITY_TOKEN,
>>                               "invalidTokenType",
>>                                new Object[]{tokenType}
>>                           );
>>                       }
>>                The content of secRef object as follow. As you can see
>>                from above code,
>>
>>            it
>>
>>                is looking for an attribute named "TokenType", whose
>>                value is "
>>
>>                http://docs.oasis-open.org/**wss/oasis-wss-saml-token-**
>> profile-1.1#SAMLV1.1<http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1>
>>                " but SecurityTokenReference doesn't have it. That's
>>                why it throws
>>                exception. What we can do about this? I am going to
>>                update *CXF-4367 with
>>                new content.*
>>
>>                <o:SecurityTokenReference xmlns:o="
>>
>>
>>            http://docs.oasis-open.org/**wss/2004/01/oasis-200401-wss-**
>> wssecurity-secext-1.0.xsd<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd>
>>
>>                ">
>>                <o:KeyIdentifier ValueType="
>>
>>
>>            http://docs.oasis-open.org/**wss/oasis-wss-saml-token-**
>> profile-1.0#SAMLAssertionID<http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID>
>>
>>                ">
>>                 _ca94d3c5-0933-4af0-ac12-**a83fd407310c</o:KeyIdentifier>
>>                </o:SecurityTokenReference>
>>
>>
>>
>>            --
>>            Colm O hEigeartaigh
>>
>>            Talend Community Coder
>>            http://coders.talend.com
>>
>>
>>
>>    --     Glen Mazza
>>    Talend Community Coders
>>    coders.talend.com <http://coders.talend.com>
>>    blog: www.jroller.com/gmazza <http://www.jroller.com/gmazza**>
>>
>>
>>
>
> --
> Glen Mazza
> Talend Community Coders
> coders.talend.com
> blog: www.jroller.com/gmazza
>
>

Reply via email to