You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »

https://spaces.at.internet2.edu/display/Grouper/Grouper+Call+30-July-2014


Wiki Home

Grouper Release Announcements

Grouper Guides

Grouper Deployment Guide

Community Contributions

Internal Developer Resources

Post PSP Provisioning

Following on from the discussion on the July 3, 2013 Grouper Dev call and the July 29, 2014 and the August 27, 2014 Grouper Dev call, this page captures thoughts about the future of the PSP and directions for provisioning strategy. General consensus:

  • The PSP is weighted heavily towards trying to be all things to all people.
  • Due to the above, it suffers horribly in the area of performance.
  • The community believes that messaging and more specifically a queue is the future direction that they all need to move in
  • Building on the message-queue concept, Grouper should create a generic interface and message format that would translate changelog events into generic messages.
  • Grouper would also create an interface to read/validate messages
  • The community and project would use this message format and interface to write provisioners.
  • The two messaging systems that the Grouper project will launch with support for are ActiveMQ and Amazon SQS
  • Grouper will also attempt to write an implementation of the interface that does not rely on an external queue so that adopters who do not wish to run AMQ or connect up to Amazon could still run the provisioners locally.

General Requirements

General requirements moving forward for message queue readers:

  • Support incremental provisioning by reading events off the message queue
  • Support bulk reconciliation. Note: they may not be the same executable, but should retain and reuse code and configs where possible/practical.
    • When doing bulk-reconciliation the provisioner shall support optionally being pointed at a particular group or folder to reconcile 
  • Each module should be capable of being run in parallel with other modules
  • All provisioning modules will follow the Grouper configuration paradigms with properties overlays and expression language.
  • Modules shall provision based either on the location of a group in the tree as done today or using an attribute that will instruct the provisioner to provision the group and/or how to provision the group

Message Format

This still needs to be worked out.

  • Messages should be in JSON
  • Messages should always be signed
  • Messages will always carry their own metadata and consumers will not rely on the messaging system metadata but rather the grouper-produced metadata (this will keep our messages messaging-system-agnostic)
  • Message payload can be optionally encrypted to one or more keys

First Implementations

Prospective first implementations for Grouper 2.3 are:

  • LDAP
  • Active Directory

Configuration

The provisioning modules will be configured via properties files using standard grouper configuration mechanisms. Modules will be activated by either calling them from GSH for batch/reconciliation functions, or by the changelog consumer. The provisioners will support two kinds of configuration:

Global Configuration

Global configuration of the modules will be done by properties files specific to all instances of that module. Some of the envisioned properties set in these files include

  • Hostnames / connection endpoints of provisioned systems
  • Authentication information for provisioned systems
  • Logging options
  • Scheduling for running batch reconciliations
  • Conflict handling
  • Thresholds to prevent a provisioner from performing a change that would affect N% of users in a group
  • Transformation instructions for turning group names or membership names into a format that the downstream system expects

Group-Level Configuration

This needs to be re-thought in light of the message consumers. Do we put the attributes into the message to inform the downstream consumers about it or do we require the consumers to call-back into grouper for additional data. My gut says we should do our level best to ensure a message has all the data a consumer would need to keep speed up and callbacks down.

Group level configuration would be handled by attributes placed upon groups or folders. The following standard attributes are envisioned:

  • $NameProvision – when set on a group, that provisioner will provision the memberships to the target system.  When set on a folder, all groups under that folder will be provisioned to the downstream system.

Specific provisioners may specify additional attributes they will use to determine how to provision that group's membership. Some examples are:

  • Attribute to describe where in the LDAP DIT the group shall live.  If this is set, it will override any global configuration.
  • Attribute to describe the type of provisioning (members of this group shall represent Google Apps Organizations vs Google Apps Groups)
  • Customized provisioning thresholds (for this group, refuse to provision if more than N% of the membership is affected)

The Grouper UIs will also be updated to facilitate managing of these attributes.

  • No labels