Grouper Developers Forum

["Jessica Bibbee" <>]

Signet/Grouper Hooks call
May 17, 2007

 

*Attendees*
Tom Barton, U. Chicago (chair)
Blair Christensen, U. Chicago

Jeff VanEeuwin, U. Chicago

Dave Donnelly, Stanford U.

Lynn McRae, Stanford U.

Will Norris, USC
Gary Brown, U. Bristol

John-Paul Robinson, UAB

Jessica Bibbee, Internet2 (scribe)

 

New *Action Items*
[AI] {Lynn and Tom} will propose a set of useful points of control to flesh out requirements and identify immediate use cases.

[AI] {Jessica} will schedule a follow-up Hooks call and send out an invitation to the attendees.

*Agenda*

1. I2 IP framework
2. background
3. discuss functional requirements
4. discuss technical approaches (time permitting)
5. wrap-up AIs

 

*Discussion*

{Lynn} opened the discussion by reiterating the intent to have a less technical, more general approach to the topic of hooks.  The idea of hooks is that there are critical points of functionality that will routinely require business logic and extra points of control with a wrapping layer, the architecture of which should easily combine with the core code of, e.g., Signet or Grouper.

 

{Lynn} shared the specific needs of Signet driving the idea of hooks, which points mainly to integration. He clarified that hooks are a good way to enhance the capabilities of a product with the notion that business needs exist. Hooks could signal whether an assignment was made or when privileges change, for example, in advance of an expiration date. One could add their own business logic as necessitated.

 

{Jeff} volunteered a couple business requirements: 1) on the Signet side, there is a need for a way to determine IF an assignments ought to be made BEFORE the assignments is made, by way of reviewing the grantor, grantee, and their relationship. For example, a grantor cannot belong to a group where a grantee can approve expense reports. 2) on the Grouper side, there is a need for a way to make sure a subject doesn't belong to more than one group when they change memberships; it would address whether a post has violated a rule prior to changing memberships. {Lynn} paraphrased the intent by saying that it is not just a passive callout that would be aware of events, but one that could actually abort a transaction on its own. It would present the user with a message detailing the error or aborted assignment.

 

Another advanced use of hooks that could benefit the Signet/Grouper relationship would be to notify Signet when group memberships change in Grouper, such that Signet could react and reissue privileges immediately. {Tom} noted that this is just one of a much larger set of requirements and functionality to integrate Signet and Grouper. {Dave} commented that the integration of Signet/Grouper might be the ultimate example of business requirements between the two. It would help to define a base set of hooks by directly accessing the API.

 

{Dave} commented on the control aspects of using hooks, which then send messages to Signet/Grouper. A listener would act to kick-start a chain of events with Signet or Grouper, enabling control in these hooks. 

 

{Lynn} asked about requirements for synchronous and asynchronous callouts. {John-Paul} thought that synchronous seemed easier to implement, though a specific use case would still be helpful to outline. While {Tom} thought asynchronous seemed out of scope, {Dave} posed that the opposite would be true. He said that listeners would only need to provide events that the plugins would act upon, whereas synchronous requires more integration. {Lynn} said that each point of control would need to be analyzed as it makes sense for the API, possibly with a TRUE/FALSE. How to define the point of control and how to apply it?

 

{Lynn} spoke of various points of control, such as pre- or post-processing. Also, there could be entry/exit of each module, perhaps better defined as the addition/subtraction/deletion of a group.

 

{Dave} mentioned having Signet/Grouper use interfaces and perhaps abstract events classes to be used in a case-by-case situation by creating assignments. He asked, with respect to plugins, how Signet/Grouper would know which would take precedence for the same event. {Gary} said it would be important to specify the order in which they go, especially on the synchronous side.

 

{Gary} requested that there be a mechanism for wrapping these various hooks, such that several sets of hooks that might be encapsulated by one plugin. {Lynn} suggested that there could be one plugin with the main responsibility to call out to a rules engine for coordinating the logic. {Gary} said it ought to be easily configurable for different sets of people working on various integration points. A file could identify which plugins would be invoked in which order. {Lynn} suggested that the hooks would likely be java-based and community shared for further connecting to other pieces.

 

[AI] {Lynn and Tom} will propose a set of useful points of control to flesh out requirements and identify immediate use cases. [0]

 

The attendees expressed interest in a follow-up Hooks call, to be scheduled after each of the Signet and Grouper Working Groups have a chance to separately discuss their motivations around hooks development. [AI] {Jessica} will schedule a follow-up Hooks call and send out an invitation to the attendees.

 

The next Signet/Grouper Working Groups Hooks call will be announced on the Signet/Grouper –dev mailing lists.

 

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

[0] c.f. Lynn's email, 25-May-07 <https://mail.internet2.edu/wws/arc/signet-dev/2007-05/msg00012.html>

 

Signet program hooks, some high level assertions ...

   * Defined at specific points of program control to address common site-specific needs
   * This could provide provisioning hooks among other points of control
   * An easy to configure plugin (or similar) approach that keeps site code distinct from Signet (or Grouper) code
   * Not meant to obviate any need to customize the core code itself, but should provide high value coverage and ease of product extension.
   * need synch and async capabilities (do sync first -- it meets functional needs of both cases)
   * Each point of control should not be limited to a single "listener" but be capable of engaging multiple callouts in a site-specified order
   * Might provide a simpler more consistent template for adapter class handling in general
   * Keep initial implementation simple!  it can grow.

Proposed Signet hooks:

1. Assignment, pre-commit
     - For regular assignments and proxy assignments?
          - Known need for former (regular assignments)
     - Requirement is to be able to
          - examine the assignment and approve/disapprove
          - ability to cancel the commit, with a reason code/message
          - possibly augment the assignment information?
     - A synchronous invocation of a site specific module
     - Uncommitted assignment object is passed as a parm
          - plugin needs to know Assignment API
          - plugin needs to know Subject API for grantor/grantee information

2. Assignment, post-commit 
     - For regular assignments and proxy assignments?
     - Can be asynchronous
     - Use case is to take a provisioning action,e.g., invoke message or a write to the directory
     - Pass the assignment on the call?
          - compare assignment vs privilege changes

3. Assignment activation
     - For regular assignments and proxy assignments?
     - Can be asynchronous
     - Not quite the same as post-commit, e.g., for future effective date, future prereq activation.  Also a provisioning use case.  (Do we need both?)

4. Assignment deactivation
     - For regular assignments and proxy assignments?
     - Can be asynchronous

5. Assignment reconciliation
     - This is when Signet re-evaluates an assignment to see if it has met prerequisites or

        no longer meets conditions.
     - Rules handle most of the need here
          - a rules interpreter could be implemented as just a builtin hook plugin
     - call out should basically implement the same interface as rules, returning a boolean true/false evaluation

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

Internet2 R&E Network Members
Community, connected.
http://www.internet2.edu/renm/