Linking Membership to other tables

March 17, 2008 10:41 AM

I ran into a very simple problem today that, unfortunately, had a somewhat complex solution. A user's Active Directory login name had changed, and I needed to update his record in a web application which uses Membership to handle its logins.

Now, of course, the easiest way to uniquely identify your users is by username. You can easily get the ID of the currently logged in user from User.Identity.Name. Of course, as I discovered, this is a Bad Idea, because now I have to update 14 fields in 11 tables.

Instead, it's best to user the ProviderUserKey property of the MembershipUser. This means it takes one extra step to get the current user's ID: Membership.GetUser(User.Identity.Name).ProviderUserKey

On the other hand, you can pass the ProviderUserKey value into Membership.GetUser just like you did the username.

Comments

Gooye'd

Michael Neel • March 17, 2008 12:22 PM
Having been burned by this in the past, I now use the AD GUID for the user, and treat the username field as I would any other text field in AD. I'm curious, in this case is ProviderUserKey returning the GUID?

GUID

Dylan Wolf • March 17, 2008 12:37 PM
I'm not sure. What we've been using here is a custom combination of AD and the built-in SQL provider. (AD is just used for authentication; SQL tells whether the AD user actually has access to the app. This also lets us use SQL logins for users that don't have AD accounts.) It's returning the SQL GUID.

If you use the built-in ASP.NET AD membership provider, I would assume that this is the AD GUID.

GUID

Dylan Wolf • April 23, 2008 05:31 PM
FWIW, the ProviderUserKey is of type System.Security.Principal.SecurityIdentifier. You get what I assume is the AD GUID, but it's a string rather than a Guid type.