Question

I know what are you saying already (baad idea), but please read first 🙂

I am developing ASP.NET MVC based app, which will require some specific features:

1. combination of “local” users and facebook connect login, but FB users will be “mirrored” to some kind of local representation, because there will be some statistics and other stuff needed to keep for both types

2. authorization will be 3-layered instead of asp.net standard 2 layers. By this i mean : User is in Group (m:n) and Group is in Role (m:n), instead of User is in role (m:n).

So, if i would want to use standard authentication/authhorization approach, i would have to:

1. implement custom Membership provider, and it wont be even “right”, because it will utilize methods like AddUserToGroup and AssignRoleForGroup etc.

2. implement custom Principal/Identity for sake of accessing my own User objects

3. casting HttpContext.User to my object every time needed…

4. implement custom Role provider

5. custom mechanism of sessting AuthCookie (unique userId in userdata, cant rely on username with third-party FB users in system)

6. … (you surely can think of something else)

Well, i really dont like the idea of “bending” and replacing every part to get pretty messy solution in the end. So I think of implementing my own mechanism encapsulated in one place – lets call it AuthService.

1. AuthService will be thread-safe singleton
2. Instead of AuthCookie will be using standard Session object (i know sessions also use cookies, but i really dont see advantage of low-level storage (cookie) over session)
3. AuthService will provide AuthService.CurrentUser (of my own type), populated from session on beginning of every request (Application_AuthenticateRequest, I think)
4. AuthService will provide in one place all methods – ValidateUser, RolesForUser, IsInRole, Logout, etc.

So now.. why should I not do this this way ? 🙂

I think session is equally secure to AuthCookie (same risks for ticket and authcookie)..
I dont really look for “modularity” (plug-and-play role providers, membership providers, profile providers..) – I deal here with pretty specific stuff, I dont expect standard components to fit.. have “my approach” any other disadvantages ?

Thanks for all good ideas and sorry my terrible english, I am from non-english-speaking country 🙂

R.

Answer 1

I can certainly see why you don’t want to implement an entire Membership provider. However, I would take advantage of the low-level support offered by Forms Authentication (e.g. the cookie, expiration etc.) and just do my own custom authentication. If you do this, you can inject your own custom user class into the HTTP context and use it throughout your code. Your custom user object would implement IIdentity and IPrincipal. Your IPrincipal.IsInRole would work against your custom authentication scheme. This would allow your higher level code to use standard .NET framework permissions stuff. This is the neatest, simplest way to accomplish what you want while taking advantage of what already exists.