Also, another thing that confuses me is that the current user identity is
always stored as IPrincipal. E.g. isn't the normal approach to
1) authenticate to get IIdentity
2) create IPrincipal and "wrap around" IIdenty
3) store this IPrincipal either to HttpContext.User or
Thread.CurrentPrincipal
So you cannot first authenticate and then in some other part of the
application authorize, but you need to do it all in one go. Unless you store
the IIdentity somewhere else in your custom made state management or do
something like:
// authenticate
IIdentity user = Login(name, password);
// arrive to open area of the application
OpenAreaPrincipal p = new OpenAreaPrincipal(user);
Thread.CurrentPrincipal = p;
// user does things here
// and then goes to secure area
SecureAreaPrincipal p = new SecureAreaPrincipal(
Thread.CurrentPrincipal.Identity);
I'm not sure if I explain my confusion clearly... but never mind, I just
haven't really needed the separation of authentication/authorization or
users/roles and I think would do it quite different way myself.
Thanks for the thread,
Miika
On Dec 18, 2007 11:50 AM, Sébastien Lorion <[EMAIL PROTECTED]>
wrote:
> Separating authentication and authorization is all fine, but the question
> is
> why it was done in this way. Why not have a RoleProvider with a method
> IsInRole(IIdentity, IRole role), along with other methods like
> GetRoles(IIdentity), GetAllRoles(), etc. To me, the way the current
> IIdentity/IPrincipal architecture is done, it feels awkward.
> When you look at System.Web.Security, you can see that the provider
> model has already been put in place and that
> its interaction with the System.Security architecture is a bit cumbersome.
>
> Sébastien
>
> On 12/17/07, Mark Brackett <[EMAIL PROTECTED]> wrote:
> >
> > Your UserIdentity hierarchy seems to be confusing security rights with
> > identity - which is where the lines are blurring for you between
> > authentication and authorization. I think a more appropriate example
> would
> > be something like:
> >
> > class DatabaseIdentity : UserIdentity // retrieved from app specific
> > custom DB
> > class FlickrIdentity: UserIdentity // uses Flickr.com login info
> > class LdapIdentity : UserIdentity // from enterprise LDAP store
> >
> > Each *Identity class has it's own logic for Authenticating a user and
> > retrieving/persisting user details. See the FormsIdentity and
> > PassportIdentity for a concrete example.
> >
> > Now, when your app wants to determine if the user is allowed to run the
> > Admin functions, you'd perhaps use your own IPrincipal implementation
> that
> > takes in a UserIdentity and loads the appropriate roles from your custom
> DB
> > store, and then call Principal.IsInRole("Admin")
> >
> > class DatabasePrincipal : IPrincipal { DatabasePrincipal(UserIdentity
> > identity) }
> >
> > The WindowsIdentity/Principal combo isn't the best example of this,
> since
> > the store is ultimately the same (Active Directory) for both
> authentication
> > and group (role) info. But, you could use a WindowsIdentity with the
> above
> > DatabasePrincipal or GenericPrincipal and load role info from somewhere
> > else. Using WindowsPrincipal without a WindowsIdentity is a bit more
> > problematic (and wouldn't make much sense, knowing that AD stores group
> info
> > based on User SIDs - which your Identity classes wouldn't have).
> >
> > --MB
> >
> > > -----Original Message-----
> > > From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> > > [EMAIL PROTECTED] On Behalf Of Miika Mäkinen
> > > Sent: Thursday, December 13, 2007 12:15 AM
> > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> > > Subject: Re: [ADVANCED-DOTNET] IPrincipal and IIdentity
> > >
> > > Hi all,
> > >
> > > After looking through the code for two pairs implementing these
> > > interfaces
> > > in mscorlib using Reflector I think I start to understand... To me it
> > > still
> > > looks that this separation is a little bit artificial though. Like
> said
> > > there are two pairs: GenericPrincipal + GenericIdentity and
> > > WindowsPrincipal
> > > + WindowsIdentity. E.g. very tightly coupled classes... in fact I
> can't
> > > see
> > > any other reason why these are separated but to have less code per
> > > class.
> > > Another thing that doesn't make it any easier to understand is
> > > IPrincipal
> > > interface being as it is... one method IsInRole(string)! This is
> hardly
> > > ideal way for many applications to authorize a user! And in fact can
> > > see
> > > that WindowsPrincipal uses a lot of other ways...
> > >
> > > Or maybe my confusion just comes from the fact that I haven't needed
> > > multiple different IIdentity classes... There I could see reason to
> use
> > > this:
> > >
> > > abstract UserIdentity : IIdentity
> > >
> > > class AdminIdentity : UserIdentity
> > >
> > > class AnonymousIdentity : UserIdentity
> > >
> > > class SalesPersonIdentity : UserIdentity
> > >
> > > class UserPrincipal : IPrincipal
> > > + ctor(UserIdentity identity)
> > >
> > > Maybe somebody's doing like above? Or do you have better examples
> where
> > > it's
> > > clear why these are separated?
> > >
> > > Ah, I just hate to see so central concepts that I don't clearly
> > > understand
> > > :) Sorry about being difficult...
> > >
> > > Cheers,
> > > Miika
> > >
> > > ps. Looking at
> > > http://blogs.msdn.com/ploeh/archive/2007/08/20/UserContext.aspx says
> > > "Should
> > > I create both a UserPrincipal and a UserIdentity class? In some cases,
> > > it
> > > makes sense, while in others, it doesn't"... At least this article
> > > confirms
> > > that it's ok to implement in same class if you don't see reason not
> > > to...
> > >
> > >
> > > On Dec 12, 2007 11:54 PM, Mark Brackett <[EMAIL PROTECTED]> wrote:
> > >
> > > > Authentication (IIdentity) vs. Authorization (IPrincipal).
> > > >
> > > > --MB
> > > >
> > > > > -----Original Message-----
> > > > > From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> > > > > [EMAIL PROTECTED] On Behalf Of Miika Mäkinen
> > > > > Sent: Tuesday, December 11, 2007 10:30 PM
> > > > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> > > > > Subject: Re: [ADVANCED-DOTNET] IPrincipal and IIdentity
> > > > >
> > > > > Thanks Brandon... This text in MSDN is the reason why I was
> > > asking...
> > > > > to me
> > > > > very cryptic explanations!
> > > > >
> > > > > On Dec 11, 2007 10:34 PM, Brandon Willoughby
> > > <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > > Taken from the MSDN:
> > > > > >
> > > > > > IIdentity:
> > > > > >
> > > > > > An identity object represents the user on whose behalf the code
> > > is
> > > > > > running.
> > > > > >
> > > > > > IPrinciple:
> > > > > >
> > > > > > A principal object represents the security context of the user
> on
> > > > > whose
> > > > > > behalf the code is running, including that user's identity
> > > > > (IIdentity)
> > > > > > and any roles to which they belong.
> > > > > >
> > > > > >
> > > > > > http://msdn2.microsoft.com/en-
> > > > >
> > > us/library/system.security.principal.iidentity(VS.80).aspx<
> http://msdn2
> > > > > .microsoft.com/en-
> > > > > us/library/system.security.principal.iidentity%28VS.80%29.aspx>
> > > > > >
> > > > > > http://msdn2.microsoft.com/en-
> > > > > us/library/system.security.principal.iprincipal.aspx
> > > > > >
> > > > > > Brandon W
> > > > > >
> > > > > > Miika Mäkinen wrote:
> > > > > > > Hi all,
> > > > > > > I'm having hard time understanding what is the purpose of
> > > > > IPrincipal and
> > > > > > > IIdentity. Why are these 2 separate interfaces? To me it just
> > > > > > complicates
> > > > > > > matters... Does anybody know of a good article explaining...
> > > > > > >
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Miika
> > > > > > >
> > > > > > > ===================================
> > > > > > > This list is hosted by DevelopMentor(R)
> http://www.develop.com
> > > > > > >
> > > > > > > View archives and manage your subscription(s) at
> > > > > > http://discuss.develop.com
> > > > > >
> > > > > > ===================================
> > > > > > This list is hosted by DevelopMentor(R) http://www.develop.com
> > > > > >
> > > > > > View archives and manage your subscription(s) at
> > > > > > http://discuss.develop.com
> > > > > >
> > > > >
> > > > > ===================================
> > > > > This list is hosted by DevelopMentor(R) http://www.develop.com
> > > > >
> > > > > View archives and manage your subscription(s) at
> > > > > http://discuss.develop.com
> > > >
> > > > ===================================
> > > > This list is hosted by DevelopMentor(R) http://www.develop.com
> > > >
> > > > View archives and manage your subscription(s) at
> > > > http://discuss.develop.com
> > > >
> > >
> > > ===================================
> > > This list is hosted by DevelopMentor(R) http://www.develop.com
> > >
> > > View archives and manage your subscription(s) at
> > > http://discuss.develop.com
> >
> > ===================================
> > This list is hosted by DevelopMentor(R) http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
> >
>
>
>
> --
> Sébastien
> www.sebastienlorion.com
>
> ===================================
> This list is hosted by DevelopMentor(R) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
