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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[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>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

coheigea
Administrator
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.

On Fri, Jul 21, 2017 at 7:08 PM, NicholaiX <[hidden email]>
wrote:

> 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

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

NicholaiX
Thanks Colm,

Actually it's an entire different namespace, not just the capitalization of the suffix:


EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">

Note the secext namespace rather than the expected one.

And yes, it's different than the spec.  How would I proceed?

As a side node, when I was using a regular cxf endpoint, I was able to set is-bsp-compliant to false to suppress the validation, in hopes I can intercept it later. But that suppression does not seem to work when using STS.

At this point, my needs are fairly basic, so I can use STS or just a regular CXF soap endpoint, but I'm still not clear how I should proceed in either case. It would be helpful if I could find an example of what I need to do to handle a custom token in CXF 3.x, to give me an idea of which parts I should be prepared to write.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

coheigea
Administrator
What's the stacktrace of the exception? I would expect it to fail on the
BST in the security header, and disabling BSP validation should work there.

Colm.

On Thu, Jul 27, 2017 at 2:03 AM, NicholaiX <[hidden email]>
wrote:

> Thanks Colm,
>
> Actually it's an entire different namespace, not just the capitalization of
> the suffix:
>
>
> EncodingType="http://docs.oasis-open.org/wss/2004/01/
> oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">
>
> Note the secext namespace rather than the expected one.
>
> And yes, it's different than the spec.  How would I proceed?
>
> As a side node, when I was using a regular cxf endpoint, I was able to set
> is-bsp-compliant to false to suppress the validation, in hopes I can
> intercept it later. But that suppression does not seem to work when using
> STS.
>
> At this point, my needs are fairly basic, so I can use STS or just a
> regular
> CXF soap endpoint, but I'm still not clear how I should proceed in either
> case. It would be helpful if I could find an example of what I need to do
> to
> handle a custom token in CXF 3.x, to give me an idea of which parts I
> should
> be prepared to write.
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.
> com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected-
> tp5782018p5782075.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

NicholaiX
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 JAXB object of unknown type: {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 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: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 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: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)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

coheigea
Administrator
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.

On Sat, Jul 29, 2017 at 4:43 AM, NicholaiX <[hidden email]>
wrote:

> 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
> JAXB object of unknown type:
> {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
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 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
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 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

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

NicholaiX
In reply to this post by NicholaiX
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 definition. The payload example is here:

https://msdn.microsoft.com/en-us/library/dn366934.aspx

The two BinarySecurityToken objects are defined here:

https://msdn.microsoft.com/en-us/library/dn410740.aspx

To quote:

Authentication MUST be implemented for this message as defined in section 3.4. In summary, the following elements and attributes MUST be specified in the SOAP header:
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

coheigea
Administrator
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.

On Mon, Jul 31, 2017 at 3:23 PM, NicholaiX <[hidden email]>
wrote:

> 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
> definition. The payload example is here:
>
> https://msdn.microsoft.com/en-us/library/dn366934.aspx
>
> The two BinarySecurityToken objects are defined here:
>
> https://msdn.microsoft.com/en-us/library/dn410740.aspx
>
> To quote:
>
> Authentication MUST be implemented for this message as defined in section
> 3.4. In summary, the following elements and attributes MUST be specified in
> the SOAP header:
> 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.
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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?







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

coheigea
Administrator
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.

On Tue, Aug 1, 2017 at 3:51 PM, NicholaiX <[hidden email]>
wrote:

> 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

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

coheigea
Administrator
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.

On Fri, Aug 4, 2017 at 12:28 AM, NicholaiX <[hidden email]>
wrote:

> 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

Talend Community Coder
http://coders.talend.com
Loading...