On Jan 24, 2011, at 4:16 PM, Brian Stansberry wrote:
On 1/24/11 8:08 AM, Heiko Braun wrote:
>
> If I understand you correctly, you say:
>
> - we could do role based authentication
Right.
> - simplify it by providing fixed set of roles the UI knows of
For now, yes. But we'd want to understand how to make that set of roles configurable
in the future.
> - allow for a highlevel mapping of roles to management use cases (what ever highlevel
means)
This is the hard part. We'd want to design this to be flexible for the future. I
suspect that's *much* easier to do for the core management infrastructure than it is
for the console.
> - defer the decision how roles are being mapped to principals
>
Well, we'd have to solve this problem even for the simplest use case; i.e. just
because a user can authenticate against corporate LDAP, he may not be an admin.
As for the UI side of things: The console will always have two means of authorization:
a) One for the client server communication (which operation can a 'role' invoke?)
b) another one discriminating which parts of the UI the user actually gets to see.
I did refer to the later, when I said "a fixed set of roles for the UI".
It's very unlikely that a) and b) are the same.
Typically b) relies on several operations that are covered by a). This is the
"highlevel" mapping that I tried to describe.
To keep things simple, but extensible we could map all UI access roles (b) to a single
principal or even just begin with a single role ('root') to cover them all. But we
can design both sides to allow for further roles in the future.
A typical set of roles for (b) could be:
- admin (read, write, deploy)
- manager (read, deploy)
- user (read)
I wouldn't go any further then that, i.e by creating authorization schemes for logical
entities like domain, host, server-group.
Which basically means, if you incorporate a particular role, you always get to see
everything under one domain. The roles are simply means to restrict modifications to the
system.
My 2 cents.
Ike