Active Directory Vs Sql Server which way to go?

[Patrick.O.Ige]

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?

[Scott Allen]

Some thoughts:

I'd leave the groups in Active Directory. Administrators become
unhappy when they have to update authorization rules in two places :)
IsInRole works very well for programmatic checks.

Have you looked at the security trimming feature of the ASP.NET 2.0
navigation system? Or is this in 1.1?

--
Scott
http://www.OdeToCode.com/blogs/scott/
On Fri, 4 Nov 2005 20:25:37 +1100, "Patrick.O.Ige"
<pa********@optusnet.com.au> wrote:

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?

[xhead]

We use Authorization Manager (available standard in Windows 2003 and as
a download for Windows 2000) which takes the whole role management
thing out of the application altogether.

You still organize authorization by users and roles and such, and it
links into Active Directory, but what it boils down to in the
application code is a check for a certain task or operation and if the
current user is allowed to do that or not

Authorization.CheckAccess("taskIdentifier",current Identity) as Boolean

You define the task identifier strings in Authorization Manager (AzMan)
as a developer task, then assigning all the permissions to those tasks,
organizing them into roles and such, becomes an administrative
function. The real benefit here is that you can change what it means to
be a member of "Admins" or "Managers" outside of the application, and
the app behaves accordingly, without a recompile.

So, when you build your menu structure, call the authorization manager
for each menu item (use a nice naming convention that corresponds to
the tasks defined in AzMan) and ask if the current user is allowed to
do that task or not, and decide to add it to the menu structure or not
(or enable/disable).

Enterprise Library has an authorization piece that leverages AzMan.
There are lots of samples out there if you google AzMan and .NET or C#.
Mike

[Patrick.O.Ige]

I know that its actually like re inventineg the wheel.
I don't think the trimming navigation system is in ASP.NET 1.1.
In 2.0 i think.
Thx Scott
I'm looking at using Authorization Manager if all goes well
"Scott Allen" <sc***@nospam.odetocode.com> wrote in message
news:9f********************************@4ax.com...

Some thoughts:
t
I'd leave the groups in Active Directory. Administrators become
unhappy when they have to update authorization rules in two places :)
IsInRole works very well for programmatic checks.

Have you looked at the security trimming feature of the ASP.NET 2.0
navigation system? Or is this in 1.1?

--
Scott
http://www.OdeToCode.com/blogs/scott/
On Fri, 4 Nov 2005 20:25:37 +1100, "Patrick.O.Ige"
<pa********@optusnet.com.au> wrote:

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 theGROUPS in Active Directory
or to move the Active Directory groups into a Sql Server database and basethe 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 configurativelylike 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 itin 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?

[Patrick.O.Ige]

Mike thx alot fr the reply.
I will look into using this .Well the good things is that i can use it on
Win 2000 beacuse i don't think they have WIN2003 yet.
Patrick
"xhead" <xh******@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

We use Authorization Manager (available standard in Windows 2003 and as
a download for Windows 2000) which takes the whole role management
thing out of the application altogether.

You still organize authorization by users and roles and such, and it
links into Active Directory, but what it boils down to in the
application code is a check for a certain task or operation and if the
current user is allowed to do that or not

Authorization.CheckAccess("taskIdentifier",current Identity) as Boolean

You define the task identifier strings in Authorization Manager (AzMan)
as a developer task, then assigning all the permissions to those tasks,
organizing them into roles and such, becomes an administrative
function. The real benefit here is that you can change what it means to
be a member of "Admins" or "Managers" outside of the application, and
the app behaves accordingly, without a recompile.

So, when you build your menu structure, call the authorization manager
for each menu item (use a nice naming convention that corresponds to
the tasks defined in AzMan) and ask if the current user is allowed to
do that task or not, and decide to add it to the menu structure or not
(or enable/disable).

Enterprise Library has an authorization piece that leverages AzMan.
There are lots of samples out there if you google AzMan and .NET or C#.
Mike