AzMan Still the way to go?

Discussion in 'ASP .Net Security' started by John Graham, Aug 24, 2006.

  1. John Graham

    John Graham Guest

    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
     
    John Graham, Aug 24, 2006
    #1
    1. Advertising

  2. John Graham

    MikeS Guest

    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, Aug 25, 2006
    #2
    1. Advertising

  3. John Graham

    MikeS Guest

    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.
     
    MikeS, Aug 25, 2006
    #3
  4. John Graham

    Joe Kaplan Guest

    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.

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "John Graham" <> wrote in message
    news:...
    >
    > 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
    >
     
    Joe Kaplan, Aug 25, 2006
    #4
  5. John Graham

    MikeS Guest

    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.

    >>but lots of other people need to store their users in SQL and/or ADAM


    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.
     
    MikeS, Aug 25, 2006
    #5
  6. John Graham

    Joe Kaplan Guest

    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.
    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "MikeS" <> wrote in message
    news:...
    > 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.
    >
    >>>but lots of other people need to store their users in SQL and/or ADAM

    >
    > 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, Aug 25, 2006
    #6
  7. 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/

    ---
    Dominick Baier, DevelopMentor
    http://www.leastprivilege.com

    > 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, Aug 25, 2006
    #7
  8. John Graham

    John Graham Guest

    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.
     
    John Graham, Aug 25, 2006
    #8
  9. John Graham

    Joe Kaplan Guest

    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.
    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "John Graham" <> wrote in message
    news:...
    >
    > 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, Aug 25, 2006
    #9
  10. 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...

    ---
    Dominick Baier, DevelopMentor
    http://www.leastprivilege.com

    > 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, Aug 25, 2006
    #10
  11. John Graham

    John Graham Guest

    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)
     
    John Graham, Aug 25, 2006
    #11
  12. 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

    ---
    Dominick Baier, DevelopMentor
    http://www.leastprivilege.com

    > 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, Aug 25, 2006
    #12
  13. John Graham

    Joe Kaplan Guest

    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.


    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
    message news:...
    > 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
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    >> 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)
    >>

    >
    >
     
    Joe Kaplan, Aug 25, 2006
    #13
  14. John Graham

    John Graham Guest

    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, Aug 25, 2006
    #14
  15. John Graham

    John Graham Guest

    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, Aug 25, 2006
    #15
  16. John Graham

    John Graham Guest

    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.
     
    John Graham, Aug 25, 2006
    #16
  17. John Graham

    MikeS Guest

    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.
     
    MikeS, Aug 26, 2006
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?UmVuem8=?=

    Problem using AzMan url Authorization and HttpHandler

    =?Utf-8?B?UmVuem8=?=, Mar 24, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    592
    Brock Allen
    Mar 24, 2005
  2. Michael Herman \(Parallelspace\)

    ASP.NET 2.0, MS AD/ADAM and Authorization Manager (AzMan)

    Michael Herman \(Parallelspace\), Jul 6, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    895
    Michael Herman \(Parallelspace\)
    Jul 9, 2005
  3. iusfani

    Security Appl. Block with AzMan

    iusfani, Sep 5, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    1,044
    iusfani
    Sep 5, 2005
  4. Michael Herman \(Parallelspace/OpenCanal\)

    AzMan: Has anyone created an HTML/Web management console as an alternative to the AzMan MMC?

    Michael Herman \(Parallelspace/OpenCanal\), Jan 6, 2006, in forum: ASP .Net Security
    Replies:
    0
    Views:
    265
    Michael Herman \(Parallelspace/OpenCanal\)
    Jan 6, 2006
  5. Lars Sundstrom

    Azman. Unable to recive rolls from Azman.

    Lars Sundstrom, Oct 9, 2008, in forum: ASP .Net Security
    Replies:
    0
    Views:
    768
    Lars Sundstrom
    Oct 9, 2008
Loading...

Share This Page