Can AD provide my Win desktop application with credentials for my web services?

Question

I have a working c#/dotnet Windows desktop application that does its work by hitting various web services in my web application. When the desktop application starts up, it prompts the user for username / password and then hits my login web service, which returns a session token.

I have a large-org customer with many users. That customer wants to provide authentication / authorization for my combined desktop / web application directly from their domain controller. They want single signon, so my desktop app doesn't prompt their users for usernames and passwords.

How can my desktop application retrieve a usable authentication / authorization token from Windows (maybe from the user's Security Principal object)? How can my web application validate that token so it can trust the desktop application and send it a session token?

(My web application runs in my environment, not in the customer's domain.)

With pure-web-app customers I do this successfully with SAML2 and Active Directory / Federation Services. The SAML2 dance gets my user's browser to POST a request to the customer's AD/FS server, which then POSTs a signed response back to my web app.

But I can't figure out how to do it cleanly from a desktop application. Any wisdom?

Answer 1

You can check this samples in github (by jelledruyts): Modern claims-based identity scenarios for .NET developers

It has samples of authentication and authorization using Azure Active Directory and/or Windows Server Active Directory Federation Services.

---

I suggest read this article Digital Identity for .NET Applications. It's a little old but is a good overview/review.

Tokens come in many different formats. For today’s .NET applications, however, three kinds of tokens are most important. They are the following:

1. User name/password token—This very simple token contains only two claims: the name of some subject and that subject’s password.
2. Kerberos ticket—More complex than a user name/password token, a ticket includes a subject’s name, the name of the subject’s Windows domain, and other information. Kerberos tickets that are issued by Active Directory also include an extension that contains security identifiers (SIDs) that identify the subject and the groups to which this subject belongs.
3. SAML token—The Security Assertion Markup Language (SAML) is an XML-based language that is owned by the OASIS multivendor standards group. Unlike the other token types that are described here, a SAML token doesn’t have a fixed set of claims defined for it. Instead, this kind of token can contain any claims that its creator chooses.

---

As soon as the claims are available, they can be used by Windows, the application, or both. The most common uses of claims include the following:

1. Authenticating the user(...)
2. Making an authorization decision(...)
3. Learning about this user(...)

---

Kind of Authentication:

1. Domain Based Authentication (eg Kerberos tickets):

A domain-based application accepts only a single token format with a fixed set of claims. One common example is a Windows application that accepts only Kerberos tickets. This kind of application is easy to create, and it works well inside a single Windows domain. The problem is that this simplistic approach to digital identity is no longer sufficient for many applications

2. Claim Based Authentication (eg. SAML tokens):

Unlike a domain-based application, a claims-based application can potentially accept multiple token formats with varying sets of claims. The token formats and claim sets that this application accepts are determined by the application itself.

---

Identity Technologies

• Active Directory (AD) Domain Services (full-featured directory service, token source for Kerbero tickets, etc)
• Active Directory Federation Services (ADFS) (support for claims-based applications, token source for SAML tokens
• Windows CardSpace
• Active Directory Lightweight Directory Services (subset of AD services)
• Identity Life-Cycle Manager (ILM) (synchronization between different identity stores)
• Windows Authorization Manager (tools for RBAC - role-based access control)
• Active Directory Rights-Management Services (RMS)

---

Because AD Domain Services implements Kerberos, the default token in a Windows environment is a Kerberos ticket. To use this default, an ASP.NET application specifies Windows Integrated Authentication, while a WCF application uses an appropriate binding, such as NetTcpBinding. In either case, the following figure illustrates how a Windows application with clients in the same domain might use a Kerberos ticket and AD Domain Services

---

First versions of AD FS only support SAML with web clients.

ADFS 1.0, supports only browser clients—a restriction that’s scheduled to change in the technology’s next release.

Hope it helps.

Answer 2

I should preface this with the fact that I've never done this, so I can't give you exact code, but I can point you in the right direction.

You should be able to do this with ADFS and Windows Integrated Authorization (WIA). In a "pure web app", the browser sends the credentials of the currently-logged-on user during the authorization step. In your case, your desktop app needs to do everything that the browser would normally do. Either way, the setup on the web service side should be exactly the same.

In C# with HttpClient, this is the important part:

var httpClient = new HttpClient(new HttpClientHandler() 
                  {
                      UseDefaultCredentials = true
                  });

Then, whenever your httpClient sends a request that is challenged with a 401 response, it will automatically resend the request with the user's Windows credentials. This is exactly what a web browser would do. So use that when you get the token.

You may have to send a user agent string in the request, since ADFS seems to limit WIA to certain agents.

Once you have a token, then use the token in your requests to the web service.

The key is that you're replicating what a browser would do. So if you have trouble setting up what the HTTP requests should look like, then access a GET request in your API from a browser and use the browser's dev tools to inspect exactly what the traffic looks like, and use that information to replicate the same request in your code.