Grouper Developers Forum

[Jim Fox <>]

In general I prefer improvements that help rather than hinder
performance.

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.

Jim


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
>
> Colleagues,
>
> 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?
>
> Cf.
> https://spaces.internet2.edu/display/Grouper/Grouper+user+managed+entities
>
> Thanks,
> Tom