Understanding WCF Windows Authentication

I have a service with windows authentication. Using the following code, I can get the Windows Identity of the user who (by using the client) consumes the service.

String currentUser = OperationContext.Current.ServiceSecurityContext.WindowsIdentity.Name;

The configuration in the server is:
<binding name="messageSecurity">
<security mode="Message">
<message clientCredentialType="Windows"/>
</security>
</binding>

I also read that in the server, it is using Kerberos for this to work.

Now, I am trying to understand its significance in our corporate network. In the office, users will be logging into their desktops using their active directory credentials. Our service is hosted in a windows server named “SERV1” .

  1. Is only users who have access (to login) to “SERV1” can 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?
  2. Is there a way to ensure that only CIO approved applications will be accessing the service, keeping the service as windows authenticated?
  3. Does this authentication check happen for each service operation call or only for the first call?
  4. Is there any way the service will be able to know the windows credentials of the user?

Note: What I understand is WindowsAuthentication can be compared to a Membership provider – providing username and password from a centralized location. It can be compared to ASP.Net Membership Provider or Active Directory Membership Provider.

Further reading:

  1. ASP.NET Active Directory Membership Provider and SQL Profile Provider
  2. wcf data contracts authorization
  3. http://www.theserverside.net/tt/articles/showarticle.tss?id=ClaimsBasedSecurityModel

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

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

Method 2

  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.


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x