Signet Working Group conference call
August 18, 2006
*Attendees*
Lynn McRae, Stanford U. (chair)
Dave Donnelly, Stanford U.
Gary Brown, U. Bristol
Brendan Bellina, USC
Tom Barton, U. Chicago
Bill Turner, Cornell U.
Steve Barrett, Cornell U.
Joy Veronneau, Cornell U.
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
New *Action Items*
[AI] {Jessica} will create a new space in the Internet2 wiki for I2MI-Common related documentation.
[AI] {Dave} will update the requirements text to reflect the upgrade to Java 1.5.
[AI] {Tom} will email the grouper- and signet-user mailing lists to probe for issues related to versioning changes.
[AI] {Tom} will email the list with potential contacts at Macquarie University.
Carry Over *Action Items*
[AI] {Lynn} will request use cases and other agenda topics for the CAMP program. (21-Jul-06)
[AI] Contact {Lynn} if you identify additional functional requirements for your local project. (28-Apr)
[AI] {Bob} will send .htaccess local syntax to the group via the list.
[AI] {Group} will develop use cases for Signet.
[AI] {Minh} will develop a list of requirements for how Signet will interface with LDAP and Grouper.
[AI] {Lynn} will write up a person and function summary to express the relationship of privileges to roles and to determine what gets expressed in the eduPerson entitlement space.
*Agenda*
1. The Signet Wiki status
2. Java and other versioning questions (cf. Lynn’s email, 17-Aug)
3. Notification interface requirements, some information gathering (cf. Lynn’s email, 18-Aug)
4. Signet and XACML, where we are and interest from Cornell (cf. Lynn’s email, 18-Aug)
*Discussion*
The Signet wiki is now open to the public anonymously, confluence-users, and to WG members with a login. There is a Project section devoted to the WG and its members. Comments and suggestions are welcomed, and may be sent to Jessica via email or via the Signet Public links. {Jessica} is working to revamp the Signet Home and Working Group web pages. The Signet product documentation will be removed from the web and will exist only in the wiki; a formal announcement for the opening of the Signet wiki will follow.
The Group expressed interest in creating an area for items that are a result of the collaborative efforts of or are to be shared amongst all Internet2 middleware. As items related to 3rd party libraries and Subject API look for a permanent home, a wiki space would serve to meet these initial needs. [AI] {Jessica} will create a new space in the Internet2 wiki for I2MI-Common related documentation.
The Group discussed whether there were any issues regarding the decision to use Java compiler version 1.5. {Lynn} emailed a set of questions along with the agenda, pertaining to versioning:
- Aside from Dave, does anyone else have a significant amount of existing code that might be affected
by switching from 1.4 to 1.5? (no)
- Does _your_ IT infrastructure support, or even allow, 1.5? (no major resistance)
- Will there be any issues if Grouper / SubjectAPI remain on 1.4 and Signet moves to moves to 1.5?
(probably not)
- Will there be any issues with any 3rd party libraries currently used by Signet? (probably not)
[AI] {Dave} will update the requirements text to reflect the upgrade to Java 1.5. [AI] {Tom} will email the grouper- and signet-user mailing lists to probe for issues related to versioning changes.
Cornell is working on a notification module, and the Group discussed requirements and other issues. See Lynn’s email, appended below [0]. He wants to expand the list to a precise set of lifecycle events in a privilege; auditable events that would notify a module and take action, if necessary. Cornell is looking for an application of this to iCalendar, by means of sending XML to an engine for parsing. The iCalendar event then becomes a message that is emailed to whomever the local implementation desires. This idea would translate over to the use of Signet and Grouper as well. This discussion also lead to how it could make Signet or Grouper events available to other EDDY agents. Signet could potentially have another ‘attribute of interest’, e.g., an email address, which Signet could collect and then use for such purposes. For any given event, an email is generated; another possibility is to gather events and issue a single email based on a specified number of those events, or per date. In a more general sense, what are the identifiers that ought to be shared when the subject identity is shared?
{Lynn} followed up on an email [1] regarding the use of XACML with Signet. {Tom} pointed out that a larger problem with using XACML is that it is not widely used and few have experience working with it. A good designer could work with the XACML, while others work with the metadata or use a translator. The Group will continue discussion on the incorporation of XACML into Signet, and will proceed slowly. [AI] {Tom} will email the list with potential contacts at Macquarie University.
The next Signet Working Group call will be on Friday, September 1, 22006 at 11am EDT.
“”””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””
[0]**Subject: Signet and Notification Requirements** (cf. Lynn’s email 18-Aug-06)
I have a couple of goals for our discussion of notification in the call. First is to remind folks of the Signet requirement we are fleshing out. The original specs at <http://middleware.internet2.edu/signet/docs/signet_func_specs.html> don't go into much detail:
19. Signet must support automated email notifications, site-configurable, for
* New assignments.
* Revoked assignments.
* Assignments waiting too long to meet prerequisites.
I would expand this list to these possible situations:
- New assignment, privs activated -- notify grantee
- New assignment, pending pre-reqs -- notify grantee
- Assignments still awaiting pre-req after "n" days -- notify grantor and grantee
- Effective date reached, assignment activated -- notify grantee
- Pre-reqs met, assignment activated -- notify grantor and grantee
- Assignment modified with privilege change (or expiration date change?) -- notify grantee
- Assignment manually revoked -- notify grantee
- Assignment expires in "n" days -- notify grantor and grantee
- Assignment expired -- notify grantor and grantee
- Assignment revoked by condition -- notify grantor and grantee
In these cases "grantee" applies to individuals, not to groups.
I would be the first to say that this list looks like overkill, that any specific site might just pick a handful as useful. What we're aiming for is an approach that makes that question irrelevant, that Signet can easily accommodate the simple awareness of some number of "moments" and inform a notification module,. Then it would be configuration, or the simple process of providing a handler for a case, that decides whether a site is doing that notification or not.
Some assertions/questions:
1) Implement notification via some plugin/adapter approach,
providing for alternate implementations (e.g., Cornell's)
2) Determine basics of this API -- subject identity (granter and grantee),
assignment or privilege information, "situation" per above?
How to pass other data, like which pre-req is missing?
3) Email address?
4) Signet should ship with a simple implementation that takes the call,
formats text (via templates?) and sends email on a case by case basis
(platform, mailer differences?)
“””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””
[1]**Subject: Signet and XACML output, our story so far** (cf. Lynn’s email 18-Aug-06)
Here's a quick summary of where the discussions of Signet and XACML have led us to date. The main issue is how to map the privilege artifacts produced by Signet into the language of XACML rules.
Signet expresses privilege information along the lines of who (subject), a permission, scope, and qualifiers (limits). Anyone interested in interpreting this information for a specific purpose simply needs to know the layout of the information as determined by the privilege definer, and that consumer can then define their own mapping into local security rules. This serves the needs of provisioning permission information to target systems adequately. When we talk about mapping this data to something like eduPersonEntitlements, we observe the same thing ... make the entitlements you need and tell people how to use them.
XACML assembles such information into rules and provides structure that enables the interpretation of the rules to answer authorization questions. This structure separates resource from action from qualifiers, for a couple of reasons. First, it supports a natural "can this person do this to that?" style of interaction – can <subject> take <action> on <resource> -- that makes any qualifiers (limits) a part of answering the question, not part of asking it . It also makes it easier for a policy engine to scan and find applicable rules to fit specific questions (all rules about building X, or account Y).
One thing is unusual about this situation. The XACML we would produce would not necessarily be expressing institutional policy or global rules. Rather, it would be permission rules about just the specified subject (I once referred to this a a "policy of one"), and for a given situation we could produce XACML expressions targeted to a situation. Nonetheless, I think we still need to fit our information into XACML in some well-formed way.
Our challenge is that neither the <resource> or <action> are explicitly identified in the Signet data. Which of two limits is specifying a resource (e.g., a budget) vs a qualifier (a dollar amount)? Which limit is expressing an action (e.g., read/write) vs. the resource (a file)? Perhaps the function itself (e.g., "check out books") provides that information implicitly.
We left things with the thought that we could close this gap with some declarative information in the function/permission metadata, essentially encoding the rules for creating an XACML expression from the data. It might be as simple as indicators:
<limit id="building" in-xacml-this-would-be-the="resource">
well you get what I mean. There were a couple of other XACML related cleanups, like whether Scope is relevant or not to the interpretation of a permission (whether it should be added to the rule as a qualifier). But we think it all could be handled through the metadata.