Question on Membership Providers

I've been working with Membership Providers for quite some time and have gone ahead and used Membership Providers in a few internal project. However, I've just come accross a requirement which is particularly interesting (and Valid, to be honest). Here it goes -

The Users need to be authenticated using integrated windows authentication. However, everything other than the authentication (their roles, groups, permissions etc. is maintained seperately in a custom database) and I need to use Membership Providers to achive a 'sort of' mixed apporach where by the authentication occurs on the AD using Kerbos or NTLM but User information comes from SQL Server.

I'm leaning towards a Custom Membership Provider that will Assume all users are authenticated and setting IIS options for Integrated Windows Authentication. Any Better Ideas, Anyone?

Feedback

# re: Question on Membership Providers

My thoughts are you should avoid a custom membership provider.

Use the standard membership provider for authentication from AD, and write a custom user class which contains methods which returns roles, groups and permissions - based on the username provided.

When you want to check a role/group/permission, you call your custom user class and pass in the current username.

Example:

Let's say you have predetermined that a user must belong to the "ReportViewer" role to run a report. Then you can check to see if the current user belongs to the "ReportViewer" role through your custom user class before letting them execute the report.

Example code:

public class User
{

... Constructor and other code ommitted...

public static ArrayList Roles(string UserName)
{
ArrayList A = new ArrayList();
Database D = DatabaseFactory.CreateDatabase();

//Replace "aspnet_UsersInRoles_GetRolesForUser" with your stored procedure name
DbCommand cmd = D.GetStoredProcCommand("aspnet_UsersInRoles_GetRolesForUser");
D.AddInParameter(cmd,"@ApplicationName", DbType.String, "MYDB");
D.AddInParameter(cmd,"@UserName", DbType.String, UserName);
IDataReader IDR = D.ExecuteReader(cmd);
while (IDR.Read()) A.Add(IDR["RoleName"].ToString());

return A;
}

public bool CanRunReport(string UserName)
{
ArrayList userRoles = User.Roles(UserName);

foreach (string usrRole in userRoles)
if ("reportviewer" == usrRole.ToLower())
return true;

return false;
}

Sample Call:

string UserName = (Membership.GetUser() == null) ? "" : Membership.GetUser().UserName;
if (CanRunReport(userName))
{

... Report Rendering code here ...
}
else
{
... No Access code here ...

}

3/13/2006 10:57 AM | Brian

# re: Question on Membership Providers

Hi Brian,
Thanks for the detailed feedback and the sample code. this really helps. I'm trying to evaluate the pro's and con's of both apporaches so here are a few additional questions that come to mind.

1. I am using Integrated windows authentication with IIS becuase i dont want users to login explicitly if they are already logged in using their domain passwords to their NT boxes. Is their an out of a box provider for this? or do the users have to provide their AD username and password to the out of the box provider for AD?

2. I agree with you and personally dont like writting custom providers till there is a justified need for writting them - in this application we're relying on permissions rather than roles and roles to us are just a logical grouping of permission. So, a person might have insert update delete permission on object X can perform all three. These permissions may be grouped using a role Y which the Admin might define and then assign this role Y to user X. I handle all of this in the custom provider. Wouldn't moving to a standard provider force me to stick to roles and use them as a means to controlling access?

3. There might be customers who have their ADs organized enough and might be able to provide all information that the application needs. In this case I was hoping that they will write their own custom providers (similar to the one i am writting, with permissioning concepts etc.) but with different implmentations. Can I have the same level of pluggable architecture if I use my own classes with out of the box provider?

4. I've created the user class that you talked about and this is a nHibernate class that my custom provider currently consumes (but other custom providers may not consume if their ADs are organized enough). Is their a way by which I can make the consumption of this class configurable?
3/14/2006 10:57 PM | rajiv

# re: Question on Membership Providers

1. You basically have to cover 3 cases for authentication.

* Unauthorized users, users who have not logged into the domain
* Unauthorized Domain users, users who have logged into the domain but do not have permission to use your app
* Authorized users, users who have logged into the domain and are application users

Unauthorized users:
There is no out-of-box provider for handling unauthenticated users. This is handled by IIS where integrated

windows authentication sets the Page.User.Identity.Name variable to the users' Domain\Login name. Each user will

be required to login to get access to your site. Users already logged into the domain will not be required to

login again. Users who haven't logged in yet will cause The browser to open a popup window asking for the name and

password which will be matched against the domain name. Users unable to login after 3 tries will get an error

page. Users who login successfully will be directed to the requested page and fall within one of the other two

categories below.

Unauthorized Domain Users:
These users are valid domain users but they aren't supposed to use your app or haven't been verified by your

application.

I suggest writing a routine to handle these users through an authenticate method in your custom user class or a

custom provider which your customers can modify. This method would create a session variable to store the user's

login name (not the password!). You can check this session var on each of your pages. If the session var is not

set, that means the user has not been authenticated to your app, run the user.authenticate(username) method where

username is the Page.Identity.Username value.

If the users' page.identity.username value is not set then they are an anonymous user and you will have to grab

their username and password and check their login manually through your own custom login page (This is not

required if you turn off anonymous access in IIS as these users will get the browser's login/password prompt).

If the users' page.identity.username value is not a valid user of your application then redirect them to an error

page with a message e.g. "You are not a valid user!" otherwise, set the session var and the user is now the third

case, an authorized user (your done).

2. When it comes to permissions, users and roles, a common method is to assign permissions (rights) to roles

(groupts) and users to roles. A user has a permission if they belong to the appropriate role. This works well when

your users can all fit into distinct categories by job category e.g. Finance, Sales, Production, Warehouse etc or

job function as it pertains to the application e.g. Admin, Supervisor, Account Manager etc. If you want more

permission granularity, or the ability to assign individual permissions to each user, then just omit roles all

together and go with a user/permission based system. You can achieve this with a role-based provider where each

permission maps one to one with a role e.g. Permission_Report_Delete is the only permission assigned to

Role_Report_Delete.

However, I think you will find that even the simplest system has so many permissions that this becomes a

management headache. In the following example, which is more clear?:

User/Permission
Bob / ReportView
Bob / ReportEdit
Bob / ReportDelete
Sam / ReportView
Sue / ReportView

Permission/Role, User/Role

Permission/Role
ReportCreator / ReportView
ReportCreator / ReportEdit
ReportCreator / ReportDelete
ReportViewer / ReportView

User/Role
Bob / ReportCreator
Sam / ReportViewer
Sue / ReportViewer

In this example, it seems to me that the user/role table is easier to read than the user/permissions table. The

Permission/Role table serves to hide the complexity behind the scenes while still allowing for permission/user

granularity.

3. For customers who want to roll their own provider I would suggest publishing your stored procedures and table

design. That way, those customers can rewrite the stored procedures to suit their own needs. If they want to use

AD for everything then you need to go with a custom provider. You can't have the same level of pluggable

architecture if you use your own classes unless you wrap those classes in a custom provider which your customers

can replace. Sounds like you have done this anyway based on your next question.

4. I'm not that familiar with nHibernate. I think you will have to abstract away the nHibernate class into a set

of properties exposed by your custom provider so that your customers can replace the provider with their own

implementation independent of nHibernate. Alternatively, make nHibernate a requirement of any provider your

customers create and publish the source of your provider as an example.

Hope this helps

-Brian

3/15/2006 9:05 AM | Brian Foote

# re: Question on Membership Providers

Thanks for your detailed comments brain! This helps a lot... Quite a bit of our apporaches are similar which tells me that I am basically on the right track :) - For the permissions part - We have some pretty funny requirements e.g. users being able to add but not delete or users being able to edit but not add (and other wild combinations) which kind of forced me to take the permissions apporach. As you rightly said - permissions were a headache to maintain so we allow the users to group them using roles. We give some system roles and then if user wants he can create more roles of his own by adding permissions as he sees fits. The secuirity model however, as you mentioned, is concered with user/permission i.e. which user has which permissions - these may come from multiple roles the user belongs to; so we're basically on the similar thought frequency!
Thanks a lot for your comments on this! This tells me i am not way off track and I really appreciate it!!
3/15/2006 8:38 PM | Rajiv Popat

Rajiv Popat