All geek questions in one place

How to create a .NET client for the wso2 secure token service

I need to create a .NET client for the wso2 secure token service.

Normally I would create a simple console or WinForm project by adding a link to the service to it. An open WSDL will be converted to a set of classes that I can use to request a service and to properly manage its response.

Unfortunately, the generated request and response classes are empty: just declaring the class without any property or method. This is similar to the behavior described in this other (unanswered) stack overflow question.

I found a sample request for a service on this forum: http://cxf.547215.n5.nabble.com/Sample-STS-Client-tp4643980p4664175.html , and I made it work with the SOAP interface.

Is there a correct and possibly automatic way to recreate the complex data structure needed to request a Secure Token service?

EDIT

OK, after many attempts, I reduced the SOAP request from the above forum message to the minimum structure needed to receive the RequestSecurityTokenResponse request from STS.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsse:UsernameToken wsu:Id="UsernameToken-6D35592DCDDA26FFF3141578725699577"> <wsse:Username>USERNAME HERE</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">PASSWORD HERE</wsse:Password> </wsse:UsernameToken> <wsu:Timestamp wsu:Id="TS-6D35592DCDDA26FFF3141578725699576"> <wsu:Created>2014-11-12T10:14:16.995Z</wsu:Created> <wsu:Expires>2014-11-12T10:16:16.995Z</wsu:Expires> </wsu:Timestamp> </wsse:Security> <wsa:Action soap:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</wsa:Action> <wsa:MessageID soap:mustUnderstand="1">uuid:6d4eab69-77f9-42b7-8d6b-1f710020fb0b</wsa:MessageID> <wsa:To soap:mustUnderstand="1">STS ENDPOINT ADDRESS HERE</wsa:To> </soap:Header> <soap:Body> <wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"> <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType> <wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType> <wst:Claims> <wsid:ClaimType Uri="http://wso2.org/claims/userid" xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/identity"/> </wst:Claims> </wst:RequestSecurityToken> </soap:Body> </soap:Envelope>

I got partial success defining in app.config of my project either one wsHttpBinding, like the following:

  <wsHttpBinding> <binding name="SendUsername" messageEncoding="Text"> <security mode ="TransportWithMessageCredential"> <message clientCredentialType ="UserName"/> <transport clientCredentialType ="Basic" /> </security> </binding> </wsHttpBinding>

with or without CustomBinding:

 <customBinding> <binding name="wso2carbon-stsSoap12Binding"> <security defaultAlgorithmSuite="Default" authenticationMode="IssuedToken" requireDerivedKeys="true" securityHeaderLayout="Lax" includeTimestamp="true"> <localClientSettings detectReplays="false" /> <localServiceSettings detectReplays="false" /> <issuedTokenParameters keyType ="SymmetricKey" tokenType ="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"> <issuer address =STS ENDPOINT ADDRESS HERE binding ="wsHttpBinding" bindingConfiguration ="SendUsername"/> <claimTypeRequirements> <add claimType ="http://wso2.org/claims/userid"/> </claimTypeRequirements> </issuedTokenParameters> </security> <textMessageEncoding messageVersion="Soap12" /> <httpsTransport /> </binding> </customBinding>

In both cases, however, the request throws a timeout exception and checks using the WCF trace for the issued request, I see that the Claims element is missing. Any hints?

+6
source share
2 answers

After many days involved with configuring WCF, I got partial success.

The key that allows me to get a response from the security token service is that I realized that in the long run I will need to work in a federated security scenario. I do not need a token as such, but I need it to get the authentication value for other services.

Given this opportunity, I began to study what WCF has to offer for such a scenario, and I built the following configuration parameters:

  <wsFederationHttpBinding> <binding name="fs"> <security mode="TransportWithMessageCredential"> <message issuedKeyType="SymmetricKey" issuedTokenType ="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"> <issuer address = <!-- STS address here --> binding ="customBinding" bindingConfiguration ="StsBinding"/> <claimTypeRequirements> <add claimType="http://wso2.org/claims/userid" /> </claimTypeRequirements> </message> </security> </binding> </wsFederationHttpBinding>

The above binding is used to communicate with a service that needs token authentication, while the following adds additional instructions on how to contact the security token:

  <customBinding> <binding name="StsBinding"> <textMessageEncoding messageVersion="Soap12WSAddressingAugust2004"/> <useManagedPresentation/> <security authenticationMode="UserNameOverTransport" includeTimestamp ="true" keyEntropyMode ="ServerEntropy" securityHeaderLayout ="Lax" messageSecurityVersion="WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10" > </security> <httpsTransport authenticationScheme ="Basic"/> </binding> </customBinding>

In this configuration and using Fiddler and WCF tracing, I see that I get a security token response from the STS issuer.

However, as I said, in the beginning, it was only partial success, because the WCF infrastructure, when processing the token, says that it has the wrong action ... but this may be a subtask of another issue; -)

I hope this can be considered the right answer, although my search for authentication by token has not yet been completed.

+2
source

Source: https://habr.com/ru/post/977971/

More articles:


All Articles