***Signet Call, 06-June-2008***
**Attending**
Mike Olive, Stanford (chair)
Gary Brown, U. Bristol
Rob Carter, Duke
Klara Jelinkova, Duke
Tom Barton, U. Chicago
Renee Frost, Internet2
Ann West, EDUCAUSE/Internet2
Dave Donnelly, Stanford
Chris Hyzer, U. Penn
Josh Drummond, UC-Irvine
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)
**New Action Items*
*[AI] {Klara} will prepare and post on the wiki a draft version of an assessment instrument for evaluating Signet.
[AI] {Group} will review Chris's Hooks and Notifications Summary email and inform him if there are disagreements with it.(see https://mail.internet2.edu/wws/arc/signet-dev/2008-06/msg00009.html)
[AI] {Group} will review Chris's Proof of Concept after it is sent out.
**Carryover Action Items**
[AI] {Dave} will write up his understanding of what Chris is asking for in the area of notifications and will add this to the requirements as something that has been deferred.
[AI] {MikeO} will send a note out to the list with some context about auditing issues and requesting folks to talk with their respective auditors for their perspectives, and report/discuss via the list.
[AI] {MikeO} will develop an initial strawman set of test cases to float to the list for feedback. Mike will also contact U. Washington for information on their authority manager (ASTRA), for additional data points about how other systems approach these issues.
***Discussion***
**Assessment Tool for Signet**
Klara plans to create an assessment tool to revisit functional requirements for Signet. The tool/survey will be given to eight schools that are fairly far along in implementing privilege and role management. Results will be used to create a gap analysis describing where Signet is and where it needs to be. The group agreed that this analysis would be very helpful.
Klara is creating the assessment tool and will check it with the Signet working group before sending it out to the eight schools. Klara’s goal is to produce a final report in next two months.
[AI] {Klara} will prepare and post on the wiki a draft version of an assessment instrument for evaluating Signet.
** Hooks and plug-ins **
Some frustration has been expressed about the amount of time devoted to discussion of hooks, notifications, and plug-ins. MikeO explained that new players have become involved since the topic was discussed in 2007, and that’s the nature of community. The hope is to lock down decisions within the next two weeks.
Josh was concerned about suggestions in a previous Signet-dev call that we release a version of Signet with basic hooks and plug-in functionality and expect people to change Signet code if greater functionality is needed. Josh supports making Signet as extensible as possible without the need to modify the core code.
MikeO stated that two topics that still need to be resolved are the handling of:
1. long-running transactions
2. post-hook notifications
Chris reviewed decisions from the 28-May-2008 Grouper-dev call.
- There will be a common way in both Signet and Grouper to configure plug-ins. But since the infrastructure is different in Grouper and Signet, the hooks and plug-ins will behave a little differently.
- Chris is working on a proof of concept example with sample hooks that have no multiple event registration (no multiple plug-ins per hook). This will not be applicable for Signet.
- In Grouper, there will be both pre and post-hooks. However, the definition of post-hooks in Grouper will be different from the definition in Signet. Grouper’s post-hooks happen after a query goes to the database, but BEFORE the commit happens.
- Creation of an audit log for Grouper has been discussed on the Grouper-dev email list as a way of facilitating roll-backs for long-running transactions.
The exact design of auditing has not yet been determined.
- Post-commit notification in Grouper would be based on the audit log or some notification log in database.
- Transaction vetoes in Grouper would be communicated by a subclass of runtime exceptions.
- Hooks will be synchronous. However, to make a hook asynchronous, only three lines of code will be needed.
MikeO summarized some of the differences between the Grouper framework and the Signet framework for hooks and plug-ins.
- Unlike Grouper, Signet does not currently have long-running transactions. In Signet, batch transactions get decomposed into single transactions with a single notification for each.
- Signet will have post-hooks after the commit.
MikeO’s concern with the current proposed architecture for hooks and plug-ins in Signet –- regardless of notification used -- is the opportunity for data inconsistency. For example, if in a plug-in, something gets provisioned to LDAP, and then later for some reason the commit fails, how does that get cleaned up? Chris replied that in Signet, a post-hook could be used to update an external system. But things could still potentially get out of synch if, for example, 1) the app server is turned off after one commit but before LDAP is updated, or 2) if LDAP is down.
It was noted that if Signet ever switches to using long-running transactions, then post-hooks after the commit wouldn’t be effective anymore. Dave stated that implementation of long-running transactions would be a major architectural change for Signet.
In Grouper, there is only a fine difference between pre- and post-hooks. Grouper actually has two variations of pre-hooks: an early pre-hook and a later pre-hook. Both are prior to committing; there is no post-commit post-hook in Grouper. Post commit, there will be an audit trail.
What is needed to build reliable notification into Signet and Grouper? It was suggested that post-hook notification is not a good idea, but that instead it would be better to integrate notification (possibly using a third-party notification technology) with an audit or change log.
**Wrap-up of Hooks and Plug-ins Discussion**
The group agreed to end the hooks and plug-ins discussion because all major issues had been decided.
Discussion of the audit log -– and exactly what needs to be recorded -- will occur on the next Grouper-dev call.
[AI] {Group} will review Chris's Hooks and Notifications Summary email and inform him if there are disagreements with it.
https://mail.internet2.edu/wws/arc/signet-dev/2008-06/msg00009.html.
[AI] {Group} will review Chris's Proof of Concept after it is sent out.
The next Signet Working Group call is scheduled for Friday, June 20, 2008 at 11am EDT.