Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Grouper-provided Entities

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Grouper-provided Entities

Chronological Thread 
  • From: Jim Fox <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] Grouper-provided Entities
  • Date: Thu, 27 Oct 2011 10:19:34 -0700 (PDT)

In general I prefer improvements that help rather than hinder

It seems to me wasteful and unnecessarily complex to build a new
subject source inside grouper that mostly duplicates an already
workable subject source mechanism. An automated process presents
some credential, let's say an x509 certificate. An off-the-shelf
jdbc subject source easily manages subjects that have the CNs of
the certificates as names, or ids, or whatever. It requires nothing
new except a means to update the database of automated clients---not
a difficult task.

My second comment is that this capability, even if I don't use
it, will slow down grouper. For example, changing the name of
a stem will require a search for downstream subjectIdentifiers.
This might be a small, even trivial concern, but let me remind
you of the published comparison of performance between grouper
1.6 and 2.0. As I recall 2.0 is 'only' 15-20% slower than 1.6.
A couple more upgrades like that and it won't run at all.

An example of an improvement that does address performance is the
recent addition of sort and search attributes to member records.
This allows for much faster and easier selecting and sorting of members and subjects. That's what I'd like to see more of.


On Thu, 27 Oct 2011, Tom Barton wrote:

Date: Thu, 27 Oct 2011 09:47:43 -0700
From: Tom Barton
To: Grouper Dev
Subject: [grouper-dev] Grouper-provided Entities


For those not on the grouper-dev call yesterday, we spoke about Chris'
design for implementing Entities within Grouper. If you haven't been
following that thread, the purpose is to map security credentials
presented by automated processes into Subjects (or Entities) so that
their access to selected Grouper objects can be managed (the usual
alternative is to have them act as GrouperSystem). Of course, some sites
may already be able to present such credentials as a Subject Source, and
they wouldn't need to use this feature. But for those that don't, this
would provide a solution.

Chris realized that to ensure that distributed people using Grouper
couldn't produce the same Subject for different automatons, each Folder
must be capable of providing its own Subject Source for any Subjects it
contains. A simple way to do that is to use the Folder's pathname as the
SourceId for each Subject in that Folder.

So, to solve the problem of managing automatons' access to Grouper data,
we're planning to enhance Grouper to be able to be the provider of any
number of Subject Sources, and Grouper's delegation model will apply to
this capability just as it does to other objects managed by Grouper.

I call attention to this here because I suspect that this capability
could be used far more widely than just for the motivating use case, and
I ask the wider grouper-dev community to help us anticipate what that
might bring. Are there other use cases you think this capability would
be a good match for? Are there use cases for which using this capability
might be a bad idea?



Archive powered by MHonArc 2.6.16.

Top of Page