Skip to Content.
Sympa Menu

grouper-dev - Re: Sharing group management system experiences...

Subject: Grouper Developers Forum

List archive

Re: Sharing group management system experiences...


Chronological Thread 
  • From: Tom Barton <>
  • To:
  • Subject: Re: Sharing group management system experiences...
  • Date: Thu, 06 Jan 2005 09:09:33 -0600

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.



Archive powered by MHonArc 2.6.16.

Top of Page