Patterns in RBAC?
By Simon Moffatt on May 21, 2009
Over the last couple years working with customers embarking on RBAC implementations, many ask during the PoC/workshop stage, what is the 'best' RBAC model we should aim for?
Many attempt to compartmentalize the question using tangible benchmarks. Numerical normally so they can attempt to visualize, model and compare to either other vendors or to compare the approach to a scenario if no roles based access were used at all.
This results in many questions so as: How many roles per user should we have? How many entitlements per role? How many exceptions? How many users with out any roles? How many roles in department X if they have 650 people and 10% turnover? Etc etc. It can be very difficult and misleading to suddenly dive straight into a details base discussion with absolute facts and figures. I don't personally think this is the way RBAC should be approached or bench marked. There are several white papers (mainly academic) that discuss the value of RBAC from a quantitative perspective performing user to role modelling based on various functions.
In reality however I don't really believe there is a set number for things like user to role associations, or business role to IT role relations. A lot depends on the organization. How is access managed today? Centralised/decentralised, branch level, application centric, business driven etc. In addition what does the organization do? Are they a blue collar office company with many large teams of tele operators? Or a mid sized mining company with hundreds of locations with small numbers of localized workers?
Each of these factors can all affect the RBAC model and in turn the ratios.
With that said, best practice and the leading experience we have at Sun allows us to start and develop a more qualitative approach to how RBAC should be modelled. In reality although RBAC and role based services are not a new concept in operating system security, large scale enterprise implementations are relatively immature - the oldest probably being less than 8-10 years old at most.
This results in a new opportunity over time to develop a model and approach that not only utilizes our toolset efficiently but also allow businesses to understand and analyze themselves in a non-tangible way. A colleague of mine compared this to the patterns approach used in OOP and I can see why. The benefits are much greater than a standard numerical even ROI approach and will allow RBAC to start becoming a well versed approach to access modelling rather than a longer term dream of provisioning.