akela_p501usa's profileakela_p501usa's spacePhotosBlogListsMore  |  Tools Help |
|
August 10 Exploring Claims-Based IdentityTraditional Representation of Client Identity That's enough abstract talk; let's see this stuff in action. I'll start with a simple Windows Communication Foundation (WCF) service that accepts either Windows credentials or X.509 certificates from clients. It exposes a single method that takes no arguments, and when called by a client, it prints out details about the client's identity. Figure 1 shows this method, called Hello. In this version, it uses the traditional IIdentity interface introduced in the .NET Framework 1.0 to inspect the client's identity. The first step here is to grab the ServiceSecurityContext for the call, which is how WCF communicates details of the client's identity to a service. I'm careful to check for null, which would indicate an anonymous client. Then I grab the PrimaryIdentity property and dump out its contents. Here's what the output looks like when I configure the sample to use Windows credentials: Primary identity type: WindowsIdentity AuthenticationType: NTLM IsAuthenticated: True Name: GROMIT\Alice
The concrete type in this case is WindowsIdentity, which exposes a lot more information than IIdentity. By downcasting to WindowsIdentity, I'd be able to get a list of the groups of which Alice is a member, get her user SID and use that to look up her user record in Active Directory®, and I might even be able to impersonate her in some circumstances. Now let's run this same example with a different WCF configuration. This time I'll have the client submit an X.509 certificate. Primary identity type: X509Identity AuthenticationType: X509 IsAuthenticated: True Name: CN=SampleClient; 33BB8518E4B7…
The Name property in this case is a combination of the common name in the client certificate and its thumbprint. If you wanted further information, such as the issuer, expiration date, and so on, you might try downcasting to X509Identity, but you'd quickly find that this class is marked internal. But regardless of this limitation, even if you could downcast, you'd be dealing with an entirely different programming model from that in WindowsIdentity. This is one problem that the new identity model solves: it gives you a single programming model no matter what shape of client credential you get. In the next section, I've rewritten the Hello sample to be claims-aware. Read on and see what identity looks like through a claims-based lens. cm codemaker : udkapi NULL |
|
|
