[security-dev] IDM Realms and Applications - The Nitty Gritty

[Bill Burke]

On 11/15/2012 8:39 PM, Shane Bryzak wrote:
> On 11/16/2012 11:19 AM, Shane Bryzak wrote:
>> On 11/16/2012 10:33 AM, Bill Burke wrote:
>>> On 11/15/2012 4:55 PM, Shane Bryzak wrote:
>>>> On 11/16/2012 06:25 AM, Bill Burke wrote:
>>>>> I don't think your design incorporates the idea of a distributed
>>>>> application:  a set of services and websites that makes up one
>>>>> application.  In other words the fun SOA buzzword.
>>>> Even the latest design?
>>>>
>>>>> In my mind, you have a bunch of distributed services.  Each service may
>>>>> or may not have its own roles and role mappings.  A user is allowed to
>>>>> execute on a set of services and those services may call other services.
>>>>> For example: a user may interact solely with Website A, but Website A
>>>>> may need to interact with other services.
>>>>>
>>>>> So, the actors would be Realm, Applications, Services, Users.
>>>> I'd like to see a specific example demonstrating this use case. Would it
>>>> be possible for the services that make up a single application to simply
>>>> share the roles defined by that application? Adding yet another layer to
>>>> the current design is going to really complicate things further.
>>>>
>>> A user might be "admin" for one service, but not "admin" for a different
>>> service.  Service "A" might want to invoke on Service "B" on behalf of
>>> the user.  Doesn't that have to be conveyed in the model somehow?
>>>
>>> Bill
>>>
>> Maybe what we really need to do is find another name for the abstraction
>> that we're currently referring to as Application.  The only reason we
>> currently have Applications is to support application-specific roles,
>> which is exactly what you're suggesting we do for Services.
>
> Actually, how about we just introduce a new, hierarchical abstraction
> which we call "Tier", and allow roles to be granted at various levels.
> This way, the application could be modelled as a parent tier, and
> services could be modelled as sub-tiers of the application.  Roles
> granted at the parent tier level would automatically become inherited by
> the sub-tier, so at the application tier you could grant general roles,
> then for each service tier you could grant more specific roles.  Would
> that work?

Sounds good.  Ditch the idea of applications/services and introduce 
logical nested tiers.  For the data model though, users should be global 
with a unique ID, same with "tiers", roles, and permissions.  Then have 
join-tables/associations to create the relationships you need.

Also, you might want to think about how this maps to something like an 
access token.  YOu might find you need some rules for role namespacing 
in some of these more complex tiered scenarios.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com