cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <darren.s.sheph...@gmail.com>
Subject my two cents on RBAC/authorization
Date Sun, 29 Sep 2013 03:51:07 GMT
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

Mime
View raw message