Understanding securitytokenmanager and bindings in WCF


I never had a good mental model of how the security apparatus works in WCF.

We see first how the main control point on the server for the developer is the service credential. First configure the cert on the default behavior and then substitute one’s own behavior. It has the same cert assignment but now one gets to set your own securitytokenmanager class.

image

image

The token manager is a recognizer of tokentypes – presented as host opening time. The tokentypes presented depend on the binding assigned to the endpoints of the service (as read from the service definition in web.config). For each token type as part of the opening process, essentially one attaches an authenticator class for that token type

image

image

Because we added the  establishSecurityContext=false property to the message requirements declaration, the host opening protocol no longer asks the manager to bind an authenticator to the “sessiontoken” type of token. Normally, a library authenticator would look after it, in any case. Of course, we still get asked to recognise “http://schemas.microsoft.com/ws/2006/05/servicemodel/tokens/AnonymousSslnego” because we have yet to turn off the “service cert negotiation feature” trying to make things as simple as possible!

image

Ok, so we see how via servicecredentials behaviour we get to control the configuration of tokentype authenticators. Now, the URI for the username token used in the WCF client is NOT the same as the URI found in the WSSE namespace for a usernametoken to be presented in a ws-trust RST, normally. Small gotcha, note: “http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName”.

To react to WSSE namespace username tokens we would have to recognize

image

But we are learning! (or rather, we are learning what folks who learned in the Microsoft WSE era work already know!)

Ignoring stuff about authorization policies (which we can think of as just a container for passing claim sets between the token handers/generators and our service implementation), at the heart of the matter lies the ability to register a class that confirms whether the username/password combo is good (and list some claims as a result). Most of the work is inherited from the windows account checker.

image

Advertisements

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 SAML, SSO. Bookmark the permalink.