Signet Call 24-Oct-08

**Signet Call 24-Oct-08**

**Attending**
Mike Olive, Stanford (chair)
Dave Donnelly, Stanford
Chris Hyzer, U. Penn
Bill Kasenchar, U. Penn
Josh Drummond, UC-Irvine
Neil Matatall, UC-Irvine
Rob Carter, Duke
Klara Jelinkova, Duke
Steven Carmody, Brown U.
Jim Repa, MIT
Bert Bee-Lindgren, Georgia Tech
Eric Buckhalt, Georgia Tech
Datta Mahabalagiri, UCLA
Warren Leung, UCLA
RL "Bob" Morgan, U. Washington
Tom Barton, U. Chicago
Albert Wu, UCLA
Ann West, EDUCAUSE/Internet2
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)

**New Action Items**

[AI] Dave and Mike will focus on these priorities in wrapping up the current phase of Signet:
- web services interface (RESTful style)
- hooks and plug-ins example
- knowledge sharing with the Grouper and COmanage teams
- integration with EDDY

[AI] Albert Wu will forward to the group a UCLA use case for Signet.
https://mail.internet2.edu/wws/arc/signet-dev/2008-10/msg00020.html

*Carryover Action Items*

[AI] Klara will send out the survey invitation to a broader group, including the Educause IdM CG and CSG lists, with instructions for the recipients to direct it to the appropriate staff within their organizations.

**Discussion**

- Next/remaining steps for current Signet product
What work should be done between now and the end of 2008 to complete the current Signet effort?

Suggestions included:
- work on web services with RESTful style interface -- this is on the roadmap:
https://wiki.internet2.edu/confluence/display/i2miCommon/Combined+Roadmap
- actual example of code that makes use of hooks (Dave said he is removing the
hard-coded history record generation/creation from being embedded in Signet
and moving to into a plug in. That will serve as an example of how to implement a
plug in and how to interface with an external system from the plug in.)
- Integrating with EDDY.
- implement a widget for a dynamic limit of some sort.
- knowledge sharing to prepare for possibility of moving parts of Signet into Grouper or COmanage.

- Compose and build consensus around a new strategy for MACE
privilege management

The group discussed various aspects of building a new privilege management strategy.

Chris: U Penn does privilege management on an application-specific basis. An application asks FAST (Framework for Administrative Systems and Technologies) “does Joe have this privilege?” Finding the answer involves joining to the group membership table. It makes sense to centralize that logic so the applications don’t have to do it.

https://mail.internet2.edu/wws/arc/signet-dev/2008-10/msg00012.html

https://mail.internet2.edu/wws/arc/signet-dev/2008-10/msg00007.html

Bob noted that there are two ways (at least) to integrate privilege management.

1. A privilege management system can manage data and push it out, either provisioning the data into applications or into a privilege store that can be queried. (The homegrown privilege manager at U. Washington works this way)

2. A privilege management authorization decision service or PDP where a protocol is needed to ask a question. This is more invasive and requires more commitment from the applications.

MikeO: how can we make first incremental steps to providing a simpler mechanism that would meet people’s needs? Should we encourage third party systems to go to LDAP for both group and privilege definition?

Chris: LDAP is one of the stumbling blocks of why Penn is not as interested in Signet. With Grouper and LDAP, you do a query and you get back an answer. However, with Signet, data is received from LDAP and there is still a need for a lot of logic work. Web service standard is better than LDAP.

Q: Are privileges parameterized and groups Boolean?

TomB: Depends on how privileges are to be used.

TomB: There is a lot of common capability that should be in an integrated interface to allow management and query of privileges and associated subjects (people) with them, whether they’re in groups or not. Things can be done incrementally with an integrated interface. A layered approach is attractive.

Jim Repa : It’s important for an application to be able to query about a subject and a transaction they want to perform (“Can Joe spend $ on account 1234?”)
and get back a “yes” or “no”. It’s problematic to have every application get a lot of stuff back and need to interpret that.

TomB noted that there are two approaches to privilege management:

1. Deep administrative systems, like FAST at Penn, and perhaps what is used at MIT. Also Kuali Rice and KIM (Kuali Identity Mgmt.) https://test.kuali.org/confluence/display/KULRICE/KIM+Overview
are a suite of big administrative systems that will have a common means for resolving security questions. These systems provide a granular application-specific set of permissions and assignment to roles.

2. Approaches that provide more grazing, a slice only of those very granular application-specific permissions.

Klara: At Duke, the PeopleSoft/ERP systems have solved the privilege management questions. It’s other applications that need a solution. The tie in between Grouper and privilege management is compelling for Duke. A privilege management add-on to Grouper would be attractive.

StevenC: At Brown, also privilege management in the ERP area is solved. Privilege management for collaborative applications is needed. Another smallish problem: privileges on crossing firewalls within the campus network; who is allowed to cross firewalls? Start with a small set of issues that are solvable.

Bert: At Georgia Tech, the biggest problem with privileges is the inability to automatically remove them. Privilege parameters reside inside the PeopleSoft applications. But a central application is needed that has all info and can remove people from groups.

Bert noted that much privilege management can be accomplished by parameterizing groups in Grouper.

Albert Wu stated that at UCLA, they had been hoping to use Signet in the future. Albert commented that groups and roles must be mapped to permissions. Signet is about surfacing those permission mappings to a central repository. This allows auditors to have a place to audit without having to pull detailed records from every application. If some privilege management capabilities are added to Grouper, but there is not a central repository for auditing, there will still be a hole missing.

Albert: At UCLA, we are most likely going to continue with Signet in pilot. But we wouldn’t be able to contribute changes back to community and manage it.

[AI] Albert Wu will forward to the group a UCLA use case for Signet.
https://mail.internet2.edu/wws/arc/signet-dev/2008-10/msg00020.html

TomB: In moving forward with a privlege management strategy, we must solicit needs from various organizations who are willing to make a commitment to piloting.