WCF sample of asymmetric proof keys

Ignoring RSTs that are self-signed and induce creation of issuer-signed assertions bearing RSA public keys as proof-tokens (typically wrapped for access only by an intended recipient), we see the output of a  WCF sample project:


Notice that the confirmation field bearing the proof token is just a cleartext RSA public key value (its not encrypted that is).

Similarly, note that the signature on the assertion is not supported by a reference or value to a certificate – but cites (the same) public key value.

We seem to be seeing a very early form of SAML, in its initially simple form.

To all intents and purposes , this is a self-signed certificate.

Now we see the programing model, in which the second or nth call reuses the assertion and RSA signing key stored in the credential structure. The first time, we see that the code can create the two. Of course, if we provide the values in the initiated credential, even the first web service call would use our own assertion and signing key.


This code provides a solid backgrounder behind the notion of the genericXmlSecurityToken – and we can see now clearly how things are supposed to work  with proofkeys/securitykeys.


The puzzle pieces are falling into place. We learned to use issuertokenprovider to talk to an STS, using ws-trust suited to requesting asymmetric tokens. We have learned to make a saml credential, that drive ws-security interactions.


About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in SSO. Bookmark the permalink.