Re: Architecture: Custom Profile Provider with Active Directory Membership
- From: "Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 13 Aug 2007 23:28:57 -0400
Steven,
I see how this can be a problem for you, but the provider model isn't completely at fault here, I believe.
The MembershipProvider doesn't account for a change in the username of the user, which is why everything is keyed on that. While you can perform insert/update/delete operations on users, the one thing that you can't change is the username (The UserName property on the MembershipUser is read only).
So, it stands to reason that if you perform a rename in AD, you are doing it outside of the context of the MembershipProvider, and unfortunately, it would be up to you to relocate profile information for any accounts that you changed the name of (since this is not an operation that is supported outside of the membership provider).
Now, the part that I feel is at fault is the ProfileProvider, as it only performs searches based on user names. It assumes that the unique, unchanging identifier for the user is the username, which can be argued whether or not it is correct or not. It can be argued that it is incorrect because the MembershipUser class has a ProviderUserKey, (which in the case of AD, probably returns the GUID of the user) which is also read only.
Regardless, it's unfortunate, because you are dealing with a membership provider which provides the action of renaming the user (while maintaining the identiy) outside of the MembershipProvider. Because of this, you will have to keep track of when a rename is performed through AD and then update your data store for the settings accordingly.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"Steven Nagy" <learndotnet@xxxxxxxxxxx> wrote in message news:1187058318.081391.326150@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi All,
So I have this fundamental problem that is going to influence design
decisions.
We want to use the ActiveDirectoryMembershipProvider but use a custom
profile provider.
When you inherit from ProfileProvider you have to implement the
abstract methods and so on.
Those methods force you to deal with user accounts based on user name.
This seems fundamentally flawed to me. In Active Directory, a user
account can be renamed.
If I have a user who has used my application and they therefore have a
profile under that username (eg "bob") then if they get their username
renamed to "robert", the next time they use my application they will
not have a profile.
The work around to this is that when I receive a username in my
profile provider methods, I then lookup the guid for that user against
AD, except that this violates the whole point of a provider model. In
other words, if I later change from using
ActiveDirectoryMembershipProvider to SqlMembershipProvider, then the
profile provider will suddenly stop working.
I thought all this was suspect. So I used Reflector to look at how MS
implemented their SqlProfileProvider. Turns out they base everything
on username which means an AD rename like I mentioned above would
cause the "lost profile" problem mentioned earlier (I have not
actually proved this with working code however).
Can you see my problem here?
If anyone can shed light on the problem, please reply.
Many thanks in advance,
Steven Nagy
.
- Follow-Ups:
- References:
- Architecture: Custom Profile Provider with Active Directory Membership
- From: Steven Nagy
- Architecture: Custom Profile Provider with Active Directory Membership
- Prev by Date: Re: Is there an elegant way of displaying fractions in C#
- Next by Date: Re: Architecture: Custom Profile Provider with Active Directory Membership
- Previous by thread: Architecture: Custom Profile Provider with Active Directory Membership
- Next by thread: Re: Architecture: Custom Profile Provider with Active Directory Membership
- Index(es):
Relevant Pages
|
