If i want to generate a menu structure depending on who is logged in
in an intranet system(using windows authentication) is it better to use the
GROUPS in Active Directory
or to move the Active Directory groups into a Sql Server database and base
the authrorization and authentication on the SQL Server roles/groups?
Whats the best way to make use of the GROUPS in active directory to
authorize
users apart from using web.config where you have to set it configuratively
like below(but i don't want this)
<authorization>
<allow roles="DOMAIN\HRUsers" />
<deny users="*" />
</authorization>
This works if i want to deny users who are not part of the GROUP
"HRUSERS"(Which just denies the URL .aspx page)
Is it possible to store/collect all the Active Directory groups and use it
in code to validate against USERS?
(Apart from storing it in SQL server?)
or
programmatically by doing :-
If Not (User.IsInRole("HR")) And Not (User.IsInRole("Managers")) Then
' Display the Button
Else
' Don't display it!
End If
The badside to these methods is that if you are calling a method several
times from different applications, you will need to repeat the logic all
the time. How can i do it declaratively using Active Directory.
I know if i use a database with stored procedures that would be a benefit.
Any thoughts?
I have to say we move active directory to the SqL server database only when we want to extend the authentication mechanism to an internet environment from an intranet environment, be aware that once you do this you also have to bear responsibility of synchronising your database with Active Directory using a windows service, So if you are ready to write a windows service which will take care of your synchronization its a nice option .
But if this is an application which will be used inhouse or will not be used by more than one customer its not worth it , you could use the system.directory services be ware again this uses COM interop beneath the surface
I hope this gives you enough info .. if you need any more let me know
It is also dependent on is it one for organisation and you know the size of the active directory
I have to say we move active directory to the SqL server database only when we want to extend the authentication mechanism to an internet environment from an intranet environment, be aware that once you do this you also have to bear responsibility of synchronising your database with Active Directory using a windows service, So if you are ready to write a windows service which will take care of your synchronization its a nice option .
My Answer
-----------
Yes i know the synchronising will be an issue and the system is going to be an HR system which security is a main issue
But if this is an application which will be used inhouse or will not be used by more than one customer its not worth it , you could use the system.directory services be ware again this uses COM interop beneath the surface
My Answer
-----------
The system will be inhouse and seriously there is no sense writing a windows service.
I hope this gives you enough info .. if you need any more let me know
It is also dependent on is it one for organisation and you know the size of the active directory
My Answer
----------
Its for one organization and the Active directory should contain lets say 400 users maximum i think if not less
So what do you think should be used in this case..
As i said if i use the web.config and set my Roles configuratively i will be able to have the pages only secured.
But i want to use it in my code..
Any other ideas?
Thanks
With the application size and end user I would say you could use System.DirectoryServices to do the job and avoid SQL Server management.
Now with regard to not repeating logic and doing the job declaratively I have a couple of ideas that might be useful
You do know the Application_AuthenticateRequest method in the Global.asax . In this method you could do something like create a generic principal class that has all the information you want once , then as you know the User object in the System.Web.UI.Page.User is nothing but a pointer to the one in HttpContext so switch the object with your own User object derived from generic principal. Have attached some sample to do the job see if its useful
Another idea is something in the lines of CAS(Code Access Security in .Net 2 not the same but something like that)
Create a custom attribute class which can be applied to all your methods or controls in you web page, And use this attribute to define if the call can be executed or not . Create the instance of custom attribute object for the user in the Authentication request
I seem to have been carried away here , let me know if it is useful
Well in that case you can use the first idea for playing with roles on the windows account, and define roles in your application, these application roles can have permissions on code methods, objects etc etc
Bookmarks