Understanding WCF Windows Authentication

Can only users who have access (to login) to “SERV1” access the service?

Yes - that's the point of using Windows credentials in a WCF service. Only users which have a domain account in that Active Directory domain (or a separate domain which has a bidirectional full-trust relationship with your domain) will be able to access the service.

Or all users who are able to login to the office network (suing active directory credentials) will be able to consume the service?

The WCF security boundary is the Active Directory Domain - not a particular server.

Is there a way to ensure that only CIO approved applications will be accessing the service, keeping the service as windows authenticated?

How are those "CIO-approved" applications different from others? WCF is accessed by accounts - typically user accounts. You can limit which accounts have access to your service (by e.g. requiring those accounts to be member of a given AD group or something). You cannot really "limit" based on applications (only if those applications use specific application-level accounts to access your WCF service)

Does this authentication check happen for each service operation call or only for the first call?

Depends on your service - if you use a per-call WCF service, then the check happens for each call. If you use a per-session WCF service with "security negotiation" turned on, then the check happens once at the beginning of the session and not anymore until the session ends.

Is there any way the service will be able to know the windows credentials of the user?

Yes - OperationContext.Current.ServiceSecurityContext.WindowsIdentity IS the Windows credentials (the Windows identity) used to call your service. It's a lot more than just the user name.....


  1. That's not an authentication task, that's an authorization task. Kerberos is responsible for ensuring the user is authenticated (the name you get for them is their actual name). LDAP manages authorization. In a Windows context, that means the user should be a member of some permitted-to-access-server-stuff group (and the service must check that this is the case).

  2. Applications? Not really. That is to say, there are two types of authenticated principals in Active Directory: users and computers. But why does it matter what application is being run, if the user doing the running has the permission to connect to the service? Phrased another way, you can't stop someone from using their own code to do exactly what your code would do.

  3. Shouldn't matter. The authentication is working, no? What's actually happening is that the application is being passed a ticket to prove that the user already authenticated (to the KDC, the active directory server).

  4. Yes, the security context is, in some sense, the user's set of credentials. They might also have other credentials, but you can get those too.