Full Meeting Notes - Dec 2-3, 2010

COmanage/LIGO meeting - Dec 2-3, 2010 @ CalTech

Attendees:
Warren Anderson - uber-PM for LIGO IT stuff
Scott Koranda - chief architect
Stuart Anderson - head of computing for LIGO Lab; manager of the interface for the IdM system
Melody - "I just do stuff" (software developer, primary developer for the database and web interface)
Heather - project coordinator for COmanage
Benn - guy who does stuff too - architectural and development

Goal for this meeting:
* try to figure out how to get to a new release/replacement of MyLIGO in 4-6 months (sooner is better); do we take the next step with LIGO creating something, or figure out how much COmanage can provide in that effort; can COmanage do it all, do some, we need details
* when the codebase was transitioned, their second release went backward in functionality - they lost features; if we implement something, we have to have at minimum the functionality that they have now

Culture comment

* standards? RFC's?
* does not want a finished, polished product; want to be in an an agile development model; don't trust "finished" products

Regarding redesign

* (W) thinking of offloading as much of the backend to Grouper as possible; love grouper's functionality
* (SK) was thinking Grouper + some javascript would be sufficient to meet the immediate needs; thinking COmanage may do some of that; an implementation detail

Internal Questions/Thoughts (HF)
* create a second, separate LDAP for security? why? why not create a limited replica instead?
* internal decisions still pending - restricting even registration page to people who already have accounts who will have to fill out the request form for others
* features they love about grouper: fine grain auditing, permission on attributes, point-in-time auditing
* groups vs roles vs entitlements - conversation to have with Keith H. regarding glossary
* interesting point that LIGO actually isn't to support federated identity in the way that COmanage originally intended; so, the support for local identity will be necessary
* LIGO is curious if iPlant has as many edge cases (as described in the use cases below)

Current:
                 MyLIGO
LDAP ---- PHP ----  KDC
                |           |
         MySQL    Grouper (LDAPPC)
                           |
                         LDAP

* Want the MySQL piece to go away definitely, was thinking grouper would take over all of that; hoping that the whole thing would be replaced by COmanage
* They are also thinking to create a LIGOGUEST.ORG kerberos realm that will need a similar (perhaps more lightweight) registry structure as the main LIGO component

Plan prior to I2MM:

        web browser ---------  PHP/Phython (apache) ----------- KDC
                |
          Grouper
    RESTful interface
        LDAPPCng
                |
           LDAP

* want people with management credentials to have ways to query the system, get reports, etc

* VIRGO credentials also being managed by LIGO, but there are more politics here
* many classes of people to serve: different groups of scientists (LSC and Lab), granting agency access, organizations with paired research; if COmanage will be extensible to be able to add buttons or things to meet the diff org needs or something, that'll be awesome-sauce
* the new guest realm is the target to practice COmanage against
* given the remoteness of the instruments, there will need to be a certain amount of reduncancy built in here
* would love to have provisioning/de-provisioning of cluster accounts (tho' deprovisioning a cluster account with 20 TB of data is tricky)

Switch to discuss COmanage reference architecture diagram

* note that LIGO acts more as a VO platform than just a VO alone
* note that we could add a Reports tab to the COllabmin section and that's where an admin/manager could do the grouper auditing, for example
* would like reports to include something that pushes out to the inviters saying who has / has not accepted their invitations, etc
* will need to make sure we have a way to tweak things like "LIGO wants to set these policies for what can/can't be published, iPlant wants to configure a different policy"
* FERPA a concern
* need to add emergency contact, and only emergency response team or security office allowed to see it (this will be common enough and will need a use case - do we need a separate app for that? that's what's being done now)

COmanage post-institution access use case
* after a person leaves an institution, and that institution has a very short grace period, but grace period within LIGO is longer, the CMP will need to take over the authentication and other stuff for the person through the VO grace period

federated groups use case
* where icecube and ligo want to federate, the authorization will likely not be any specific individuals from icecube or ligo and so will need to consume IsMemberOf from one org or the other to flesh out the organization
(Credential Management Problem) COmanaged managed username/passwords use case
* an idp of last resort for individuals from wholly unfederated institutions who must have access to the VO information (maybe can use the model of having a KDC involved to meet this need)LIGO has tiered VO* a VO may consist of several smaller VO's (GEO for example, is comprised of 15 institutions, each of which is in some sense as VO) so management responsibility is distributed; the decisions of what needs to be managed at any given level changes over time; different tiered VO will have different requirements regarding how they distribute management responsibility
* monitoring system in LIGO is considered a "crowning jewel"
* have 5-10 new groups per year (are they VO or not? Does it matter)

Groups/Roles/Entitlements

* roles are essentially a short cut to being added to certain groups, mailing lists, applications
* what will COmanage do that group won't, what will be missing?
** in theory we can do anything the API supports; the way we want that to happen is to support that group services API (doesn't exist yet) and we can implement to that, and as long as something else implements to that as well, we'll be good; in the interim we'll do some hacks to get what we need and update as other availability; think of groups as vendor-specific API and what we want to code to is a more generic API for groups

AFTER LUNCH
* map information flow and understand how some of our use cases flow through the reference diagram

Use Cases

New Postdoc - SignUp through MyLIGO
this is an accepted process; no major changes expected/required
1 * signup takes you to a registration "adduser page"; Firstname/middle/last; email address is your only alias; Country is perhaps not used but there; "Describe your ligo affiliation" which is moderately problematic because many people coming in don't actually know their ligo affiliation (this may need to be moved); overall, ligo will need more than one signup page depending on affiliation - need to start with the affiliation question because the answer to that will actually change what information needs to be collected (LIGO wants invite-initiated for Lab (2 subclasses - fill out entirely for the invited user, fill out partially for the invited user), but wants user-initiated for other groups in LIGO); the COmanage name data model is different than what myLIGO has and we will need to sort out; every time a new group joins LIGO, that will need to adjust the signup page when asking "LSC member at"
** we have the invitation workflow documented in COmanage - is it sufficient? where are the gaps; current invite flow does not include self-invitation;
** need to be able to delegate roles for people submitting invitations and probably more
2 * after the signup page, an email is sent to uwm group managers
3 * uwm group manager goes to group management interface
4 * AuthZ against UWM group managers group
5 * UWM group manager sets values for postition/FTE/Research/LSC (Very Important for LIGO)
** some attributes provided by the applicant, some by the group manager
** these particular bits would not be in Grouper, they'd be in another common repository (LDAP or SQL or whatever is appropriate as we develop further)
** note that COmanage does not currently store passwords, and myLIGO currently sets the initial password (gap)
6 * PD gets email with result. If denied, email contains email address of authorizer
7 * If approved PD fills out  her contact info, etc and can change change password from default
** there will be security requirements on what reset passwords need to be, and would like to make password change forced; should be a timeout on the generated password and say so to the user

Name space collision

* if chosing a name that is already in use, nice little error message and request to chose a different name
* note that LIGO id is auto generated, thus the change-their-name requirement; would rather automatically change kerberos principle automatically than forcing people change names
* kerberos principles are never reused (LIGO needs to determine about re-provisioning returning researchers - how to validate it is in fact the same researcher)

Post-doc gets a faculty position
1 * PD fills out web form asking to transfer on a given date
** have pre-dating (this happened in the past on this date) but will need post-dating (this will happen on this date)
** interesting point that LIGO actually isn't to support federated identity in the way that COmanage originally intended; so, the support for local identity will be necessary
2 * unclear on what the rest of the process should be; maybe have the LIGO (identity of last resort) as the identity you need to use when transferring from old identity (post doc) to new identity (faculty); this seems more like a deprovisioning/new registration

Engineer joins LIGO LAB @ CalTech
1 * Hiring manager logs in to myligo and fills out application on behalf of the new engineer; it is the hiring managers responsibility to know what groups this new engineer will need to be member of; this must include the effort/position data that happens later in the other use case
2 * this sends an email to the group manager
3 * the group manager approves/denies; group manager has an opportunity to adjust effort/position, and one attribute must be expiration date
4 * this sends email to end user; If denied, email contains email address of authorizer
5 * If approved engineer fills out her contact info, etc and can change change password from default
** there will be security requirements on what reset passwords need to be, and would like to make password change forced; should be a timeout on the generated password and say so to the user

Graduate student joins Cardiff
1 * grad student fills out registration form at myligo
2 * email is sent to group managers at GEO, including one or more from Cardiff
3 * internal communication happens inside of GEO (black box)
4 * a (one single) person as Glasgow approves/denies request and set position/effort info
5 * this sends email to end user; If denied, email contains email address of authorizer
6 * If approved engineer fills out her contact info, etc and can change change password from default

Staff scientist joins VIRGO (one big black box, don't know what institution from within VIRGO the person is joining from)
1 * scientist fills out web registration form at myligo
2 * email is sent to: melody, warren, LSC spokesperson, VIRGO spokesperson, Severine (the person who will actually push The Button)
3 * Severine gets the email with a link to a form, accept/decline, but then does NOT get the next page setting position/effort info
4 * they can then get to the myprofile info and fill out information that no one actually uses and which LIGO probably shouldn't be collecting

NSF joiners
1 * admin assistant enters info about person
2 * NSF group manager receives email and approves/denies; one attribute must be expiration date
4 * they get sent to a smaller form to collect minimal info

Looking at the IDM OSS Reference Architecutre (IdM ref architecture)

* checking this diagram against what LIGO might need - doe sit fit? Gaps?
** possibly POSIX username (but not a huge deal)
* provisioning/deprovisioning includes enough policy issues that we can't cover it in detail right now
* would be nice if at least the interface for deprovisioning went through COmanage; it would be nice to point group managers to one interface for them to deal with
*the diagram in question is overall accurate, and we can target Blue stuff in the time frame we're talking about, along with a bit of provisioning/deprovisioning

The tooling that COmanage can provide to the LSC spokesperson

* the LSC spokesperson will be most interested in authorized organizations, not necessarily the details of the individuals
* the LSC spokesperson/admin would need a tool that says we now have a new organization that is a member of the CO and that will automatically populate info within COmanage as if it were an organization/source of identity data - template for what enrollment template is used, and assign/delegate the authority to an individual within that authorized organization to do further work with the details/individuals within that group
** this person should be able to click on the COOrganizations button and have that do much more than it does right now; note that these organizations will be using the IdP of last resort (local identities) mostly at start
* about COGroups and COMailingLists - some concern that there is no plan regarding how interfederation will work in these contexts; the Grouper folks have been talking about this as well and are still trying to figure out details (how to do groups across multiple Grouper instances)
* for the COPeople list, will need something a bit more scalable to handle 100+ people within the CO; just a simple query interface
* should get periodic reporting on organization summary (number of individuals, number of delegates, possibly more)

The tooling that the Organization Management will need

* enrollment use cases + some glue
* manage members will need to be able to mess with the position/effort information ("ManageMyPopulation" button)
* this is where they care about individuals
* some more reporting function desired here
** note that percentages matter at an organizational level in terms of reporting significantly, but also for an individual, that triggers whether or not they can have their name on papers
** want this available via a RESTful interface

What is required in COmanage next?

* COadmin can add a new organization - not required in 6 months but highly desired
* All of enrollment information is required
* All profile information currently available is required (manage my profile requirement and data model requirement)
** especially position/effort info
* IdP-ish functionality (managing of KDC, publishing to LDAP)

Day 2 (start at 9am) Agenda
* get the enrollment process to a well-understood point - done!
* chart out the technical roadmap (here are the pieces, who is doing what)

Flow diagram for enrollment process; spreadsheet of different populations and how they are treated differentlyFlow+Diagrams+-+invitation

For Lab people, if they are also members of LSC, then there are categories of faculty, staff, etc. If they are NOT also members of LSC, there are no differentiators, they are just employees.

ROADMAP
* will need to have some amount of rearchitecting because we're hearing more and more that the VO (like LIGO) wants more help with IdM (enrollment, person registry) than with apps, at least for now
** in particular, will want to split out a piece of authentication, which we never intended to do in COmanage originally (was to be all federated) - COmanage IdP in a Box
** it is not what we said we would be doing, but having COmanage guide a VO in to doing the right thing, it sets them more effectively on the correct path to federation
* LIGO is essentially like an InCommon for a large bunch of organizations
1. plug in points for: interactive UI, programmatic UI, Registration, Authenticator Management, some Group management, Reconciliation, some basic role management, identifier and attribute management, and limited provisioning to the directory
2. customization of registration/enrollment is a LIGO responsbility, tho' COmanage will have to support it in some way
3. group management is mostly a LIGO responsibility, possibly including providing the stub that gets called to do the initial population (for the next 4-6 month target)
4. authenticator management could be either COmanage or LIGO
5. reconciliation, basic role management, identifier and attribute management are COmanage concern
6. limited provisioning is a LIGO concern

Potential milestones
* rest of December = (re)architecture for the COmanage IdP in a Box, and finishing up the documents coming out of this meeting, understanding the requirements they imply
** two follow up calls: Dec 10, Dec 17
* January = review documented work, decide technical path, assign specific technical tasks

Enrollment:

FUTURE follow up items
* list of applications depending on this infrastructure, what they use, what they provide - DEFER
** what about domain-specific apps being added to Applications in the platform
* list the pile of Organizations and their relationships and their identities and their "needs" ; what is the difference from LIGO's perspective of a group joining versus a organization joining and does there need to be a difference? - DEFER
** shell provisioning for new organization - what would that look like? what set up needs to happen?
* list of attributes, where they are sourced from, what they mean, who can edit them; what attributes get prompted for and when - joint effort (Benn, Scott, Melody)
* data model (what should be in the COmanage data model but isn't, and what is LIGO specific stuff) - (Benn, Scott)
* create the full list of default groups per role - (Scott, Melody; facilitated by Benn)
** roles, groups, permissions, hierarchy
** details in groups and group management specific to LIGO
* identifier inventory - (Benn)
* clean up enrollment flow diagram - (Benn)