Role Based Security Question

[Mike Logan]

Questions about Role Based Security in ASP.Net:

I have a few questions about role based security in an ASP.Net application.
Below are some points about our system:

- We have a hierarchical roles system stored in a database.
- We are also using Windows for authentication.
- Page - Role relationships are also held in a database.
- We have created a shared assembly for ease of use in applications.

Here are the goals we are trying to accomplish:

1. - If a page (i.e. /Dir1/Dir2/Page1.aspx) has not been entered into our
system for the given application (i.e. /App1), throw an exception and let the
application handle it. 2. - If a user is not in a role that is defined for
the current page, throw an exception and let the application handle it. 3. -
If two sibling roles (our roles are established in a hierarchy) have access
to the same page, allow the application to use this construct to control page
layout for different roles:

If User.IsInRole("RoleName1") = True Then
pnlRole1.Visible = True
ElseIf User.IsInRole("RoleName2") = True Then
pnlRole2.Visible = True

Here is our current approach to solve each of these:

For Goal 1, load all the Application Pages into the Application object on
Application_Start and check the page for existence on each
Application_BeginRequest. For Goal 2, load all the roles the user is in and
the pages the user has access to into the Session object on Session_Start.
For Goal 3, load the roles into the IPrincipal interface to allow users to
use User.IsInRole("RoleName").

Here are the questions:

Do you think this is the best way? We are trying to minimize calls to the
database. We plan on testing this solution, and another solution using only
calls to the database and not storing data in the session or application
objects. Then use ACT to performance test each solution.

We plan on placing the code/shared assembly into an HTTP Module that
attaches to global events like Session Start, Application Start,
AcquireRequestState, and etc. to check for security access. Is there any
better way?

Is there anything else we should check into?

TIA, Mike Logan

[Rulin Hong]

I suggest redirecting to a specific page instead of throwing an exception.

[Nicole Calinoiu]

"Mike Logan" <Mi*******@community.nospam> wrote in message
news:96**********************************@microsof t.com...
<snip>

For Goal 1, load all the Application Pages into the Application object on
Application_Start and check the page for existence on each
Application_BeginRequest.
Not a good idea. With this approach, you'll need to restart the application
in order to get a newly added page to be properly handled after its
permissions have been set in the db. Either store the data in a cache
that's invalidated when the db is updated, add an administrative means to
repopulate the collection, or don't cache at all. Also, you might want to
keep in mind that maintenance of the cache may also affect overall
performance of the application, particularly if the number of pages is very
large.

For Goal 2, load all the roles the user is in and
the pages the user has access to into the Session object on Session_Start.
Thereby allowing a user to maintain elevated permissions simply by keeping a
long session even if you've locked them out via the db? Again, not
generally a good idea. Also, any given legitimate user will place requests
relatively seldom (usually not more than one or two per minute in most
applications). Keeping a large permissions set in session state to handle
infrequent requests might not give you quite the performance advantage you
might expect. <g>

For Goal 3, load the roles into the IPrincipal interface to allow users to
use User.IsInRole("RoleName").
Fine, but when? As with the user-specific permission set, allowing the
cached roles to be persisted for too long could expose the site to
unintended use by users whose permissions have been decreased since their
sessions started.

Here are the questions:

Do you think this is the best way?
We are trying to minimize calls to the
database.
As suggested above, just make sure you don't compromise security or
useability to get there.

We plan on testing this solution, and another solution using only
calls to the database and not storing data in the session or application
objects. Then use ACT to performance test each solution.

We plan on placing the code/shared assembly into an HTTP Module that
attaches to global events like Session Start, Application Start,
AcquireRequestState, and etc. to check for security access. Is there any
better way?

Is there anything else we should check into?

TIA, Mike Logan

[Steven Cheng[MSFT]]

Thanks for Nicole's informative suggestions.

Hi Mike,

As for the questions you mentioned, here are some of my understandings and
suggestions:
Q1: If you do need to manually do the checking, I think Nocole's suggestion
on using the Application Cache instead is reasonable.

Q2: Q3:

I think Q2 and Q3 should be the same, generally if you're using the Form
Based Authenticatoin, we'll store a user's roles info into the
cookie(Authentication ticket) at the time the user logon, and then in each
of a user's sequential request, we retrieve the roles from the cookie and
set them into the IPrincipal (current User) object in application's
Authenticate Request event. However, since you're using Windows
Authentication rather than forms authentication and you store the roles at
session start into the user's sessionstate, we may need to change the
approach. I think if we store the roles in SessionState, it would be better
that we no longer use the IPrinciple object , and just checking roles from
the SessionState when we need to do authoriztion in each page's initial
time. This will avoid the overhead on retrieving roles from sessionstate
and set into request's current Principal object.( Also, as Nicole
mentioned, when to set it is a
problem).

Just some of my suggestions. If you have any other ideas or questions,
please feel free to post here.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)