AzMan Still the way to go?

[John Graham]

I've been reading a bunch on the Roles based set-ups people are using,
and am sort of at an impass. Meaning, I need to stop reading and start
coding.

Brief background, I am starting fresh with an intranet, and was
planning on having the whole site use IIS windows authentication.
However I keep reading about folks still using the Form login with
windows authentication, am I misunderstand how they are implimenting
their setups?

I've started playing around with AzMan, and as I understand it, it's
simply just a connection between a person's AD account and what roles
they are assigned to. Correct? If that's the case, why use an
enternal XML file for AzMan? Couldn't that be stored in SQL? or is it
better to have the portability of the XML.

I'm hesitant to jump in with both feet without having the security in
place.
John

 

[MikeS]

AzMan us seriously over built (tasks, operations) for just ASP.NET
roles but it works well for them none the less.

I think the xml option is for developers to use in dev before they are
let into AD in a live domain.

For an intranet site, NT auth and a seamless login is a nice feature,
having already authenticated users have to re-key credentials is
annoying.

You can always, later on, put up a form based auth site that issues an
auth ticket, using the same machine key, validated against some other
membership store, and redirect to the formally intranet only site if
you want to let non domain users in. You can also do this in reverse to
let domain users into an internet site, that is an NT auth site issuing
a ticket to get into a forms auth site.

And yes, you can use the SqlRoleProvider instead and that is the
default for the toolset and should work fine. But if your shop standard
is to keep it all in AD you use AzMan for application defined roles or
the WindowsTokenRoleProvider to use NT groups.

 

[MikeS]

A couple of downsides about AzMan. It uses com interop so I think your
site will required full trust. It is AD based and AD in not immediate
like sql depending on the topology and replication. And because of
those, it is finicky, Be prepared for lots of "the parameter is
incorrect", "system.io not found", and other odd exceptions that are
propagated very poorly from the interop layer or wherever. And be
prepared to point at a single AD server and not the domain if you
expect your roles to be visible instantly (same goes for AD membership
users). Just my $0.02.

 

[Joe Kaplan]

The main idea with AzMan is the concept of programming against operations.
Operations are very granular things that should have no overlap in usage.
By grouping operations into tasks and tasks into roles and then mapping
principals (users and groups) to roles, you have a very power model for
defining authorization in your app. Since you program directly to the
operations, your code doesn't need to know what roles a user has and that
can be changed by the administrator at runtime. In fact, someone could
define a completely different set of roles to consume the operations you use
in your code and you wouldn't need to change any code at all. That's where
the real power lies.

The main idea behind the XML store is that you need a place to store the
authorization policy and not everyone can stick it in ADAM or AD. Because
it is a hierarchical data model, XML makes good sense as a file-based
storage mechanism. If you were just storing a list of roles, then it
wouldn't be as compelling. Having a text-based file as the policy store
makes a lot of sense from a source control standpoint as well.

Whether or not you have enough authorization to do to warrant AzMan is
another question. It is a powerful model, but it is also complex and is
probably overkill for simple things. If you just have a role or two and the
operations they protect don't overlap or aren't likely to change, then it
probably isn't warranted.

Another nice thing about AzMan is that it supports arbitrary principals, not
just Windows users. For your application (intranet), you'll probably be
most interested in consuming Windows principals for security, but lots of
other people need to store their users in SQL and/or ADAM, and having that
flexibility is very helpful.

Joe K.

 

[MikeS]

Yes sir, no disrespect of AzMan intended. Thank you for the bigger
picture, I appreciate it. I see the capability of AzMan.

As I implied and as you stated, it may be overkill for things like...
IsUserInRole("joe", "god")
and...
IsUserInrole("mike", "codemonkey").

I have to look at my Boston 2006 DVD's and catch up on the WWF
(!wrestling) sessions I missed but I have to assume AzMan figures in
there.

I have never been able to get ADAM to work with AzMan using the ASP.NET
auth store role provider and the AD membership provider, I know there
is some anecdotal evidence of this being possible but it eludes me. I
think I finally decided I needed the auth store provider source code
since I figured it wasn't creating the context properly, or something,
it's been awhile.

 

[Joe Kaplan]

Certainly. I was just trying to answer the question a little diffierently
by pointing out the way AzMan is intended to be used and what the point of
the policy stuff is. I think your points are good and well taken.

I'd actually like to understand the membership provider stuff a bit better
as well, especially the AD version. I wrote a book about DS programming,
but we purposefully skipped that and I never had a chance to get into it, so
I see a lot of the problems that people have with it and I still don't know
the answers. The fact that ADAM should work as a user store doesn't mean
that it is particularly easy to do.

I see similar struggles with AzMan, such as the errors you mentioned in your
other post, and don't usually know what the problem there is either
(although it is almost always an issue with security context).

Whether or not I'll actually get around to any of this is hard to say. I'm
spending most of my time these days with ADFS or general .NET development
stuff.

Joe K.

 

[Dominick Baier]

There is also a new whitepaper:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetserv/html/AzManApps.asp

and Keith's excellent roadmap

http://msdn.microsoft.com/security/identityaccess/

 

[John Graham]

Thank you all very much for the dialog. I already have Azman up and
running on my test box, but given the discussion and my novice skill
level, I think I'm going to take a step back from AzMan and use the SQL
Role provider, and AD for the authentication.

I just got Stefan Schackow's .net 2.0 Security, membership and Role
Management Book and I'm going to dive into that also for some best
practices.

 

[Joe Kaplan]

Stefan is the man. He was one of the key guys on membership.

Your approach sounds reasonable. If provisioning the roles in SQL becoms a
problem due to the need to keep AD and SQL in sync in order to associate
users with roles, you might also consider using AD group membership for
roles. You can also just use Windows authentication in IIS instead of the
AD membership provider if you don't need forms-based authentication for your
application. That depends a lot on what the deployment model is, whether
you can use IWA to get SSO, the look and feel you want, etc. If you can
avoid using forms auth and the membership provider, I would.

Best of luck!

Joe K.

 

[Dominick Baier]

If it is an intranet app i would def. go for integrated auth. This is the
most powerful option...

I don't like membership. For roles you can still add app defined roles to
your users...

 

[John Graham]

Joe, I'm still waiting for my book to show up so I'm sort of stalling.
However from reading your previous note, I think I'm getting a bit
overwhelmed with information. (meaning confused)

I can use windows authentication IIS, and was actually planing on it.
That explains my confusion, because everything is form based, and I
have been trying to just use the Windows authentication in IIS for
initial authentication and then look at a mixture of what AD groups,
and what sqlRoles they are part of to determine what they see. Maybe
that approach is to complex and I should eliminate something in there.
I'm just not sure what approach to take.

I know I can do IWA.... SSO would come along with that also. I guess
that leaves me back with, most of the documentation is for forms.
Maybe that book will give me a better 101 level understanding of which
approach to take.

(leave to go check the mail...where's that book)

 

[Dominick Baier]

Well - you find that much info about IWA in Stefan's book - it is more about
the providers.

The good thing with IWA is, that you turn it on and it just works - you don't
need any code. IIS does all the heavy lifting -

here's you'll find a lot of info on how to integrate with Windows security
- unfortunately you'll have to wait some more weeks for it...

http://www.microsoft.com/mspress/books/9989.asp

 

[Joe Kaplan]

Agreed with D. His book should be very good too. I'm looking for it. I
like mine too, but it is really only appropriate if you need to do LDAP
programming, and I'd say that isn't needed here.

The thing to know with Windows authentication (IWA in IIS) in ASP.NET is
that the user will be authenticated by the OS and your code will be given a
WindowsPrincipal object representing the authenticated user. The
WindowsPrincipal contains the user's name and their groups. You can check
the groups directly for authorization by doing IsInRole.

If you want to create a mapping between the principals in AD (users and
groups) and your application-specific roles, that is one thing that AzMan
shines at. However, it is also big and complex and may be overkill. A very
simple approach is to create a simple mapping between AD groups and your
application roles and then create a new GenericPrincipal object in the
Authenticate event handler of global.asax that simply reads the users
groups, figures out which mapped application roles they get, and then
creates the appropriate array of roles to feed into the GenericPrincipal
constructor. After that, the rest of your code can authorize based on the
application-specific roles. This type of approach is basically like a poor
man's AzMan, where you have to implement the storage of the role mappings
and the implementation of the role mappings yourself and don't get the
advantage of having the powerful role/task/operation model that AzMan
supports. The benefiit is that there is no black box and you understand
exactly how everything works. The downside is that you may have to write
more code, won't get a pretty UI for maintaining the mapping policy for
free, and have less abstraction in your model, which may mean that your code
ends up being harder to maintain. It is all trade-offs.

It may also be possible to use the SQL role provider to get some of this
functionality; I'm not sure how it integrates with Windows auth. The thing
you want to try to avoid is storing all of your users in SQL, as that will
create a maintenance nightmare with keeping the data in sync with AD. Ick!

Joe K.

 

[John Graham]

I follow that IWA, "just works" but does it still allow me to tie roles
in with AD accounts. That in essence is the big question for me then.

 

[John Graham]

I follow that IWA, "just works" but does it still allow me to tie roles
in with AD accounts. That in essence is the big question for me then.

 

[John Graham]

I follow that IWA, "just works" for securing a site as a whole, but
does it still allow me to assign roles using AD accounts? From my
earlier reading that was why I needed AzMan.

It's really a pretty basic set-up.

Intranet with 9 depts, those are in AD and I can apply AD groups to
those. Then there are application specific tasks such as business
office budgeting, where only a select few should have access to, and
that is nested within one of the 9 departments. For the sake of
managing a simple hiearchary I'll probably create a Section at the
first level that just shows app level tools based on their associated
roles.

 

[MikeS]

I think I am the one who stepped into this pond and muddied it.

Since it is a Windows domain intranet you will not use membership you
will user IWA.

So that is <authentication mode="Windows"/>

And you will want authorization.

<authorization>
<deny users="?"/>
</authorization>

No un-unauthenticated users allowed.

You will use <allow role="domain\group">, <deny user="*"> in web.config
location tags or in sub directories web.configs to protect content.

If you ever only want to add <allow role="domain\group">, <deny
user="*"> in location tags or in web configs in sub directories you
will not need a role manager.

You will need a role manager if you ever want to call IsUserInrole (and
other roles.* methods) in your code. Calling IsUserInrole is not needed
for protecting content but only on the fly decisions inside aspx pages.

So really, you need no providers to require authenticated users on a
Windows domain intranet site and to protect content based on the users
domain group membership.

If you want to use IsUserInRole (and other roles.* methods) you will
need a role provder.

Something like...

<rolemanager enabled=true>
<providers defaultProvider="SQLRoles">
<add name="SQLRoles" type="SQlRolePRovider"
ConnectionStringName="A connection string section entry name"
..../>
</providers>
</rolemanager>

You can install just the sql role manager tables and procs on
SQLEXPRESS or MSDE or SQL server using aspnet_regsql

Something like

aspnet_regsql -E -A r -S .\sqlexpress

Note that the windows toke role provider is seriously under implemented


http://msdn2.microsoft.com/en-us/library/system.web.security.windowstokenroleprovider_members.aspx

And therefore not suitable for on the fly role management. So if you
need to be adding and removing folks to and from roles on the fly you
use must SQL or AzMan, or role your own.

I think that maybe the site map provider with security trimming enabled
and therefore the menu controls don't need a role manager either. They
should just work.

So you can get a pretty decent secure intranet site working with no
providers.

Or you can do a tad more work and get more fancy, like letting the
users themselves manage who can and can't get at their sections by
using the rolemanager features (instead of them having the help desk
to it for then in AD in NT groups).

Clear as mud?

Thanks for your patience.