suggestions: AD, integrated auth, custom Roles

[SpaceMarine]

hello,

i am working on intranet web apps in an AD windows environment.
authentication is done via Integrated Windows Authentication.

i have several apps and need to devise a solution to allow admin-users
to create & manage user roles (permissions). things like:

App1-Read
App1-Write
App1-Admin

App2-Read
App2-Write
App3-Admin

....etc. in v1.1 i always did this w/ a roll-yer-own user/role manager
on a SQL backend.

in the 2.0+ world, i was wondering what the options are... 3 main
questions:

1) is this what Role Providers are for? i have found one that allows
me to use a SQL database and stores roles in it. im assuming i still
have to create my own UI for it tho?

2) or, is this the sort of thing to place directly into AD? can i
write code-behind to insert/update/delete custom roles such as these
into AD, and assign/remove users from them?

3) is there a way for me to do user-searches against AD? if i write my
own role manager, i need to write code to allow admin-users to specify
*which* AD users they are assigning roles to.


any sort of suggestion would be appreciated.

thanks!
sm

 

[Joe Kaplan]

Using AD is an option here. With Windows integrated auth, the app already
"knows" what groups the user is in by way of the WindowsIdentity object
created by ASP.NET as part of the login. As such, you don't need your own
lookup code.

It is definitely possible to build a UI to manage group memberships, but you
might also consider just having the admins use the standard tools that come
with AD for managing groups like ADUC.

It is also possible to store roles in SQL as well. You would likely need
some sort of UI for managing this, but the role provider framework does make
this much easier.

To me, the big decision here is whether it would be acceptable to use AD
groups for roles or not and that usually boils down to organizational
politics. Since you are already using Windows auth in the app, it is
definitely the path of least effort.

Joe K.

 

[SpaceMarine]

Using AD is an option here.  With Windows integrated auth, the app already
"knows" what groups the user is in by way of the WindowsIdentity object
created by ASP.NET as part of the login.

yep. i am using this already for a broad-level authorization check (im
in a big org; but all of my users are in one Group in AD). that is
good, but not enough, of course.

It is definitely possible to build a UI to manage group memberships, but you
might also consider just having the admins use the standard tools that come
with AD for managing groups like ADUC.

well the problem is, i have many apps, as do other devs. our admins
arent really keen on being our app managers, nor do i want them to. i
prefer creating a web UI so my admin-users can manage themselves. also
it seems like a lot of mucking in our global AD for something that is
really only useful for me and my apps. a more localized solution sits
better w/ me.

It is also possible to store roles in SQL as well.  You would likely need
some sort of UI for managing this, but the role provider framework does make
this much easier.

yep, this is how i used to do it in the v1.1 days (sans provider, roll-
yer-own). i see the SqlRoleProvider, but im not certain if it can be
used w/ Windows Authentication (since there is no userID from an SQL-
based auth provider). i may be incorrect about this, however. do you
know?

and the WindowsTokenRoleProvider is out because its read-only, cant
create new roles.

i found some articles on MSDN, and it seems that for an intranet app
w/ AD, they suggest using the AuthorizationStoreRoleProvider and the
"Authorization Manager", aka AzMan. its designed for app-specific
custom roles, supports NET's Roles Manager API, and can be configured
to use one of three policy stores:

1) an ADAM server instance

http://msdn.microsoft.com/en-us/library/ms998331.aspx

2) an .XML file

http://msdn.microsoft.com/en-us/library/ms998336.aspx

3) AD

...this sounds like just what i need, no coding required. plus AzMan
supports more granular roles, in the form of Tasks and Operations.

im going to try w/ the .XML solution first because it seems easier
and more self-contained than installing an ADAM instance. plus XML is
of course programmable and easy to back up.

this will allow me to build web-based UI that uses the Role Manager
API.


now -- heres hoping it actually works

matt

 

[SpaceMarine]

i found some articles on MSDN, and it seems that for an intranet app
w/ AD, they suggest using the AuthorizationStoreRoleProvider and the
"Authorization Manager", aka AzMan. its designed for app-specific
custom roles, supports NET's Roles Manager API, and can be configured
to use one of three policy stores:

...

2) an .XML file

http://msdn.microsoft.com/en-us/library/ms998336.aspx

...I've implemented AzMan, using the .XML-based authorization store.
Very easy.


sm

 

[SpaceMarine]

yep, this is how i used to do it in the v1.1 days (sans provider, roll-
yer-own). i see the SqlRoleProvider, but im not certain if it can be
used w/ Windows Authentication (since there is no userID from an SQL-
based auth provider). i may be incorrect about this, however. do you
know?

i also implemented this via the SqlRoleProvider, using a SQL Server
2005 instance. it works, but when using Windows Authentication you do
not get to use VS.NET's built-in user manager UI.

so now I have both the SqlRoleProvider and
AuthorizationStoreRoleProvider (AzMan) working... dont know which is
best, yet. Azman has a slight advantage in that its very compact and
one can use its MMC snap-in UI; plus it has more granular sub-role
support for tasks & operations. but the SqlRoleProvider is nice in
that I can easily add its db instance to our data-recovery plan.

decisions..


sm