[jira] [Commented] (CXF-8240) STSClient produces wrong element order for TokenType (issue, renew)

["Colm O hEigeartaigh (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17058100#comment-17058100 ] 

Colm O hEigeartaigh commented on CXF-8240:
------------------------------------------

I'm not sure why schema validation would fail, as the schema doesn't mandate an order on RST:

[http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3.xsd]

"Actual content model is non-deterministic, hence wildcard. ". However I'll fix the ordering to conform to the spec anyway.

> STSClient produces wrong element order for TokenType (issue, renew)
> -------------------------------------------------------------------
>
>                 Key: CXF-8240
>                 URL: https://issues.apache.org/jira/browse/CXF-8240
>             Project: CXF
>          Issue Type: Bug
>          Components: STS
>    Affects Versions: 3.3.5
>            Reporter: Sergius Mohr
>            Assignee: Colm O hEigeartaigh
>            Priority: Minor
>              Labels: sts-client
>             Fix For: 3.4.0, 3.3.6
>
>
> Scenario: using STSClient to call a STS server via SOAP. Creating issue request according to WS-Trust spec.
> I have read the WS-Trust sepcs from 1.0 to 1.4 and the elements under RequestSecurityToken should be in this order: TokenType, RequestType, etc.
> see spec: [http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658937]
> {code:xml}
> <wst:RequestSecurityToken Context="..." xmlns:wst="...">
>    <wst:TokenType>...</wst:TokenType>
>    <wst:RequestType>...</wst:RequestType>
>        ...
> </wst:RequestSecurityToken>
> {code}
> STSClient produces in most cases this element order:
> {code:xml}
> <wst:RequestSecurityToken Context="..." xmlns:wst="...">
>    <wst:RequestType>...</wst:RequestType>
>    <wst:TokenType>...</wst:TokenType>
>        ...
> </wst:RequestSecurityToken>
> {code}
>  
> This produces a schema invalid request and is rejected by servers (like MS ADFS or IBM DataPower).
>  
> One Workaround is to override the addRequestType:
> {code:java}
> @Override
> protected void addRequestType(String requestType, W3CDOMStreamWriter writer) throws XMLStreamException {
> 	//correction of the element order: TokenType first and then the RequestType
> 	addTokenType(writer);
> 	setTokenType(null);
> 	super.addRequestType(requestType, writer);
> }
> {code}
> Another Workaround is to set the "template" to STSClient (no documentation found to this, i used OpenSAML3 code for this):
> {code:java}
> MarshallerFactory marshallerFactory = XMLObjectProviderRegistrySupport.getMarshallerFactory();
> RequestSecurityToken requestSecurityTokenObject = new RequestSecurityTokenBuilder().buildObject();
> TokenType tokenType = new TokenTypeBuilder().buildObject();
> marshallerFactory.registerMarshaller(TokenType.ELEMENT_NAME, new TokenTypeMarshaller());
> requestSecurityTokenObject.getUnknownXMLObjects().add(tokenType);
> tokenType.setValue("http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0");
> stsClient.setTemplate(new RequestSecurityTokenMarshaller().marshall(requestSecurityTokenObject));
> {code}
> It's not better.
>  
> Please fix this by moving the calling of addTokenType() method in AbstractSTSClient (in issue() and renew()) to before the addRequestType().



--
This message was sent by Atlassian Jira
(v8.3.4#803005)