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

Boleslaw Dawidowicz bdawidow at redhat.com
Fri Nov 16 05:11:23 EST 2012


On Nov 16, 2012, at 2:39 AM, Shane Bryzak <sbryzak at redhat.com> 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?

It is a bit hard to digest see impact on the model without a diagram. 

As this SOA use case is pretty narrow I think we should try to come up with something built around the model. Would be good to try to keep it simple for most common scenarios. 




More information about the security-dev mailing list