AuthorisationPolicyProvider in an External Assembly

Apr 21, 2008 at 3:27 AM
I'm trying to following the MembershipProviderAuthorisationPolicy to create my DNN provider, and I've hit a snag.

I copied the implementation from GetCardIdForUserId from the MembershipProviderAuthorisationPolicy into my DotNetNukeProviderAuthorisationPolicy, updated it to get the user from the DNN user store instead of membership.

I get the following build error: 'SharpSTS.Configuration.STSSettings' is inaccessible due to its protection level

From this line:
return string.Format("urn:sharpsts:{0}:{1}/{2}/{3}",
STSSettings.Settings.Issuer,
userId,
authenticationType,
dnnUser.UserID);

Seems to me that since STSSettings is internal it cannot be consumed by an external assembly - am I doing something wrong or is this accessiblity too strict?

TIA,
Dan
Coordinator
Apr 21, 2008 at 4:53 AM
Well I wanted to keep the settings out of the hands of anything outside the core library, so I don't think it's too strict.

The CardID should be specific to your web site and can be anything; so for example http://idunno.org/sts/{uniqueGuidForCardForUser}.

Documentation would help grin; indeed the sample membership provider does it the wrong way; it uses a user identifier because of limitations in the membership provider itself (i.e. there's nowhere to store another field, a card identifier for the user). So in your case I would, if DNN allows, do the following;

  • Add a new table to the user database keyed off the user identifier and have a column of card identifier; a new guid each time.
  • Create a card ID in the form urn:sharpsts:{DNNSiteName}:{card identifier guid}, or an http:// style id, your choice
  • And do the reverse lookup in GetUserIdFromCardId

By having the card identifier separated from the user identifier this means we can retire/revoke cards once I flesh out that interface (which is one reason I haven't documented this yet; that abstraction to an interface is going to be a breaking change again).

Make sense?
Apr 22, 2008 at 3:56 AM
Sure does, in fact parts 1 and 3 are aleady released in DNN as part of my Personal Card support.

Your solution to point two is obvious and I'll implement that now. I'll pulll {DNNSiteName} from a custom configuration setting that I get from config.