Re: role, domain, and user based security...

From: Jon Paugh (anonymous_at_discussions.microsoft.com)
Date: 12/23/03 

Date: Tue, 23 Dec 2003 13:37:39 -0800

Thanks for the reply.

With respect to your first suggestion, to implement
IPrinciple, I am leaning this way but I want to understand
what the benefit it? Unless I map my
domain/permission/access modifier tuples to "roles" (which
I think would be ugly), I cannot use the IsInRole method -
it only takes a string as a parameter and I want need it
to take (domain, permission, access modifier). So I don't
see how it helps me? What is the benefit?

As far as using AzMan, my concerns are:
1) It will limit the interface for setting up
authorization to a microsoft management console snap-in.
We are developing a web app.
2) I don't think AzMan supports direct mapping of users to
tasks/operations. They have to go thru a role. I might be
wrong about this. I dont have win 2003 server installed as
yet so cannot play with this.
3) AzMan uses either an XML file or ActiveDirectory. Files
are security/performance/corruption problems and
ActiveDirectory is not something we have any dependency on
at this point so I would rather not go there... (If we
were using Windows security auth with AD, that would be
fine but we probably will use forms security.) We could
deal with these problems but it's not ideal (would have
prefered database mapping).

>-----Original Message-----
>There are a couple of ways that I know of that you could
approach this
>problem. One way would be to create a custom class that
implements
>IPrincipal that contains the additional functionality you
need. That is
>certainly one possibility that may work.
>
>The other approach would be to use something like the
object model presented
>by AuthorizationManager (AzMan) to perform this kind of
logic. AzMan uses a
>hierarchical structure, where individual actions are
organized into
>Operations. Operations are grouped in Tasks which are
grouped into Roles at
>the application level. At runtime, a users identity and
group membership
>are mapped into application level Roles, which then feed
down through the
>rest of the authorization system based on configurable
meta-data. So
>basically, you consider IPrincipal to be the highest
level object and it
>feeds the other objects that your application consumes
for its role-based
>security needs. Essentially, IPrincipal is a starting
point, but you need
>additional layers to support your required granularity
and indirection.
>
>If you can use AzMan in your application, you might
consider looking at it.
>Otherwise, it wouldn't be too hard to replicate some of
this functionality
>and then use an event in Global.asax or perhaps an
HttpModule to wire up the
>required mappings on a per request basis. There was a
good intro article on
>AzMan in MSDN Magazine a few months ago that is probably
online that might
>give you some additional ideas.
>
>Joe K.
>
>
>"Jon Paugh" <anonymous@discussions.microsoft.com> wrote
in message
>news:00d701c3c983$465d1530$a401280a@phx.gbl...
>> We have an app where users have roles specific to
>> different domains (e.g. a user can have the admin role
at
>> one company but not another). These roles in turn have
>> activities associated and access modifiers with them.
>> (E.g. an "Admin" can read, write, and delete user data,
>> but an "ApplicationUser" can only read user data.
>> Finally users can have explicit permission to perform
>> activities at a given access level outside a role. (E.g.
>> Bob is not in "Admin" role but he can update user data.)
>>
>> QUESTIONS:
>> I see that this security model is a lot more complex
than
>> what Microsoft's security model is setup to handle. Can
I
>> leverage anything from the Microsoft Security Model?
>>
>> If I implement IPrinciple and stick it on the
>> Context.User, I see that the framework will allow me to
>> get the IPrinciple back again (so I won't have to use
>> Session...), but other than that what can the MS
security
>> framework does the MS Security Framework provide for me?
>>
>> I have seen suggestions that I can hack the MS Model by
>> creating roles based on a combination of attributes
(e.g.
>> create roles for every "domain/activity/access modifier"
>> combination and assign these to user, but I think that
is
>> a big hack...
>
>.
>

Relevant Pages

  • Re: role, domain, and user based security...
    ... by AuthorizationManager (AzMan) to perform this kind of logic. ... > what Microsoft's security model is setup to handle. ... > get the IPrinciple back again (so I won't have to use ... > framework does the MS Security Framework provide for me? ...
    (microsoft.public.dotnet.security)
  • Re: role, domain, and user based security...
    ... you might consider an object model ... like AzMan uses without using it directly. ... > IPrinciple, I am leaning this way but I want to understand ... > were using Windows security auth with AD, ...
    (microsoft.public.dotnet.security)
  • Re: Roles in context
    ... domain resources if you were in the machine's administrator group" the ... to resources it is instead the security identifier of the logged ... Brown's security book: ... > AzMan is a component of Windows Server 2003 which can also be installed on ...
    (microsoft.public.dotnet.security)
  • Re: Anyone out there using AzMan with WinForms solution?
    ... AzMan is extremely powerful, and the setup steps you described are correct. ... client machines. ... > any comments or feedback on trying to implement this type of security ...
    (microsoft.public.dotnet.security)
  • Re: AzMan connection problems
    ... authentication. ... What security context is being ... used to access the AzMan store? ... I have an ASP .NET 2.0 app connecting to an ADAM AzMan Store on a DC. ...
    (microsoft.public.dotnet.security)
Quantcast