2

I'm trying to get a handle on all the various techniques of implementing custom authorization within a traditional ASP.NET application - it seems that the preferred approach is to use the Membership API by creating a custom provider model.

I'm interested in implementing a custom roles authorization model based on a combination of roles and individual permissions (a role is comprised of permissions and a user can have multiple roles or specific permissions which override whatever permissions the roles might have)

What is the advantage or disadvantage of creating a full-fledged Roles provider vs implementing a custom principal object and implementing all the authorization logic in overloads of the IsInRole method? Are custom principals a deprecated technique stemming back to 1.1? In general, when are you supposed to implement a custom principal?

We are using Active Directory as the user store. A third party consulting firm has implemented a TERRIBLE custom roles-based authorization module that contains authorization logic and rules contained in an XML file and passed around in the Session object for each user and does not tie in whatsoever with the ASP.NET infrastructure for authorization.

I'd like to know what the best practice for this would be

manning18
  • 957
  • 3
  • 8
  • 18

1 Answers1

0

I would advise to stick with the asp.net membership and role provider architecture. It integrates well, and is a good thought out system.

If you need to use another account store then the asp.net membership or active directory you can always implement a custom membership and/or role provider. This is not hard.

It may be possible to wrap the custom third party system in a custom role provider, but i only would go custom if you have special needs that aren't provided in the given classes.

this video may be interesting

oɔɯǝɹ
  • 7,219
  • 7
  • 58
  • 69
  • I agree that hooking into the provider model seems to be the most robust solution. In that case, when are custom principal objects used? They seem to have some overlap in functional intent with the Roles provider obviously specifying a more complete featureset. – manning18 Jun 23 '11 at 13:55
  • No unfortunately, no one has given me a definitive answer that clearly outlines and contrasts the pros and cons of the two approaches. In the end I opted for a custom Role provider, as it is more maintainable and offers a broader featureset / hooks to implement, and generally seems like the preferred / "modern" approach. – manning18 Aug 11 '11 at 18:59