In one of our recent projects, we were managing data back and forth between two websites: one set up for an intranet with Active Directory authentication and the other set up to face external traffic with Identity authentication. In the project, a need arose to authenticate a user from the Active Directory intranet site on the external site using the Windows Identity Foundation. But there were two catches:

  • we didn’t actually want to create a new user on the external site
  • this user would have very limited functionality

The solution we came up with was to generate and save a token from a user authenticated with Active Directory, then send them over to the external site with the token. The token would be validated and the user would be authenticated using custom Identity Claims.

Why did we have to go this route?

It may be possible to authenticate an anonymous user with Identity in some scenarios and get claims without actually logging in a user, but after configuring our Identity setup (specifically the use of the IUserSecurityStampStore interface, which required a real user with a real security stamp), it became necessary to go the custom claims route. Below, I’ll describe the steps needed to authorize a user using a custom claims-based Identity and a couple different ways we used this approach.

Solution

To get started, I created an empty web application project and installed the Identity Samples Nuget package – this comes with MVC and the Identity boilerplate (introduction to MVC and Identity).

home page

Then modified the Log in page to accept a token value as an alternative method to username and password.

login page

Note: In practice for us, the token value was sent with a specific URL with Web API, but the method used here is sufficient for this demonstration.

Next, I added a POST method to get the token login, verify the validity of the token, and authenticate the user.

And finally, with the token verified, we create the ClaimsIdentity object needed to sign in with Owin’s Authentication Manager. There are a wide variety of claim types that can be associated with an Identity, but here we only use NameIdentifier, Name, IdentityProvider, and a custom “UserType”.

Now if the token is valid, the application will recognize the user as logged in and, in this case, pull the username out of the Identity.

logged in

From here we can give the user access to the full site as an authorized user, or we can limit the user’s accessibility by checking the Identity…

and redirecting them away…

or signing them out entirely…

Conclusion

The use cases that merit this type of situation may arise infrequently, but as we found out recently, they do arise. It’s nice to know we can bend the out-of-the-box authentication tools to our will and still take advantage of the benefits.

If you’d like to try this out yourself, here are the project files.

Share This