Role-based security for an ASP/ASP.NET mixed environment

[nugget]

Role-based security for an ASP/ASP.NET mixed environment

Hello:

My co-worker and I have been charged with designing role-based security
for our intranet. The technologies we have to work with are ASP and
ASP.NET. This security design must support *both* technologies.
Currently, we have a successful collection of both ASP and ASP.NET
applications with an identical look and feel; you'd only know they are
different by virtue of an ASP or and ASPX file extension. These
applications all support a common authentication scheme implemented
through cookies. This scheme is simple and very low-security: check
for a "userID" cookie with a well-known name. While we plan to tighten
this up (using some sort of encrypted token/userID combo), our problem
lies in how we need to use roles.

If this were a pure ASP.NET site, I don't think we'd have as much
trouble as I anticipate, however we need to support the classic ASP
side as well. We plan on implementing the actual application security
roles in Active Directory groups with well-known names. For example,
"East Coast Office Project Editor" and "Checking Account
Administrator". Although individual users will (optimally) most likely
be placed in only one group (e.g. "Central Office, Dept. B, Teller
Position 3"), through multiple group containment they could conceivably
be indirect members of hundreds of application roles. The problem I
foresee is that of performance. For a highly role-based application,
each page refresh is going to have to ask whether the current user is a
member of roles A, B, F, Q, and X; this in order to allow or deny
access to the page itself, certain sections, edit or read-only, and
even field-level access. So, I'm worried that it may not be the best
idea to be directly querying AD 10, 20 times on every page refresh.
Assuming that this scenario is not acceptable, I would think the only
other way is to somehow cache the collection of direct and indirect
roles to which the logged-in user is a member.

At this point, I have to think of the best way to do this not only for
ASP.NET, but also for ASP. Ignoring ASP, I suppose there is the
possibility of performing this query for all the user's roles and then
stuffing this in a session-based dictionary/hashtable/whatever for
quick lookup. Then, if the user is a member of 100s of roles, I have
to worry about 40-50 concurrent sessions, each with all these roles.
What kind of performance am I going to get out of session with this
much data? Ignoring that, how do I implement the same thing in ASP?

At this point, you may be thinking I'm an amateur ... and I certainly
would not disagree with you, at least from a security standpoint. So I
think about how exactly these roles are "queried" by the application.
While having the list easily at hand while the page is executing, I
figure the only question that has to be answered (granted, many times
in succession) is "Is the current user a member of role QPR?" I don't
ever really need to have a list of roles and I don't need to go through
the list and display their names. Mainly, I just need this very simple
boolean pseudo code: "IsMember( userName, roleName )". Again here,
please don't flame me for my amateurishness, but isn't there a way to
encode or encrypt those group names with the user name into a
relatively small block of data and just "query" the block with the user
name and group name and get back a yes or no if they "jive"? Is this
what's called a hash or a token? Or does this even exist?

If I'm not making myself clear here, I mainly want to take a user and
the known groups of which s/he is a member. Then, mathematically or
cryptographically "melt" them all together into a small block of data
for storage and easy querying. The pseudo code would look something
like IsMember( userName, groupName, AUTHORIZATION_BLOCK ) and get back
a boolean. The AUTHORIZATION_BLOCK would be this "melted" block of
data that was created from the combination of the user and the groups.
This AUTHORIZATION_BLOCK would be small enough to fit into ASP session,
which I've heard it is dangerous to store objects to.

Am I over-engineering here? Am I looking for the wrong thing? Are the
multiple queries to AD for every page refresh not as expensive as I
think it will be?

 

[Kyle Peterson]

Not that you didn't explain things well and please take no offense.
But I think you will find that no one in the newgroups is usually interested
in trying to answer huge questions like that.

Thats a lot to read and a lot to think about and yes I did read it.
This place is more for things like having trouble with a bit of code.

Take Care

 

[danspanker]

Hello Chris,
I too am attempting to create a role-based authentication system for a site that will use classic ASP and ASP.NET.

I have been under the impression that I am going to have to write for the lowest common denominator - ASP.

What I was planning to do was use was cookies or session to store an array of IDs and associate boolean values - (i.e. Permission #1: Can user do X? Value: Yes represented as 1,Yes). That array would be serialised and stored, and would need to be retrieved on each check.

I'm planning to use an include at the top of every page that will need to reference permissions to de-serialise the string of permissions and allow me to look up the appropriate permission based on the array index.

The benefit of this method is that the permissions only need to be retrieved from the database once per session (on login) - so no potentially expensive AD queries - and in a page where there might be up to 20 permissions checks - the lookups can be performed against a pre-built array.

Hope you went well with yours. Wish me luck!

 

[nugget]

Yah, that's pretty much what we figured. Indeed, ASP was the LCD and I
think we were prematurely afraid of using Session in that environment.
All the reading I've done only warns against storing COM object in ASP
Session. Anyway, yes some sort of array or dictionary in Session I
think is going to do it for us. We'll still be using AD, but we'll
probably do an initial query to populate the session for both ASP and
ASP.NET and then leave the AD server alone for the rest of the session
or until we need to manually repopulate roles.

Thanks for the reply and I'm glad I'm not the only one out here trying
to do this.

 

[Bob Barrows [MVP]]

Yah, that's pretty much what we figured. Indeed, ASP was the LCD and
I think we were prematurely afraid of using Session in that
environment. All the reading I've done only warns against storing COM
object in ASP Session. Anyway, yes some sort of array or dictionary
in Session I think is going to do it for us.

not Dictionary, I hope. Use a free-threaded XML Domdocument.

 

[nugget]

Oh no? Why no Dictionary?

 

[Bob Barrows [MVP]]

Oh no? Why no Dictionary?

Threading issues. It is a COM object and worse, an apartment-threaded COM
object.
http://www.aspfaqs.com/aspfaqs/ShowFAQ.asp?FAQID=129

 

[nugget]

Good to know. Thanks. I'll use the free-threaded XML document as you
suggest.