[STS] How to handle BinarySecurityToken when it's not as expected?

[NicholaiX]

Hi,
I unfortunately don't know much about SOAP, so I don't know if this is a
"duh" type question. Please forgive in advance!

I have configured STS and I'm getting a request which is causing an
exception. I am looking for hints or pointers on how to handle this
scenario.

This is the exception:

Caused by: org.apache.wss4j.common.ext.WSSecurityException: BSP:R3030: Any
BINARY_SECURITY_TOKEN EncodingType attribute MUST have a value of
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"

--
The request I'm receiving is this, which has the EncodingType as the secext
namespace.


<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<s:Header>
<a:Action
s:mustUnderstand="1">http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RST/wstep</a:Action>
<a:MessageID>urn:uuid:0d5a1441-5891-453b-becf-a2e5f6ea3749</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">https://localhost:9999/sts</a:To>
<wsse:Security s:mustUnderstand="1">
<wsse:BinarySecurityToken
ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">...token
edited for space...</wsse:BinarySecurityToken>
</wsse:Security>
</s:Header>
<s:Body>
<wst:RequestSecurityToken>

<wst:TokenType>http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken</wst:TokenType>

<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wsse:BinarySecurityToken
ValueType="http://schemas.microsoft.com/windows/pki/2009/01/enrollment#PKCS10"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">...cert
edited for space...</wsse:BinarySecurityToken>
<ac:AdditionalContext
xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<ac:ContextItem Name="TargetedUserLoggedIn">
<ac:Value>true</ac:Value>
</ac:ContextItem>

</ac:AdditionalContext>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>




--
View this message in context: http://cxf.547215.n5.nabble.com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected-tp5782018.html
Sent from the cxf-user mailing list archive at Nabble.com.

[Colm O hEigeartaigh]

The message is failing validation against the Basic Security Profile 1.1
spec. The spec states:

R3030 Any BINARY_SECURITY_TOKEN EncodingType attribute MUST have a value of
"
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
".

However, in your message a lower case "base64Binary" value is used, which
is not correct. You can either fix this in your code or else turn off Basic
Security Profile validation.

Colm.

Post by NicholaiX
Hi,
I unfortunately don't know much about SOAP, so I don't know if this is a
"duh" type question. Please forgive in advance!
I have configured STS and I'm getting a request which is causing an
exception. I am looking for hints or pointers on how to handle this
scenario.
Caused by: org.apache.wss4j.common.ext.WSSecurityException: BSP:R3030: Any
BINARY_SECURITY_TOKEN EncodingType attribute MUST have a value of
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
soap-message-security-1.0#Base64Binary"
--
The request I'm receiving is this, which has the EncodingType as the secext
namespace.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<s:Header>
<a:Action
s:mustUnderstand="1">http://schemas.microsoft.com/windows/
pki/2009/01/enrollment/RST/wstep</a:Action>
<a:MessageID>urn:uuid:0d5a1441-5891-453b-becf-
a2e5f6ea3749</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</
a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">https://localhost:9999/sts</a:To>
<wsse:Security s:mustUnderstand="1">
<wsse:BinarySecurityToken
ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/
Enrollment/DeviceEnrollmentUserToken"
EncodingType="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">...token
edited for space...</wsse:BinarySecurityToken>
</wsse:Security>
</s:Header>
<s:Body>
<wst:RequestSecurityToken>
<wst:TokenType>http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/
Enrollment/DeviceEnrollmentToken</wst:TokenType>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
</wst:RequestType>
<wsse:BinarySecurityToken
ValueType="http://schemas.microsoft.com/windows/pki/
2009/01/enrollment#PKCS10"
EncodingType="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">...cert
edited for space...</wsse:BinarySecurityToken>
<ac:AdditionalContext
xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<ac:ContextItem Name="TargetedUserLoggedIn">
<ac:Value>true</ac:Value>
</ac:ContextItem>
</ac:AdditionalContext>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>
--
View this message in context: http://cxf.547215.n5.nabble.
com/STS-How-to-handle-BinarySecurityToken-when-it-s-
not-as-expected-tp5782018.html
Sent from the cxf-user mailing list archive at Nabble.com.

[Colm O hEigeartaigh]

The problem here is actually nothing to do with the EncodingType attribute.
It's that a BinarySecurityToken is being included in the WS-Trust request
Body and the STS is objecting as it does not know how to handle it. Why is
this element being included here? Are both BinarySecurityTokens duplicates
of each other?

Colm.

Sorry for the late reply. I took some time to refactor and redo part of the
code. I'm still having an issue with this token, but the circumstances have
changed. I do have bsp-compliant set to false on the endpoint...
props.put("ws-security.is-bsp-compliant", "false");
22:34:34.124 [XNIO-3 task-12] WARN o.a.c.s.r.RequestParser (123) - Found a
{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd}BinarySecurityToken
22:34:34.127 [XNIO-3 task-12] WARN o.a.c.s.r.RequestParser (132) -
org.apache.cxf.ws.security.sts.provider.STSException: The specified
RequestSecurityToken is not understood
at
org.apache.cxf.sts.request.RequestParser.parseRequest(
RequestParser.java:127)
at
org.apache.cxf.sts.operation.AbstractOperation.parseRequest(
AbstractOperation.java:202)
at
org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle(
TokenIssueOperation.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider.
invoke(SecurityTokenServiceProvider.java:244)
at
com.hp.dfm.services.mdm.microsoft.impl.AOMServiceImpl.
invoke(AOMServiceImpl.java:269)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(
AbstractInvoker.java:180)
at
org.apache.cxf.jaxws.JAXWSMethodInvoker.performInvocation(
JAXWSMethodInvoker.java:66)
at
org.apache.cxf.service.invoker.AbstractInvoker.
invoke(AbstractInvoker.java:96)
at
org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(
AbstractJAXWSMethodInvoker.java:232)
at
org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:85)
at
org.apache.cxf.service.invoker.AbstractInvoker.
invoke(AbstractInvoker.java:74)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.
run(ServiceInvokerInterceptor.java:59)
at java.util.concurrent.Executors$RunnableAdapter.
call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.
run(ServiceInvokerInterceptor.java:126)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(
SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(
ServiceInvokerInterceptor.java:131)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
PhaseInterceptorChain.java:308)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(
ChainInitiationObserver.java:121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
AbstractHTTPDestination.java:263)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(
ServletController.java:234)
at
org.apache.cxf.transport.servlet.ServletController.
invoke(ServletController.java:208)
at
org.apache.cxf.transport.servlet.ServletController.
invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.
invoke(CXFNonSpringServlet.java:189)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(
AbstractHTTPServlet.java:299)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.
doPost(AbstractHTTPServlet.java:218)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.
service(AbstractHTTPServlet.java:274)
--
View this message in context: http://cxf.547215.n5.nabble.
com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected-
tp5782018p5782177.html
Sent from the cxf-user mailing list archive at Nabble.com.

[Colm O hEigeartaigh]

I could modify the logic just to process the BinarySecurityToken and store
it on the context. What is the expected behaviour of the STS for this
request? How should it interpret that BinarySecurityToken? Are you plugging
in a custom TokenProvider to support whatever the requested token format is?

Colm.

They are not exactly duplicates, they differ in the payload. The one in the
body contains a certificate.
These are payloads sent by windows, and as such I have no control over
their
https://msdn.microsoft.com/en-us/library/dn366934.aspx
https://msdn.microsoft.com/en-us/library/dn410740.aspx
Authentication MUST be implemented for this message as defined in section
3.4. In summary, the following elements and attributes MUST be specified in
wsse:Security: The <wsse:Security> element MUST be a child of <s:Header>.
wsse:BinarySecurityToken: The <wsse:BinarySecurityToken> element MUST be a
child of <wsse:Security> in <s:Header>.
wsse:BinarySecurityToken/attributes/ValueType: The
<wsse:BinarySecurityToken> ValueType attribute MUST be
"http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/
DeviceEnrollmentUserToken".
wsse:BinarySecurityToken/attributes/EncodingType: The
<wsse:BinarySecurityToken> EncodingType attribute MUST be
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd#base64binary".
The following elements and attributes MUST be specified in the SOAP body of
the request message.
wst:RequestSecurityToken: The <wst:RequestSecurityToken> element MUST be a
child of <s:Body>.
wst:RequestType: The <wst:RequestType> element MUST be a child of
<wst:RequestSecurityToken> and the value MUST be
"http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue" (see [WSTrust1.3]
section 3.1).
wst:TokenType: The <wst:tokentype> element MUST be a child of
<wst:RequestSecurityToken> and the value MUST be
"http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/
Enrollment/DeviceEnrollmentToken" (see [WSTrust1.3] section 3.1).
wsse:BinarySecurityToken: The <wsse:BinarySecurityToken> element MUST be a
child of <wst:RequestSecurityToken> and MUST contain a base64-encoded
certificate signing request.
wsse:BinarySecurityToken/attributes/ValueType: The
<wsse:BinarySecurityToken> ValueType attribute MUST be
"http://schemas.microsoft.com/windows/pki/2009/01/ enrollment#PKCS10".
wsse:BinarySecurityToken/attributes/EncodingType: The
<wsse:BinarySecurityToken> EncodingType attribute MUST be
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd#base64binary".
ac:AdditionalContext: The <ac:AdditionalContext> element MUST be a child of
<wst:RequestSecurityToken> (see [MS-WSTEP] section 3.1.4.1.3.3).
ac:ContextItem: One or more <ac:ContextItem> elements MUST be specified as
child elements of <ac:AdditionalContext> to represent the device type.
ac:ContextItem/attributes/Name: The <ac:ContextItem> Name attribute MUST
be
the literal string "DeviceType".
ac:Value: The <ac:Value> element MUST be a child of <ac:AdditionalContext>
and the value MUST be CIMClient_Windows.
--
View this message in context: http://cxf.547215.n5.nabble.
com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected-
tp5782018p5782247.html
Sent from the cxf-user mailing list archive at Nabble.com.

[NicholaiX]

At this point, I just need access to the BST inside the RST and forward it to
a certificate issuer so it can issue me a certificate. I also need access to
the AdditionalContext inside the RST (My request to the issuer needs to
contain both items)

I haven't written the code yet since I didn't get past the BST hurdle, so I
don't know how the implementation will go, I am open to any approach. I
don't see why it couldn't be a custom tokenprovider, assuming I can hand off
both the BST and the additonalcontext. But since the BST and the
additionalcontext inside the RST are peers not parent/child, would that
work?











--
View this message in context: http://cxf.547215.n5.nabble.com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected-tp5782018p5782271.html
Sent from the cxf-user mailing list archive at Nabble.com.

[Colm O hEigeartaigh]

There is a boolean called "allowCustomContent" that you can set on the
AbstractOperation:

https://github.com/apache/cxf/blob/master/services/sts/sts-core/src/main/java/org/apache/cxf/sts/operation/AbstractOperation.java#L107

Up to now it only supported DOM Elements. I've updated the code to allow
JAXBElements as well. So if you grab the latest SNAPSHOT code for 3.2 or
3.1, and set that boolean, you will have access to the custom content in
this class:

https://github.com/apache/cxf/blob/master/services/sts/sts-core/src/main/java/org/apache/cxf/sts/request/TokenRequirements.java#L48

For backwards compatibility reasons, in 3.1.x there will be two lists, one
containing the custom DOM Elements parsed, and the other the custom JAXB
Elements. Then you need to write a TokenProvider to understand the
requested TokenType, which is not supported by default in CXF.

Colm.

Post by NicholaiX
At this point, I just need access to the BST inside the RST and forward it to
a certificate issuer so it can issue me a certificate. I also need access to
the AdditionalContext inside the RST (My request to the issuer needs to
contain both items)
I haven't written the code yet since I didn't get past the BST hurdle, so I
don't know how the implementation will go, I am open to any approach. I
don't see why it couldn't be a custom tokenprovider, assuming I can hand off
both the BST and the additonalcontext. But since the BST and the
additionalcontext inside the RST are peers not parent/child, would that
work?
--
View this message in context: http://cxf.547215.n5.nabble.
com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected-
tp5782018p5782271.html
Sent from the cxf-user mailing list archive at Nabble.com.

[NicholaiX]

Thank you, it worked well for me, much appreciated.

Since I pulled 3.2, this means that the JAXBelements and DOMElements will
all be in one list, correct? (I was confused by that until I read the
commend indicating the two lists is only a 3.1 artifact)

How do I know when this fix will be released in 3.1 vs 3.2, to determine
which version I should focus on? I have not managed to find the release
plans, and JIRA has both branches with release date as "Not Set"

Again thank you!




--
View this message in context: http://cxf.547215.n5.nabble.com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected-tp5782018p5782405.html
Sent from the cxf-user mailing list archive at Nabble.com.

[Colm O hEigeartaigh]

We normally release every 2 months or so, so you could expect the next CXF
3.1.x release at the end of August. I think CXF 3.2.0 will happen soon as
well, but I can't offer any guarantees on that.

Colm.

Post by NicholaiX
Thank you, it worked well for me, much appreciated.
Since I pulled 3.2, this means that the JAXBelements and DOMElements will
all be in one list, correct? (I was confused by that until I read the
commend indicating the two lists is only a 3.1 artifact)
How do I know when this fix will be released in 3.1 vs 3.2, to determine
which version I should focus on? I have not managed to find the release
plans, and JIRA has both branches with release date as "Not Set"
Again thank you!
--
View this message in context: http://cxf.547215.n5.nabble.
com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected-
tp5782018p5782405.html
Sent from the cxf-user mailing list archive at Nabble.com.