I've noticed there's a rbac branch and things are being committed there. I didn't see any documentation about the design or anything (maybe it exists and I looked in the wrong place), so I'm just going to give you my two cents on authorization systems. Hopefully this falls in line with what is being implemented, if not, at least we'll avoid the awkward conversation when its finish when I say the code is marginally useful and should be rewritten.
When talking about authorization there's a bunch of terms like principal, permission, subject, action, policy, etc. I want to focus on policy. Policy is central to an authorization system. The policy is the collection of permissions that grant or deny access to some resource or action for a given subject. RBAC is a really just a means to generate a policy. Once you know the user, group, roles, and the permissions of those entities that aggregation of information forms the policy. You then take that policy and use it determine if the given resource/action is granted/denied to a particular subject. It is really important that policy is a first class object in an authorization system. This is important to understand because usually in a big fat enterprise-y company, they really want you to enforce the policy, but not necessarily maintain it. For example, you'll go to your fortune 500 company and they'll tell you they need RBAC. So you go and create an RBAC system. The problem is that the fortune 500 company probably already has a RBAC system, and its probably AD based. So when they said they need RBAC, the really meant you need to enforce RBAC. If you implemented RBAC -> Policy -> Authorization, your good, if you implemented RBAC - > Authorization, your kinda screwed. Now you need to create a system to sync the two RBACs. And keeping data in two places and trying to sync them is never a good idea. Now if you implemented your system as having a policy as a first class object, you can just swap your RBAC for theirs and all is still swell. So if I was to implement this, this is how I'd do it. (And if this sounds a lot like IAM, its because it is. If Amazon got anything right, it's IAM). The authenticator should be able to implement another interface that allows it to supply a Policy object during authentication. This is logical in that the authentication systems quite often hold authorization information too. If the authenticator doesn't implement the interface we fall back to generating the policy ourself. The policy is then consulted to see if the API command and the resulting entities are granted/denied. So far none of this has anything to do with RBAC. So the RBAC is implemented in that default fallback implemenation that generates the policy. You map the current user/account to groups and roles and get the policies of those entities to construct the policy. Now for storing the policies I wouldn't do it in a traditional normalized form. All you need is tables for user/group/role and the mappings for each. The for user, group, and role you can specify a policy JSON blob and that gets stored in the database as a mediumtext field on the user/group/role row. From an API perspective (just like IAM), you just let people upload the JSON blobs for each. So if we do it this way, we can have our own simple RBAC but then be able to plug into far more complex and powerful authorization systems. Hopefully that all made sense. Darren
