Architecture: Custom Profile Provider with Active Directory Membership

[Steven Nagy]

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

 

[Nicholas Paldino [.NET/C# MVP]]

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.

 

[Steven Nagy]

Hi Nicholas,

We want to use AD for authentication because it means the users don't
need "another username/password".
Also our product does not have a user maintenance section for
application users. We rely purely on sys admin maintaining AD users in
the standard way. Our product essentially leaves "zero footprint" in
this regard. So user administration is not a concern.

The only alternative then as I see it is to write a custom profile
provider base from scratch.
Or at least reflect Microsofts and fix it.

I guess this even shows a fault in the concept of the Provider
pattern; once you have an interface to a provider, you really are
locked in there.

Thanks heaps.
Steven

 

[Nicholas Paldino [.NET/C# MVP]]

Steven,

If user administration is done outside of the application, then I really
don't see the need for a custom profile provider base from scratch. You
just have to be aware that when you change the name in AD, that you have to
remember to update the underlying store that you are using for the
ProfileProvider.

 

[Steven Nagy]

If user administration is done outside of the application, then I really

don't see the need for a custom profile provider base from scratch. You
just have to be aware that when you change the name in AD, that you have to
remember to update the underlying store that you are using for the
ProfileProvider.

But exactly how would you approach that?
How does my application which stands alone seperate from AD (which it
only queries for authentication) ensure that profile information is
updated for the user?
I can't expect a sys admin to change the user's account in AD and then
come over to my app and use a tool for shifting the profile.

Do I need to setup a service that monitors if a User account username
changes?
To do this I would need to maintain a list of the user names as they
currently are and then scan AD every 30 minutes looking for any
changes to that list, and adjusting the profile username
appropriately.

Unless there is another simpler way to do this?

Cheers,
Steven

 

[Nicholas Paldino [.NET/C# MVP]]

Steven,

From what it sounds like, you are developing some sort of a commercial
offering. I originally considered this to be an internal app/offering, but
based on the emphasis on this usability aspect, it seems like that is the
case to me.

You answered your own question when you asked this:

How does my application which stands alone seperate from AD (which it only
queries for authentication) ensure that profile information is
updated for the user?

From my perspective, your app, since it only queries AD for
authentication, doesn't need to ensure that profile information is updated
for the user. It assumes that the information is correctly updated. I
don't feel it is unreasonable to have applications that only perform queries
make assumptions about the validity of the underlying data.

That being said, you might want to include a separate stand alone
application (or a module in your app) for performing the rename of a person
in AD. It would perform the rename, and update the profile data at the same
time. It's just something you will have to document for the customer, and
that they are going to have to remember. Anything else is going to be
overly complex, and not easy to maintain or manage in the event something
goes wrong.

 

[Steven Nagy]

Hi Nicholas,

I appreciate your input.
Yes the application is a commercial offering with 5 previous
versions.
We were looking for a way to unify authentication while making use of
the provider model in ASP.NET.
Previously we scanned AD and kept users in a database, then kept
profile information (user settings, etc) in database also.
This occurred as a windows service. Essentially the same as the
solution I defined previously.However it is this very structure we are
trying to get away from.

For a minority case it seems not worth the effort (cost-benefit). I'd
rather get rid of all those extra bits and pieces and move more to a
"zero footprint" installation.

Once again, thanks for your help.

Cheers,
Steven Nagy