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.
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
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!
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
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.