Minutes: MACE-paccman call of 22-Dec-2011

*Attending*

Tom Dopirak , CMU (co-chair)
Keith Hazelton, U. Wisconsin (co-chair)
Mark Scheible, MCNC
Chris Phillips, CANARIE
Benn Oshrin, Internet2
Steve Olshansky, Internet2
Emily Eisbruch, Internet2, scribe

===========

*New Action Items**

[AI] (All) work on the access management recipe, with particular attention to figuring out and filling in the gaps
https://spaces.internet2.edu/display/macepaccman/Access+Management+Recipe++V2

[AI] (Keith) will propose a strategy for how the OSIDM4HE provisioning and access management teams can work in ongoing alignment with MACE-paccman and vice versa

[AI] (Emily) will talk to Dean Woodbeck about scheduling an IAM Online Webinar in June 2012 to focus on presenting the recipe work.

**Carry Over Action Items**

[AI] (Keith and Rob) will investigate the access management and provisioning work under way in OSIdM4HE and report back

[AI] (Rob) will look into cross - linking of the wiki content between the paccman and OSIdM4HE subgroups

[AI] (RL "Bob") will share links to public docs on GoogleApps provisioning (Keith will remind Bob)

[AI] (Keith) will add to the agenda for a future paccman call:

- Gartner use case classification review
- SCIM work (update from ChrisP and TomZ)

[AI] (Keith) will test the definitions from the recipe work on "Access Control Policy Management" against the paccman use cases and report back to the group.
https://spaces.internet2.edu/display/macepaccman/Privilege+and+Access+Management+Recipes--A+Discussion-starter+Draft

===========

DISCUSSION

*Access Management Recipe*

Redrafted recipe review
https://spaces.internet2.edu/display/macepaccman/Access+Management+Recipe++V2

- Completing/ Incorporating "Authorization Techniques and Strategies" subpage

Question: should some of the work on the subpage titled "Authorization Techniques and Strategies," authored by ChrisP, be promoted to the top level of the recipe?
https://spaces.internet2.edu/display/macepaccman/Authorization+Techniques+and+Strategies

- ChrisP : the intent of the subpage was to highlight the pieces regarding groups vs roles or entitlements
- this is info geared to software architects
- it's OK to keep the info as a subpage off the main recipe

- TomD: the groups and roles vs entitlements section is something we should probably fill out more and then include at the top level
- it's a topic that comes up over and over again
- TomD has some text he can insert there

- ChrisP: This topic of groups vs roles vs entitlements has come up in SCIM
- There has been discussion of how commercial vendors see this topic
- Some commercial vendors think groups is a euphemism for role, and some vendors try to convert everything to groups
- So extra info and context about these approaches is helpful

Q: How are groups vs roles vs entitlements handled in Oracle?

A: Oracle leverages groups. The database itself has explicit allows and denies … they don't use the word entitlements,
however Oracle acquired an entitlement server product a year and a half ago.
http://www.oracle.com/us/products/middleware/identity-management/oracle-entitlements-server/overview/index.html

A: Keith: UW-Madision has experience with Oracle human capital management for the new HR system
- Oracle uses the terms "role" and "permission"
- Each role is associated with a permission list
- Those correspond to fine-grained access control determining what you can and can't do in functional screens in the Human Capital Management app

===========

*Format for Publishing the Recipe*

Q: Do we want one big document for the access management recipe or do we want subpages with deeper content?

A: TomD: based on the LDAP recipe, it was a stand-alone document with a few links, meant to be static

- the LDAP recipe was meant as a starter's guide, a 101 level, a place to get up to speed
- access management as a distinct topic is fuzzier, so a recipe will not be as crisp, but it will still be helpful

Q: Does it make sense to publish a PDF version of the access management recipe wiki content at a certain point?
(Confluence can turn subpages into chapters), then the content can be updated later and a new version published at a later date?

A: Yes, makes sense

===========

*Collaboration / Coordination with OSIDM4HD*

- Keith: It's important to be sure that we work effectively with the OSIDM4HE provisioning team and access management team
- overlapping memberships is one way to do this.
- ChrisP and Keith will discuss ChrisP getting more involved in the OSIDM4HE effort

[AI] (Keith) will propose a strategy for how the OSIDM4HE provisioning and access management teams can work in ongoing alignment with MACE-paccman and vice versa

===========

*Is Recipe Meant to be Catalog or Position / Requirements Doc?*

Q: is the MACE-paccman access management recipe a catalog of possible approaches or is it about taking a position and outlining requirements, such that an OSIDM4HE developer could use it to get requirements?
A: The recipe is not a requirements doc, but it could be seen as a "stake in the ground"

TomD noted that at CMU they had 3 basic starting requirements:

1. Must be able to know what kind of access any subject has across soother systems

2. Must know who has what access in a particular system

3. Must be able to remove all access for one individual in an hour (this is by far the hardest of the 3)

- Keith noted that use cases are good sources of requirements
- There is a good collection of use case tabulations on the MACE-paccman wiki
- These should be minded for requirements
- That would be a recommendation to the OSIDM4HE access management team -- here is a good place to start

ChrisP suggests that we make "using the characteristics of a solid approach to access management" as the guiding principle of the recipe.

===========

*Targets for Completing/ Presenting the Recipe*

Suggestions as targets to shoot for:
- Present the recipe work at an IAM Online Webinar in 2012
- Present the recipe work at Internet2 Spring Member Meeting

- there could be another 6 months of work to be ready for presenting comprehensive coverage of the topic
- might not have to document the ERP solutions in this recipe, since those are so complicated
- perhaps we should stay at a more basic level
- In April, at SMM, we could present most content and highlight where there are still gaps, still work to complete on the recipe

[AI] (Emily) will talk to Dean Woodbeck about scheduling an IAM Online Webinar in June 2012 to focus on presenting the recipe work.

===========

*Adding a Framework Example to the Recipe*

- Should we add a concrete framework/example throughout the recipe to make it easier to grasp?
- perhaps an example focusing on a mail system or a bulletin board system?
- this could be a generic framework that everyone has some level of understanding with
- Like the bedtime story used in InC to explain federation

- Most helpful to provide an illustrative use case after the general definitions and the abstract ideas
- Downside of an example throughout is that people can get bogged down in the details of the example

===========

*General Definitions Question*

Q: Should "subject" be in the general definitions at the to top of the recipe?
A: Probably not, since that is not a specialized term for access management

Perhaps link to the simple glossary, where Subject is defined.
https://spaces.internet2.edu/display/macepaccman/Another+Glossary+Page

===========
Next MACE-paccman call: Thursday, 5-Jan-2012, 1pm ET