Is there a way i can give permissions based on the groups of active directory in my asp.net web application?

Question

I am trying to achieve the following:

1. Authenticate users against Active directory.
2. If the user belongs to group "A" i want to limit user rights
3. If the user belongs to group "B" i want to have some other logic in my code.

I am able to achieve the first one in the above list.

I am using forms authentication in my web application(Intranet).I did some research and there are various suggestions to use Microsoft Active Directory Application Mode (ADAM) which i m completely unaware of.Is there a way i can achieve the above with out using ADAM? Say suppose get the group list into the code and based on that can i make a call if user belongs to some group and so on..

Is is that i am thinking only on group level which limits my options? Or is there a way other than giving user access rights from group level or am i completely not understanding the concept of Active directory authentication ?

Answer 1

Check this question, it is the same problem though differently described: Validate a username and password against Active Directory?

Either way ActiveDirectory is fully supported within C#, no need for additional systems (I am not aware what ADAM is either).

To check the groups of a username, use this code:

UserPrincipal p = UserPrincipal.FindByIdentity(
domainContext, IdentityType.SamAccountName, userName);
var groups = p.GetGroups();
foreach (GroupPrincipal g in groups) { /* do something */ }

Answer 2

If you are asking about a general architectural or best practices question, I would suggest looking at Claims Based Authentication. In particular Active Directory Federation Services (ADFS).

Basically, it seems that you need to control what a user can do at a more granular level than based only groups. Group membership can sometimes be very broad. For example, not every one in the "Users" might have the same right, not everyone in the "Sales" would have the same access. But then you don't want to create groups such as "Sales - Managers", "Sales - Employees", "Sales - Executives" etc. etc. This quickly becomes unwieldy. And no matter how much time you put into designing the perfect distribution of groups, in a few years it will all change because some subset of the sales managers will be allowed to do something, which other sales managers cannot.

To get around this problem, Claims based authentication is used. Rather than specifying rights at the group membership level you just check in your code whether a user has a certain "Claim". You can go nuts and create as many claims as makes sense for your application. You can have claims like "Can Change Birth Date", "Can Authorize Payment More Than $1000" etc. etc.

The claims are just attached to your user's identity, which is available via the thread's current principle.

Now, how does the user get assigned these "Claims" you ask? Well, if you are using ADFS, anyway you want. You can obviously do it based on AD group memberships. You can do it based on database look ups. You can do it on the time of the day or the month of the year if you so wish.

The point is, now your claim issuing and claim enforcement are completely independent and can change independently without affecting each other. Your code just says "Hey, this guy has a claim that lets him make more than $1000 payments, so I will let him do that. Why he has that claim, I don't know or care". Then your ADFS can issue claims based on any criteria that it sees fit. For example "If user is member of Managers group or has an entry in SuperUsers table in the security Database or is named 'Tim Timsky', he is allowed to spend more than $1000"

So to answer your question about "thinking only on group level which limits my options", it most certainly doesn't have to. If you are starting a new, green fields project, new tools like ADFS would give you a lot of options more easily.

But of course it comes with a caveat, which is that all abstraction has a cost of increased complexity. It is another part you are introducing into your system. You can decouple your application and introduce higher layers of abstraction and functionality. But whether or not that layer is worth introducing depends on how you plan to use the application. If you think that the application will never ever ever have to distinguish between a "Manager" and a "User" then, claims based authentication is an over kill. But if you feel that as time goes on, you will have different bits and pieces of functionality in your application that will need to be assigned to different users based on vague and ever changing rules, then claims based authentication will make your solution much neater.

As always, the net advantage of decoupling two parts depends on how often one changes independent of the other.