MACE-paccman Working Group
2009 Spring Member Meeting
April 27, 2009

**Attendees**
Tom Dopirak, CMU (Chair)
Ken Klingenstein, Internet2
RL "Bob" Morgan, U. Washington
Steven Carmody, Brown U.
Tom Barton, U. Chicago
Michael Gettes, MIT
Rob Carter, Duke
Roland Hedberg, SUNET
Niels Van Dyk, Surfnet
Adam Stone, Lawrence Berkeley National Laboratory
Bill Yock, U. Washington
Brendan Bellina, USC
Mark Poepping, CMU
David Wasley
Scotty Logan, Stanford
Milan Sova, ESNET
Debbie Bucci, NIH
Sandeep Sathyaprasad, NIH
Juhani Gurney, NORDUnet
Ken Forstmeier, PSU
Tom Golson, Texas A & M University
Liela Florio, Terena
Lucy Lynch, ISOC
Mark Scheible, North Carolina State University
Michael P. Pelikan, PSU
Mike Grady, University of Illinois
Scott Fullerton, University of Wisconsin-Madison
John Krienke, Internet2
IJ Kim, Internet2
Ann West, EDUCAUSE/Internet2
Steve Olshansky, Internet2
Nate Klingenstein, Internet2
Emily Eisbruch, Internet2
Dean Woodbeck, Internet2 (scribe)

**Background**

Ken Klingenstein provided an overview of the previous privilege management attempt, Signet. In general, privilege management is the final addition to the identity management equation, along with directories, Shibboleth and Grouper.

Signet, it turns out, asked a lot from an enterprise. In retrospect, it was too much to ask that an enterprise drop this in on top of its IdM system and organize all of the roles and privileges at once. As it was funded under the NMI grant, which expires at the end of the year, Internet2 decided to end Signet as a funded project.

Interest in, and the need for privilege management remains. The MACE-paccman working group will determine the direction for the privilege management effort, with the concept of starting small and building as interest grows.

**Current**

Tom Dopirak reported that MACE-paccman has had just a few calls and is operating with these principles:

Coordination with Grouper
Gain an understanding of the commercial space
Benefit all of higher education
Business, policy and technology issues all in scope
The desired outcomes include developing frameworks, roadmaps and documentation of requirements. The role envisioned is partially architectural and partially consulting. The group has started to collect use cases.

The notion for paccman is to achieve a quick win. Some thoughts of what might constitute a win:

An implementation that works and is useful
The ideal is to not just have a framework, but something that is deployed. This is difficult, given that you are asking people to do something a new way. As this is developed, we will need to look for opportunities, people with concrete needs and particular problems to solve.
Something that serves a variety of applications
This may involve stakeholders (auditors, data stewards, security, application users)

**Privilege Management Survey**

Rob Carter reported on the Internet2 Privilege Management Survey, with the goal of answering these questions:

Are institutions positioned to take advantage of privilege management (e.g., do they have directory in place, groups in place, etc)
What are the functional and technical requirements institutions have for privilege management?
What impediments are there to PM adoption?
The survey went to the Signet working group, participants in a privilege management workshop, and the EDUCAUSE identity management mailing list.

The survey received 25 responses. In summary:

· 18 completed the functional questions; 16 the technical questions

· Respondents were about evenly split between publics/privates

· Respondents’ IT strategies: 72 percent “balanced,” 21 percent centralized, 7 percent distributed

· 66 percent reported operating a central IdM

· 45 percent use central group management (mainly Grouper)

When asked how well the centralized PM address their needs?

38 percent said “meets neither current nor future needs”
37 percent said “meets current needs, not future needs”
25 percent said “completely meets current and future needs”
Business drivers for implementing PM – top three problems reported by respondents:

Slow or inaccurate on/offboarding
Privilege snowball – for example, people enter as a student, gain access, gain more privileges as they move into different roles, but never lose their old privileges
Auditability and transparency of authorization
There was a comment that this suggests a key driver for privilege management may be security (the last two bullets for business drivers are security related).

Desired technical features

Privileges assigned based on coarse affiliations (ePPA, dept. affiliation, etc)
Scoping of privilege targets (for example, someone can access payroll, but only payroll for a certain dept)
Privileging based on roles or group membership
Least popular technical features

Manual override and ad hoc privilege assignment (want it automated)
Periodic attestation (grant a privilege and then, a few months later, the system comes back to ask if person should still have that)
Temporary privilege transfer (e.g. vacation coverge) – some people actually intent on NOT wanting this
Technical requirements (private institutions v. public institutions)

Technical requirements vary slightly between public and private institutions
Public institutions show moderately more concern with auditing/reporting
Private institutions show moderately more concern with granular privileging, APIs and automation, and workflow.
Technical (centralized vs. decentralized IT)

Technical requirements vary more widely with the reported degree of centralization of IT
Highly distributed sites report greater interest in automation and workflow and less interest in reporting
More centralized site report less interest in automation
More detailed results available at the MACE-paccman wiki

(https://spaces.internet2.edu/x/9oEX)

**perMIT**

Michael Gettes reviewed a permissions tool under development at MIT.

Central repository – feeds data to other systems, which enforce authorization.
Permissions (ASPECs) are defined in understandable business terminology, not arcane terminology of each system
Define “functions” (transactions or roles for which permissions should be assigned) at the appropriate level
Maintenance of permissions are distributed to departments, labs and centers – keeping maintenance activities close to the people who understand the business needs (delegated administration)
- Background

RolesDB has been in use at MIT since 1998
Three-part description of permission (ASPEC)
· Who, what , where (who can do what to where)

(also called person-function-qualifier)

· Started Feb. 2009. Hope to implement during 2009

- Examples of three-part ASPEC (person + function + qualifier)

Joe + Can Access + Oxford English Dictionary Online
Jane + Can Download + MS Office 2007
John + Can Modify V-Mail Forwarding + 6172589850 (John can modify the voice mail forwarding for the phone number 617-258-9850)
Jerry + Can Create Functions + in category HR
Juan + Can spend & commit + on cost object Q678543
- Simple Design Complex Capabilities

Categories contain functions
Each function is associated with a particular type of qualifier
More than one qualifier type can exist within a category
A function can have child functions (inheritance)
Qualifiers are organized into hierarchies (inheritance)
- Capabilities

Explicitly defined permissions
Rules to generate and maintain permissions
Can input groups into ASPECs through rules
Delegation of administration
APIs via SOAP/WSDL (Kuali student oriented) – REST being considered
Limited UI – APIs allow for UI development
- Production Usage

SAP Financials (spending, approving, requisitions, etc)
Student Systems (admissions, registration, fin aid)
Environment Health and Safety
HR (various transactions, reporting)
Central services (data warehouse, MIT ID system, master department hierarchy, roles database)
More information and opportunities to become involved in the perMIT project can be found at

http://wikis.mit.edu/confluence/display/PERMIT