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 <[email protected]> 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
