G
Guest
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
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