Grouper Developers Forum

[Jim Fox <>]

re: Grouper dev action item regarding HA grouper

These are some questions that came up as we implemented an 'HA web
service', one that allows the service to respond quickly to the most
common requests and to continue service, for queries anyway, through
outages of the grouper registry.   The design uses a clustered LDAP
service as a resource for selected requests.


1) Which queries will be HA?

   About 90% of requests to our web service are two kinds of GETs:

     . Is the user an effective member of a group?
     . What groups is the user an effective member of?

   The latter is the request our IdP makes.

2) Clients should be able to manually direct queries to the registry,
   assuming that HA is the default.

3) The HA response must be complete and contain the same information
   as a normal, registry response.  A RESTful service normally includes
   an ETag, or similar, with the response of any object that can also be
   PUT, i.e. a membership.  We do not make direct memberships HA for
   this reason - our LDAP HA cannot generate the correct ETag.

4) The HA system must respond correctly to sequences such as this:

    . One client PUTs a member to a group.
    . Immediately, a different client GETs the member,  using HA.

   We allow PUTs to specify a 'synchronized' parameter which causes the
   service to wait for LDAP update before returning a response.

5) The service must wait for all members of the LDAP cluster, not
   just the master.

6) All appropriate ACls must be respected by the LDAP service.

7) If a Shibboleth IdP is using the Grouper attribute resolver it should
   be HA as well.

Jim