[jboss-as7-dev] Securing the Console

[Heiko Braun]

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