Integrated Security with Web Application

Introduction:

Guys, I've just finished setting up my first application using integrated security, and I thought I would share a few things Which I have learned along the way.

In active directory, the various groups and users are all clubbed in OUs or "Organizational Units." Within an OU, you will find other OUs or Groups. The groups are in various types. You can set up "Role Groups" with a GSGu_ prefix and you can set up "Resource Groups" with a GSLapaFC_ prefix.

Now to play with this active directory using integrated security we will follow the following pattern in our coding. You put users into Role Groups and you put Role Groups into Resource Groups. There are a number of reasons why you should mind this recommendation, not the least of which is that the AD people want us to follow this as a "best practice."

What Is Role Groups?

Role Groups will have the User IDs of users who either have the same sort of job function or are in the same department, for example. Suppose there is a Admin role which will have all the functions like Update, Delete etc then we will have all the User Id in this Role Group who will have an rights to Update, Delete the records.

What Is Resource Groups?

Resource Groups contain all the role groups that should have access to the "Resource" that the resource group represents -- this may be an entire application, one page in a web app, or even just a small group of controls on a page someplace. The main point is that for each thing that you want to explicitly limit access to, you'll want to create Resource Group to represent it.

So till now you have gone through all the information now you need to implement the same so let's see how to implement.

Create the OU which will store all the Role Groups: Eg : OUg_Functions.
You can specify whatever name you want to give.
After that Create all the Role group according to Role under OUg_Functions.
The naming convention will be GSGu_ApplicationName_Role Eg : Gsgu_Banking_Delete.
Then Add the users in this Role group.

In the above part we created the Role Groups .Now lets see how to make the relation between this Role group and Resource Group.

As I mentioned ,Users will get added in Role Group and Role Group will get added in the Resource Group.

I think there should be at least one resource group that represents the entire application as a whole. Then there may be many other resource groups that control access to different areas within the application.

Lets take an example. In my application there will be Delete, Add, Modify functionality. Now I will create three Role Group as Gsgu_BACR_Delete, Gsgu_BACR_Add, Gsgu_BACR_Modify. Next thing I will add the users who will have Delete Functionality in the Gsgu_BACR_Delete Role AD.

Next thing I will add this Role to Resource group which will be GSLapaFC_BACR_Delete.

There might be possibility that there will be only one user who will have all the three rights. So in that case we can create only one Role group and add that into one Resource group. Because of that we need not to add the same user three times in three different groups.

Once you've got access to active directory and your've created role groups (and added users to them and created resource groups (and added role groups to them), you have to do a number of things to get your application using this info to enforce security.

In web.config, you'll need these settings:

<add key="AuthIgnoreSecurity" value="False" />
<!-- "Web.Config" or "Active Directory" -->
<add key="AuthGroupLocation" value="Active Directory" />
<add key="AuthActiveDirectoryServer" value="LDAP://DC=corpdev,DC=TS-DEV, DC=net" />
<add key="AuthMode" value="Windows" /> <!-- "Forms", "Windows" -->
<add key="AuthTicketDuration" value="30" />
<add key="AuthWindowsCookie" value="BatchControlCetner_WindowsAuthCookie" />
<add key="AuthResourceGroupPrefix" value="GSLapaFC" /> <!-- needed when going against AD -->

We're still looking into the implications of changing the LDAP string so that it starts at a location lower in the AD hierarchy. The example I have here is right at the top.

You'll want to make sure that the value of the AuthWindowsCookie key is different for each application you build to avoid some conflicts between applications.

You need to put some code in Application_AuthenticateRequest in global.asax in order to initialize the security for your app -- it uses the settings in the web.config above and results in a couple of important things: The creation of the windows authorization cookie and the attachment of a string of permitted resources to Context.User in your web app. We only have to hit AD once to build the list of resources for which a user has permission and then we store that information for use by the AdSecurity class.