The Microsoft ws-trust features of WCF makes life hard – if all you want to do is simple username token versions of ws-trust security – swapping one token for another. WCF wants one to wrap even the act of accessing an STS service itself invoke an instance of ws-trust (forming a bilateral secure channel, over which a RST is sent). This all gets in the way – as so many elements of procedure have to be perfectly specified.
So lets’ document how we made the PingFederate solution do something simple (and quick). All we want to do is have a web services client in an ASP.NET page – hosted in the cloud – make itself a username token, use a local STS service to convert that into a saml token, and then send said token in a SOAP header to a WCF web service that is to interpret the inbound token as part of its access control decision making.
Let’s try to just get a soap-ready saml token minted. First, we use the demo web application supplied for the username token toolkit – to give us “something that works”.
First, install and configure the ping federate server. Simply follow instructions; and then install the “username token” demo web application (into the jboss instance hosting the PF application, too).
The issuing process works out of the box:
Per instructions, paste the “extracted security token” content into a notepad file. Use this file with now a validate “request type”. Don’t forget to change the service url fields value – replacing “idp” with “sp”. Though we could be asking our (SP-side) STS to issue another (binary or saml format) token given the saml token provided as input, here recognize we just want the SP-STS to issue a yes/no answer concerning the validity of the inbound token. Hence, we invoke the validate verb on the SP-STS endpoint.
Since the token signing certificate in the uploaded PingFederate data zip expired in 2012, correctly the STS will return a (negative) verification message – which will raise the associated exception. So, update the certificate. Create a new signing credential with attached certificate and assign it to the ISP-STS’s outgoing “SP connection” – so its used for signing the IDP-minted token. Export the cert to a file, too. Import it into the “IDP Connection”, so the SP-STS can verify many token signature referencing the certificate. Note that when using the web application that now a “valid” report result is issued (vs. an invalid report) upon invoking the validate method.
Now install visual studio 2012 express. Also install Ping Identity’s “.NET toolkit for ws-trust” – which provides two client-side programming libraries that wrap the raw Microsoft-provided “WSE3” libraries. Update the library references in the various build-able projects. Obviously, also download and install WSE3 2012 edition, from Microsoft’s site.
Using the existing unit test project for the libraryies as our baseline, we started with a simpler test – aiming simply to repeat from our programmed client what we just did from the client built into the username token kit’s web application.
Here are a few gotchas to work around – to do JUST that. They are good teachers – showing one how to diagnose issues and solve them with new configuration. All PRACTICAL skills.
We used client side code listed in the library’s help file (see below). It’s configuration doesn’t quite sync with the settings the demo of Ping Federate for username tokens has …for potential clients.So, We made some modifications to the client-side code to align things with those demo settings (see above). We changed the URI domain names (obviously); and then we removed the need for our own client to cite basicAuth credentials to gain access to the server endpoint of the layer 4 transport channel. (I.E. Let’s remove all that which is not needed, since the Ping Federate demo did not happen to require transport-entity authentication.) Obviously, we keep the username and password parameters (!) supplying values for the layer 7 token into which the username and password values are inserted are named fields.
On running the code down to the IssueToken method, the log file of the ping federate server indicates no change – no message is “handled” that is. And, a client-side exception is raised – indicating that the transport channels https/SSL tunnel could not be established (probably because Ping Federate is using a self-signed SSL cert, or because the CN field in the cert does not match what is expected by the client, given the local socket’s report).
We added a new requirement to the client side configuration (allowing the Client to so configure WSE3 so as to ignore certain SSL transport layer errors due to certificate/naming issues):
As a result , we can now form a demo-grade https connection between the client and the PingFederate server. Over https the expected request is now both sent and received:-
The message response emitted by PingFederate server over the reverse https channel causes the client library code to raise an (associated) local exception:
Using the PingFederate console, we augmented the list of user/passwords that the username token password processor can recognize – obviously adding our own “user/password configuration element” to the IDP’s token processor instance.
Modifying the code to cite the new username/password combination, we do now get a back the desired SAML (signed) token :
whose id aligns with the log file in pingfederate – recording its output message:
The log nicely aligns with the client side records – having parsed (and presumably verified the signature of) the returned token.
But, at least something works now works, and we have a clearer mental model on what the library does, what role WSE3 continues to play, what ping federate does in hosting token processes, what the token generator does, and how to configure it all in reality. And it works in a manner that just naturally expresses the protocol one is trying to invoke.
Presumably, we can now go about configuring a WCF service that can process the inbound token.