Grouper Developers Forum

[Jim Fox <>]

This is not so much of a next step, but more of a proposal related
to how Grouper might more easily achieve the next steps.



The executive summary, lest we encounter an error 413 TLDR.

I'd like to see grouper define and implement a complete groups API,
a RESTful webservice API.  (I know there is some sort of rest api
in grouper, but it doesn't appear very RESTful and I've never been
able to figure it out.)


Details, for the non-executive.


This is motivated by a concern I have for our university's groups
service, which does implement an API.

Groups have permeated every nook and cranny of UW's network, and
usage is increasing all the time.  There seems to be no significant
application that does not rely on our groups service, including
our Shib IdP.  It would be difficult to find, even overnight,
a time when a service outage of several minutes wouldn't in turn
cause outages elsewhere.  It is partly for this reason that the most
commonly requested groups resources are served from a pair of LDAPs,
rather than from the registry.  I am always wary of single points of
failure, and single elements that limit scaling.

Our API has a simpler set of resources than what might be required
for grouper, but it is complete.  All of its resources are exposed.
This means we could very easily maintain a cluster of independent
group systems (our API plus the grouper backend plus maybe an ldap
or two) all kept in sync by RESTful resource messaging.  If we wanted
to upgrade to a new OS, a new grouper, a new database, or all three,
It would be simple matter of bringing up the new service and adding
it to the cluster---risk free!  If an entire cluster member were to
disappear, say Seattle, other cluster members would continue the
groups service uninterrupted.  I think we have some scaling gains
as well, but that's not so clear.  In any case it is a route to a
scaling solution.

The utility of a REST API is well enough understood nowadays that
all websites are trending in that direction---even authn services.
(See Eve Maler's InCommon talk from a couple of weeks ago.)
Grouper should adopt this mindset.

In addition to its joining the 21st century, these are some of
the benefits of grouper's adoption of the API---and the resource
messaging.

1) Provides clearly defined group resources and representations.

2) Gains the resiliancy, reliability and scalability of clustered
   systems.

3) More easily integrate with other applications.

4) Provides for seamless upgrades between major releases.

5) Provides a means for third parties to build GUIs, that interact,
   through AJAX, with the API.

6) Disconnects groups from privileges.  These ought to be separate APIs.

7) Provides an easy means for cooperating grouper installations
   to synchronize selected groups.


My 2 cents.

Jim