Grouper Developers Forum

[Tom Barton <>]

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.

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.

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.

> 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.

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 ... :-)

>...
> 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.

> 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.