I don't think that's the intended scenario. You wouldn't create different
IPrincipals based on areas of your app - you'd create different roles. The
IPrincipal is responsible for tying together IIdentities and roles. So, in code:
class AppIdentity : IIdentity {
string Name { get; }
bool IsAuthenticated { get { return !string.IsNullOrEmpty(this.Name); } }
string AuthenticationType { get { return this.IsAuthenticated ? "AppXYZ" :
string.Empty; } }
private AppIdentity(string username) {
_name = username;
}
public AppIdentity Create(string username, string password) {
if (DB.Login(username, password)) {
return new AppIdentity(username);
} else {
return new AppIdentity(string.Empty);
}
}
}
class AppPrincipal : IPrincipal {
IIdentity Identity { get; }
string[] roles;
public AppPrincipal(AppIdentity identity) {
_identity = identity;
}
bool IsInRole(string role) {
if (role == "anonymous") {
return !identity.IsAuthenticated;
} else if (!identity.IsAuthenticated) {
return false;
}
if (roles == null) {
roles = DB.GetRoles(this.Identity.Name);
}
return Array.Exists(roles, role);
}
}
// App start
Thread.CurrentPrincipal = new AppPrincipal(AppIdentity.Create(string.Empty,
string.Empty)); // attach anonymous identity
// App login
if (Thread.CurrentPrincipal.IsInRole("anonymous")) {
// Only login an anonymous user. Otherwise, they're already logged in
Thread.CurrentPrincipal = new
AppPrincipal(AppIdentity.Create(View.GetUsername, View.GetPassword));
}
// Public area of app
if (!Thread.CurrentPrincipal.IsInRole("public")) {
throw new UnauthorizedAccessException(Thread.CurrentPrincipal.Identity.Name,
"public");
}
// Secure area of app
if (!Thread.CurrentPrincipal.IsInRole("secure")) {
throw new UnauthorizedAccessException(Thread.CurrentPrincipal.Identity.Name,
"secure");
}
// Logout
Thread.CurrentPrincipal = new AppPrincipal(AppIdentity.Create(string.empty,
string.empty)); // attach anonymous identity
> -----Original Message-----
> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Miika Mäkinen
> Sent: Tuesday, December 18, 2007 3:57 AM
> To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> Subject: Re: [ADVANCED-DOTNET] IPrincipal and IIdentity
>
> 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
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
