CustomIdentity properties

Gravy posted on Monday, January 12, 2009

Hi,

Hopefully a simple question...

When using custom authenitcation via CustomIdentity and Principle objects, if I wanted to store additional information on the logged on user (like Full Name, Departmental information etc), should I use the Identity class or the Principal class to contain the values? Right now, I'm thinging the Identity as this already contains a Name property for the logged on user.

Regards

Graham

William replied on Monday, January 12, 2009

In my project, I have CustomIdentity and UserInfo/User as separate classes. I am using CustomIdentity for authentication/authorization purpose and have CustomIdentity exposes a lazy-load property to the corresponding UserInfo object. With this, I can reuse UserInfo/User object in other areas of the applications. For example, managing user accounts in administrative area, etc.

skagen00 replied on Monday, January 12, 2009

While storing a name isn't going to be a killer, I'd use Identity to store only what you need to identify the user - for most systems UserId is sufficient. With a multi-tenant (multi-client) environment, we added a TenantId (client id) to our Identity since UserIds could be repeated in different clients.

That said, FullName is something you might find useful since it may be used in many contexts, but when you start talking about lots of supplementary information (departmental information as you mention), I would personally be wary of doing that.

 

JoeFallon1 replied on Monday, January 12, 2009

I simply followed the same pattern in use for the standard properties. So I added the extra properties to the custom Identity and exposed them from the Principal.

e.g. Principal has ReadOnly Property FullName that returns mIdentity.FullName.

Joe

 

SonOfPirate replied on Monday, January 12, 2009

Applying OO separation of concerns, take a look at your use case and decide if Full Name, etc. are applicable to security (authentication/authorization).  Probably not.  This is what Microsoft recognized when they put together the security features in ASP.NET 2.0 where they separated Profile information from the Membership information.  Principal and Identity are designed for use with application security and not a storage medium for all things related to your users.  A better approach would be to have a separate User or UserInfo class that represents the user's profile information, such as FullName.

That said, I completely sympathize that storing the information in the Principal (as a property of either the Principal or Identity) is attractive because it is easily retrievable.  If you are looking at adding just one property, then extend Identity as Joe suggests because implementing a whole Profile schema is overkill.  But, if there's more data (with possibly more in the future), a more robust model might be more appropriate.

Just adding my 2 cents...