<<< it's the CXF WSC that is complaining about the absent TokenType from the STS? (I thought the complaint was from a CXF WSP about the ADFS token it was getting from the WSC). >>> For but report 4367, it was WSP that complaining about TokenType. After I set "ws-security.is-bsp-compliant" to "false: on the WSP side per Colm's advise, I passed problem with CXF-4367. WSP generated a response, but Client throwing an exception. So, I am having a new issue now.
Thanks. Gina On Mon, Jun 11, 2012 at 4:10 PM, Glen Mazza <[email protected]> wrote: > Oh, I misunderstood your problem--it's the CXF WSC that is complaining > about the absent TokenType from the STS? (I thought the complaint was from > a CXF WSP about the ADFS token it was getting from the WSC). I'm not sure > if the is-bsp-compliant setting would work if attached to the WSC > complaining about the STS (haven't tested it). > > Your bug report 4367 is kind of vague -- it doesn't specify what you're > using for the WSP or WSC (CXF for one or both?), and in step #4 when you > say "Now I am getting 'An invalid security token was provided (Bad > TokenType "")' it's best to let us know whether it's the WSC or WSP > reporting that. Try to be more specific next time. > > Glen > > > On 06/11/2012 03:54 PM, Gina Choi wrote: > >> 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] <mailto: >> [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]> <mailto:[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> >> > >> >> <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> >> <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]> >> <mailto:[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]> <mailto:[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> >> <http://coders.talend.com> >> blog: www.jroller.com/gmazza >> <http://www.jroller.com/gmazza**> <http://www.jroller.com/gmazza** >> > >> >> >> >> >> >> -- 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 > >
