I think it is important to identify what is exclusively for Cloudstack and what all can be reused across multiple services.
1. Authentication - Typically enterprises/service providers would like to reuse their existing authentication systems. So an easy mechanism needs to be provided for integrating with them. A built-in authentication provider can be there as it is today. 2. Mapping the user identity to a role - Once the user identity is established, it is mapped to a role based on some well defined policies/rules. This is again something that can be reused across multiple services and enterprises would already have it. So the same thing applies as #1. 3. Authorization - This is something that is specific to a service. Once the role is established, it is up to the specific service to determine what kind of access control needs to be enforced. The request that comes to Cloudstack will have some authorization token with the role information. Now based on this role a decision is to be made whether to allow or deny. This needs to be customizable. 4. Audit - This is again specific to a service and can be as simple as logging. But there needs to be a way to customize this as well to take some specific action. -Koushik On 29-Sep-2013, at 9:21 AM, 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). 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
