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

[Bill Burke]

On 11/16/2012 5:11 AM, Boleslaw Dawidowicz wrote:
>
> 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.
>

I don't think the SOA case is that narrow.  Especially considering the 
move to SaaS in the cloud.

What about this relational model?

username/userid
attributename/attributeid
groupname/groupid

userid/groupid - user association with a group
groupid/groupid - group belongs to a group
groupid/attributeid/attributeValue - attribute of a group
userid/attributeid/attributeValue - attribute of a user
userid/groupid/attributeid/attributeValue - attribute of a user 
associated with a group

So, to query for the roles of a user of a certain group:

select attributeValue from UserGroupAttribute where userid=? and 
groupid=? and attributeid='roleAttributeId';

Following me?

I don't know how this would map to ldap.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com