Logistics

Mon 04 March (Dev f2f)
Tue-Wed 05-06 March (LIGO Planning)
2nd Floor Downs

Agenda

Dev f2f

1. Review technical implementation towards KAGRA-LIGO Self Enrollment (Lite) use case
   1. Do we need LIGO IdMS for this use case? (Scott: No, we can assume for this use case that all people come to the platform with an existing Org Identity that is asserted by a SAML IdP.)
2. Discuss long-term big picture planning to transition LIGO to COmanage based infrastructure
   1. What does the ligo.org IdMS look like and what are implications for ID match?
   2. Is it built on COmanage, Berkeley ID match project, or LIGO once-off?
   3. LIGO COmanage Deployment Architecture, meeting notes.jpg
3. Entering extended attributes
4. UI (and anything else) scaling (CO-312)
   1. Database query performance
5. LDAP Provisioning Plugin Operations
6. Menubar highlight color (CO-555)
7. Unit testing (CO-97)
8. Search (CO-209, CO-497, and CO-139)
9. Provisioning when a new CO/COU is created
10. 0.8 release planning

LIGO Planning

1. Evolutionary approach to implementation
   1. Introduction (review for some) of "small bang" (incremental) COmanage deployment use cases (now in priority order)
      1. KAGRA-LIGO Self Enrollment (Lite) 
      2. LIGO External Collaborator Email Based Enrollment 

1. 1. 1. LIGO External Reviewer Self Enrollment
   2. Develop user stories
2. Review of MyLIGO plans/designs with COs/COUs/People/attributes loaded and lang file "localized" ## Review of LIGO COmanage Deployment Architecture
3. Demonstration of initial LDAP provisioning code.
4. Sprint Planning

   ---

   Notes

LIGO Planning (5 March 2013)

Attendees:

• Scott Koranda
• Warren Anderson
• Benn Oshrin
• Stuart Anderson
• Melody Arroya
• Marie Hunyh

-----

Evolutionary approach

Stuart: it is a low risk thing to go after, in part because it is a low priority for LIGO
Scott: the target is not to get them more infrastructure, the real target is to make it easier for Melody and Scott to manage the infrastructure
Warren: see it as a key step on the road to deal with VIRGO; we don't want to have to wait until we're federated with the Italians; better to work first with someone willing to cooperate
Benn: also low risk because if things do not go as planned, not as visible or catastrophic
Stuart: could we give them something even more simple -> grouper access?

This will be a separate COmanage deployment; a separate COmanage registry (what does that need to look like? it will need a brand name, a URL, potentially a neutral territory), a separate LDAP and grouper and Shib IdP
* who would manage this? propose that LIGO would do the deployment and manage at the service level, but we would delegate to KAGRA to do the enrollments
* long-term view, when we have more than LIGO playing, we need to have the community-wide discussion between LIGO, VIRGO, KAGRA, etc; gravitational wave physics community level discussions; LIGO shouldn't own the infrastructure, but we need to help get them there
* not making a distinction between types of KAGRA members
* could use notifications, but it is not required at this time (will need to come back to this)
* is email and ePPN enough from a security standpoint right now? what about phone number or home institution or sponsor? for KAGRA, being a small group, sponsor should be fine; MoU are being written to require sponsors to respond to security incidents

Need to come back to COmanage-created identifiers (i.e., employee ID number)

This does not hold science data, so may not need a non-LIGO branding; but if we need a generic place for GW astronomers to collaborate, if this grows up some day to another funding stream, we need to consider the name.  Alternatively, LIGO is doing all the work and deserves some credit.
HF Recommendation: go with whatever leaves you with the most flexibility (a non-LIGO name) and LIGO can be recognized in other ways

LIGO has a domesticated online election tool - come back to this later over beer

Concern about how we display/order name
* Warren just wants to know what name comes first, what name comes last; given name and SN have very clear meanings; there are a few languages doesn't fit in to given name and surname components; these are defined in the schema; in practice, most people who come from cultures who don't fit this categorization are used to making it work; read the doc from the W3C on names which suggest just one field, "name", but that loses you some functionality like alphabetizing by last name
COmanage will currently capture given and sur, and automatically render CN; we can also have a free form field and that's what we put in a directory or published name - wiki.org would not display it
HOw many different display names could someone have? As many as configured

A point to consider: we are currently consuming "institution" from KAGRA LDIF; right now, the data model would only feed that to the Org data, not the CO data; how to adjust?  Will also be looking at this in the External Reviewer use case

Need to figure out deprovisioning, and let's use the use case of External Reviewer to drive what we need to do
* Want the enrollment optimized for returning reviewer; if you are just refreshing an expired account, does the reviewer even need to go through an enrollment again?

This cannot be a COU living under a CO - the name of reviewers must be kept private; it can be a separate CO on the same platform

----

Another potential use case includes the summer undergrad students

* they may need CLI
* they will need a LIGO identity if they need CLI
* they are shoehorned in and so removing them is difficult
* maybe they need to be part of the LIGO IDMS
* does this need to be prioritized over the KAGRA work?  this is mostly interesting as a later effort, should gather requirements later
** bring this up at part of our prioritization effort in April

Note that every MoU  has a different expiration date, and while we may continue t work with individuals, this is something to remember

----
Why not all one COmanage instance?
* because we will be enabling different behaviors between the platforms, particularly around privacy and policy implications
i.e., you want the NSF reviewers walled off, and while you have CO people and Org identities; for one box you may have the Org Identity shared across CO, but for another box you may not want to have that shared
* some you may want separate for political reasons alone

Some significant discussion regarding transfer between COU and what attributes need to be attached to the person and what needs to be attached to the role
* seniority for authorship determintaion

----
LIGO has been trying to be both a consumer and a source of identity; would like to consider these two discrete functions, and that introduces the LIGO IdMS; users will never see this directly
What the LIGO IdMS will support is an identity match service
You send in to a RESTful API what you know about a person (name? email? could be several other inputs) and this thing answers with a level of certainty as to whether it knows about that person as an existing org identity. Also, when you send it it, you can say "if you know you do not match this person, then create it and return the known identity including a kerberos hook that creates the kerb principle
this will help LIGO avoid name collision across CO instances for assigning first.last@ligo.org
proposing that the LIGO IdMS installation is a specialized COmanage instance, a RESTful service that no one ever browses to, no users
federated users who never use the CLI will never need to know their kerb identity

----
Make sure bug is submitted re: back button does not always go to the correct, consistent location after editing a person record

Need a better view when there are no COUs

Dev meeting, 6-March-2013

Attendees:

• Scott Koranda
• Marie Hunyh
• Benn Oshrin
• Heather Flanagan

Calendaring

Sprint planning and 0.8

sprint13 to run to April 20 (I2MM)
Comparing KAGRA use case against the current list of 44 tickets
CO-117 - not actually needed for this use case (except for the fact it holds the names presenting backward - moving that issue to a separate ticket - CO-577)
CO-115 - added to sprint
CO-548 - added to sprint
CO-549 - added to sprint
CO-550 - added to sprint
CO-551 - NOT in sprint, but leave in 0.8
CO-564 - added to sprint
CO-57 - added to sprint
CO-311 - is added to the use case
CO-283 - added to sprint
CO-309 - added to sprint
CO-81 - added to sprint
CO-56 - added to sprint

Note that Abe would find having an institutional name (not just VO name) helpful in order to check off IP addresses; could ask Sato to assert something (just O)

---

Scaling

Projected use is how much?
University of Florida and University of Texas have both indicated they would like to use this to support their campus needs, so while LIGO needs approx 1200, we could see the need for much more (tens of thousands of people)
If we go to the iPlant scenario, they talked about loading entire extract of students, and that use case could come up again
First order of magnitude will be ~1000, and when we have that working, aim for ~10K
Where plausible, jump to the larger number
In order to tackle the problem, need to have a test system with 10K users
** see www.fakenamegenerator.com to get bogus id's - will just need a tool to upload a spreadsheet to ingest the info correctly

----

Provisioning when a new CO/COU is created

* simplifying CO creation is a similar concept/ticket
Note that the caltech COU is 87; MIT COU would also be larger than most; majority of standard MOU will be less than 50 people
imagine a scenario to click on "add a CO" the first name of the person in the CO, click "create" and then it fires off some provisioning plug ins, which might provision a new tree in LDAP or a new folder in grouper
* is this all so well defined that we can just bake it in, or is it flexible enough that we should leave it as a plugin?
* what will you create with a new CO? a new LDAP tree, some groups…  probably should be a plugin (Scott has to clean up after the "fix" of CO-389 which adds several components not needed)
* maybe the task here is for Warren to write up the steps for when Gabby creates a new CO