On 29 Sep 2013, at 05:51, Darren Shepherd <darren.s.sheph...@gmail.com> wrote:
> 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). And it would be nice to implement a IAM interface, its quite neat actually. > 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
