Grouper Developers Forum

> I'm returning this thread to grouper-dev, and attempting to style my 
> responses so that the whole is free-standing, giving >others a chance to 
> jump in the middle of this thread.

> Comments below.

> GW Brown, Information Systems and Computing wrote:
>> I may be trying to put a square peg into a round hole. I think the 
>> disjoint is between roles and privileges. Some of the current access 
>> privs could be considered roles. Ideally I would be able to define my 
>> own roles which could be an arbitrary set of read / write privileges to 
>> particular fields. When determining permissions I would never ask what 
>> role some one has, I would ask whether they can read / write a field.
>
>> This definitely does not fit in with KISS since you need extra stuff for 
>> defining roles and assigning them to subjects - SIGNET territory?

> I think that having Grouper's internal security model be site-defined would 
> be doable, but a substantial challenge. I'm not sure >in how many specific 
> ways, but there are several in which the security is implemented in code 
> and is not data-driven, and likely needs to be given the way it's designed. 
> On the other hand, I can understand an approach in which each atomic 
> function the API is capable of is labeled and made available as a privilege 
> to be site-assigned to a role, leaving sites the flexibility I think you're 
> after. It's just that that's not the approach we chose many months ago. I 
> suspect that the concrete has effectively solidified around that choice by 
> now.

Damn, I should have gotten in earlier :)

Is the ability to write group attributes driven from the grouper_field table?

> Further, we had as one design goal to enable the evaluation of Grouper's 
> internal security to be completely externalized, anticipating that 
> authorization servers (PDPs, policy decision points) will be income 
> increasingly present in site IdM infrastructure. The integration 
> requirements become even more difficult if the security model itself isn't 
> static.

Given that we can't know what custom attributes will be required ahead of 
time, or their significance it is unlikely that a static model will be 
satisfactory in many instances.

> And finally - KISS, again. It's a great principle. I'll be happy to agitate 
> with you for some future Grouper descendent with site-defined security, but 
> I think we've bitten off enough to chew on in one project already.

Looking forward to furure agitation...

>> In principle I think that
>> 
>> GrouperAccess.has(GrouperSession s, GrouperGroup g, GrouperMember m, 
>> GrouperField f,READ/WRITE)
>> 
>> is more flexible than the current
>> 
>> has(GrouperSession s, GrouperGroup g, GrouperMember m, java.lang.String 
>> priv)
>> 
>> Grouper's native GrouperAccess implementation could still answer the 
>> question based on the updaters, admins, readers etc fields, however, 
>> institutions would have greater flexibility when developing their own 
>> GrouperAccess implementation.
>> 
>> In this respect a method
>> String[] GrouperAccess.privs(GrouperSession s, GrouperGroup g)
>> 
>> Would allow the UI to present appropriate privileges. GrouperAccessImpl 
>> would return [ADMIN,UPDATE,READ,VIEW,OPTIN,OPTOUT], but 
>> UoBGrouperAccessImpl could return a list of roles e.g. 
>> [ADMINISTRATOR,MAINTAINER,SELF-SELECTER]

> The set of privs is static, but I suppose a Grouper.getPrivs method would 
> safeguard the UI against any future changes to the priv set. 
> GrouperAccessImpl evaluates but doesn't define the privs, which is why I 
> would locate the method with the Grouper class instead.
Sounds good.

> Also, a GrouperField method to list the read/write privs in the 
> grouper_field table should enable the UI to render access privs in 
> per-field read/write terms.

>> We would need a notional field, or perhaps the 'name' field to indicate 
>> whether a group itself can be deleted. Could be simplified to
>> GrouperAccess.has(GrouperSession s, GrouperGroup g, 
>> GrouperMember,READ/WRITE)

> I'm sorry - I still haven't understood a use case requiring that deletion 
> be split off from the ADMIN priv. I know I'm getting denser with age, maybe 
> if you write real slowly ... :-)

At Bristol I can envision a loader creating lots of empty groups which are 
then administered by a human - who shouldn't actually delete the group. This 
would allow conformity of naming, and standardisation of structure which we 
think will  make training easier, and will reduce the workload of 
departmental administrators. UPDATE privilege would suffice for changing 
membership, but if we want to allow some attributes to be modified as well we 
have to give ADMIN privilege.

 >>...
>> What I mean is for Subject searches implemented through
>>     edu.internet2.middleware.subject.SubjectTypeAdapter
>> to have the same facility as GrouperQuery, namely, to qualify resultsets 
>> based on who is doing the searching.

> Ok. We could pass a subjectID along to the subjectTypeAdapter<Type>Impl 
> class, in case it has a capability to use its own security to filter 
> results based on that subject.
We might need to send the type as well?

>> An 'extreme' example of this might be illustrated by the case of Ewan 
>> Blair (Tony Blair's son) who studied at Bristol. He specifically 
>> requested that he not be listed in the University's Contact directory 
>> for privacy and security reasons. Clearly, there would have been 
>> advantages to having his details in our Identity management system but 
>> restricting who can retrieve details. An identity management system 
>> could have been set up to only return Ewan in resultsets for specific 
>> administrators and / or restrict which attributes are returned depending 
>> on who carried out the search.
 >
>>>> I think this comes back to the question of whether you can search for
>>>> more than one subject type at a time. From the API it looks as if you
>>>> search for subjects using the SubjectTypeAdapter interface - so
>>>> presumably it would find results of its own type? Merging different
>>>> resultsets can get messy
>>
>>
>>> I think I need to see some actual use cases at this point to try to get
>>> clear on what may be needed. Do you mean a query like "list all groups
>>> containing a person with last name 'Smith'?
>>
>> 
>> Say we have the following subject types:
>> people
>> groups
>> machines
>> applications
>> 
>> If I want to make a subject a member of a group, or assign a privilege, 
>> it probably makes sense to limit a search to a particular type - 
>> implemented through a specific adapter. This would involve selecting 
>> from a list of adapters.
>> 
>> It would be possible to select multiple adapters and set different 
>> threads to search using each adapter in parallel, and then collate the 
>> results - presumably each adapter would specify which attribute to sort 
>> by for an alphabetical search.
>> 
>> The case of people as subjects deserves some further thought because it 
>> is quite likely that people will be sourced from different systems.
>> 
>> Let's picture a rather messy situation where, say, Bristol needs to 
>> recognise subjects from multiple identity management systems. The 
>> subjects might be:
>> 
>> Bristol staff / students
>> (Currently from our contact directory)
>> 
>> Affiliated Staff at Bristol hospitals
>> UWE (University West of England) staff / students
>> (Might get details from an LDAP directory - would probably need 
>> different adapter for each LDAP directory searched - subclass which 
>> configures the LDAP details)
>> 
>> Individuals who authenticate via Athens
>> Individuals who authenticate via Shibboleth
>> (Would possibly need different adapter for each source site. May not be 
>> able to search, but only retrieve attributes for a known identity.)
>> 
>> I might know a name I want to search on, but not be sure which 
>> organisation the person works for. Clearly, it would be useful to search 
>> across all the adapters which represent people.
>> 
>> In such a devolved system searching for people becomes non trivial. 
>> Different sources may have different attributes available and different 
>> search capabilities. Since systems may be geographically distributed, 
>> the network, and system load problems at one location might lead to slow 
>> / incomplete results.
>> 
>> I would suggest that for 0.6 we only allow searching against one subject 
>> type at a time. In the meantime we can canvas opinions.

> Agreed.

>> One option may be to limit what Grouper can do off-the-shelf, but 
>> provide a means for institutions to override this behaviour - possible 
>> by subclassing a Struts action, or by providing a SubjectTypeAdapter 
>> implementation which takes responsibility for collating results and can 
>> return a list of Subjects of mixed type. In this case the UI might need 
>> to be able to differentiate which SubjectTypeAdapters ought to be made 
>> available for searching.