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
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>"
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<[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
"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";.
"
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
),
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
.
<<<
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
" 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
">
<o:KeyIdentifier ValueType="
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
