Question

We are trying to migrate a legacy intranet ASP .NET web app from “Forms” based authentication into a “Windows” based one so that the user doesn’t have to enter the credentials again after logging into the PC, we just want to read the current logged-in identity and use that for authenticating and authorizing the user in the application.

Doing windows authentication in ASP .NET is pretty straight forward, what i wanted to check though was how the user’s and their groups should be managed within AD or ADAM.

The same user can have rights on multiple environments of the same application like Dev, UAT, LT, Prod etc. so the same domain account needs to be authenticated in multiple environments (different URL). Also, once authenticated into an environment the user might belong to multiple roles which decide what actions are available for the user to perform.

I was looking for some recommendations here in terms of how we set this structure up in AD, we are thinking of creating groups in AD for the different environments like App_Dev, App_UAT, App_Prod etc. and have nested groups within each of them for the different roles in the application like App_Dev\Role1, App_Dev\Role2, App_UAT\Role1 etc. for each of the environments and add the users inside it.

What do you guys think?

Answer 1

You have to rememeber that Authentication and Authorization are two different things. You have combined them in your logic.

For example, your authentication mechanism is AD. So yes, use AD for authentication of credentials and group membership to ensure they can authenticate with a specific instance.

However, you can still use the classic RolesProvider and use a SQL backend to store roles and user to roles assignments per instance within the database. This is easy and uses the built-in feature of ASP.NET without having to go overboard with creating groups in AD. You can do various searches on the web about ASP.NET AD Authentication and SQL Roles Provider. I think ScottGu even has an old article about how to do it.

Lastly, what you have described here is not SSO or Single Sign-On, I’ll update your question to reflect this. SSO refers to creating a token that is trusted and shared amongst many applications. It doesn’t seem like you need that with the example provided, but if you do, you would be investigating ADFS and the Windows Identity Foundation (WIF). Just because you use AD does NOT mean you have SSO, it simply means you have a single Authentication Provider, but you still don’t have a token based system that actually only requires an initial Authentication and Authorization request to a central authentication service, usually ADFS.