Security Architecture - Settings to drive UI and Privileges (Rights) - Role-Based, per User-Account

Question

How do large companies implement their security requirements which are centralized and used to drive things people can do (allowed to call a certain web-service, submit an order, etc.) as well as to drive UI (disable buttons, menu options, individual form fields)?

I am considering RBAC architecture: Users -> Roles, Roles -> Privileges.

Complex applications with permissions based on many individual field-account-user-role-amountThreshold would have many, many "Roles" and managing this gets complicated as number of roles grows.

Managing all these possible options seems daunting, and my prior experience is to hard-code such logic in the application.

Ex: If (User.Roles("IsAccounting")) { btnEditOrder.enabled = false; }

I am tasked with designing / implementing a security service/architecture which will be used as common authentication/authorization point for any/all applications (all .NET, but some GUI and some process-oriented).

This is not possible out of the box because of the business organization around client accounts and permission tiers based on financial amounts.

Ex: John is a User and he can View and Submit requests for account "Microsoft" and "Google". Mike can View "Microsoft" and "Google" requests but can only Submit "Google" requests.

Number of accounts / users is large and variable.

If I follow RBAC, there will be hundreds of "Roles" to accommodate all required Rights (Privileges). This doesn't help because the end goal is to give easy to manage GUI tool so that managers can assign their direct reports to appropriate Roles.

I was thinking to implement this security piece with the following API (rough draft in pseudo-code):

UserContext securityContext = Security.GetContext(userID, userPwd);

And usage in application would be like this: if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}

This way there would be thousands of these 'Can<doSomething>(params)' methods to check permissions which doesn't make it easy to either manage or use this pattern.

Any links / ideas / pointers are appreciated.

It's a .NET shop, but nothing I've seen from .NET (Membership / AzMan) will give us the granularity and delegation requirements required. ActiveDirectory / Oracle LDAP integration would be nice, but not necessary.

Old (current) system uses LDAP to authenticate users, but all authorization is done in-house and stored in classic "Users, Roles, Rights" tables.

Answer 1

I think it highly depends on end use. Just off the top of my head and without knowing a ton about your app end user, have you thought about session based authentication? Basically do a check on their permissions and apply some type of identifier to their session. That way you could grant requests allowable permissions, which should be faster than checking all user permissions on every request. Just have a lookup table for an action and what sessions are allowed to use it, that way you could store everything centrally which is a lot easier to manage. Just a side note, this is purely a response on ease of implementation/manageability/speed, the more secure you want your app to be obviously the more you are going to sacrifice speed. What will really drive your implementation is figuring out the reasonable balance point between acceptable speed and security.

I'll post a more lengthy response when I have some more time later on today.

Answer 2

Have you looked at Claims Based Authentication? The idea is that attached to each authenticated user is a collection of claims, and each claim represents something about the user. When the user is authenticated a collection of claims is pulled down for the particular application in question and can contain an arbitrary set like "CanSubmitGoogleOrders" or "PurchaseLimit = $4000".

The application itself just needs to know about what potential claims it can receive, and act accordingly if it sees (or doesn't see) any particular claim.

Answer 3

This is actually a well known problem, and unfortunately not many packaged solutions exist yet - at least, not really good ones.

Role-Based Access Control is just a compromise - between scalable administration, and security. Often, this was a good choice, simply because the alternative was - well, there haven't really been many alternatives till now... It always involved massive amounts of complex custom coding. Except in the case of banking or military-grade security requirements, that was the way to go... but, it always was a compromise in the interest of making security manageable.

While @SteveS' suggestion of claims-based authentication is a good one (for .NET you can check out what was known as the Geneva Framework, or Windows Identity Foundation (WIF)), and is definitely an improvement in the direction of more granular security, it doesnt really help solve the "scalable administration" problem.

You can also look in the direction of what is (unfortunately) known as "entitlement management", Policy/Attribute -based Access control (ABAC/PBAC), Context-Sensitive Access Control, etc....
To that end, you can look into XACML - while it definitely has non-trivial shortcomings (even the upcoming v3 misses the mark...), it is definitely a substantial step in the right conceptual direction. (It's just a format/protocol, not familiar with standard tools for enforcing this...)

Bottom line, unfortunately, is there are still no really good solutions out there for scalable granularity of access control management. Today it still requires no small amount of customization - either custom coding in your app, or extensive modifications to some passibly related administration product. Maybe some small startup will come up with the solution to that soon...
_{Disclosure: I am working with one of those startups, to make scalable access granularity something you can use...}