Dev 2013-07 Milwaukee

Logistics

Mon 08 July - Wed 10 July
Zelazo 177, UWM
Start @ 09:00

Agenda

Monday

1. Agenda bash -
2. KAGRA-LIGO Self Enrollment (Lite)
   1. Infrastructure Buildout
   2. ePTID versus ePPN and what we need in our architecture
   3. UI Stuff (in the context of KAGRA)
3. CO-222 (link navigation configuration) -
4. Dev time
   1. set up Registry and LDAP on the gw-astronomy.org site

Tuesday

1. Continue dev time for KAGRA instance - 10am-lunch
2. LIGO External Collaborator Email Based Enrollment - how close are we to "done"
3. Testing Framework - lunch
4. Review off-boarding and other open issues - lunch
5. Directory - next steps - lunch
6. Dashboard - lunch
7. CO People index view - filtering on long lists - lunch
8. Larger issues from Ken - 1:30pm
   1. Looking for consistency in the collaboration management space (e.g., identifiers, release policies, name spaces, how federated groups are done)
   2. What would it mean to integrate with an SDN?
9. Sprint Planning - 3pm
10. Documentation - proposed structure
11. Review Benn's inbox of old messages
12. MyLIGO 3.0 Planning
    1. Use Cases / User Stories
    2. Timeline
    3. Backlog

Notes

KAGRA-LIGO use case

• have a service called "ask.ligo.org"; the service is like StackOverflow (OSQA); to access you need to use the LIGO IdP (only federated with the LIGO IdP and you have to be in a certain LIGO group to be able to access)
• this now needs to be accessible to the KAGRA people as well; immediate answer will be to federate with the KAGRA IdP and add a discovery service, but then will have to loosen the access controls to remove the group restriction; want to use COmanage to reinstate that functionality
• at gw-astronomy.org, would like to be able to tell the KAGRA CO rep that they can log in to that site and manage people there; when they are added to the CO they will also get access to ask.ligo.org
• people in the CO needs to be expressible in some way that ask.ligo.org can consume it; perhaps run a Shib attribute authority on gw-astronomy.org and it can look in LDAP; initially doing a simple LDAP query and follow LDAP provisioning process; OR have them show up through grouper
• must work by Wednesday 10 July 2013
• Note that first option (COmanage registry + Shib as an attribute provider) can work now – Benn demonstrates

Strategic Direction for next few months and timeline

• Directory - bring in or not
• KAGRA - last major issue is the name rendering issue
  • second tier includes sponsor, expiration, LDAP provisioner options - need to review if that's an accurate list
• LIGO External Collaborator - need to talk timelines (which may feed the MyLIGO 3.0 conversation)

• Larger issues from Ken - 1:30pm
  • Looking for consistency in the collaboration management space (e.g., identifiers, release policies, name spaces, how federated groups are done)
    • Need to get Ken to understand the need for (at a minimum) an opaque but not targeted ID - we need a persistent, opaque non-targeted identifier to work across applications, which is actually an important requirement to VO; there can still be privacy preservation, but the CMP is a collection of applications so from our model, it is all the same target
      if we get an indentifier from the IdP, it needs to be consistent regardless in which part of the CMP it shows up in; from a federation, the different parts of a CMP look like different things that get different identifiers, and that's not actually useful to the CMP itself
      Maybe target to a specific service or group of services
    • Release policy: want everyone in the world to adopt R&S or something like it
    • federated groups: the only way it makes sense to believe information in name spaces is to predetermine who an org is willing to believe, whose assertions we will trust in the name space; the trust relationship has to be there anyway for federated authN to work; the CMP can be the attribute authority for group memberships for VOs - better to have groups of federated people

• • What would it mean to integrate with an SDN?
    • An SDN is just another application. Note that the SDN space is still developing its standards, and that space focuses on lower level than users, authentication, and authorization; as with all other apps, the vendors need to be able to externalize authentication and authorization, be able to accept external attributes and assertions

Current state of the use cases and associated release plans

• Make sure at this point forward each instance (i.e., KAGRA deployment, etc.) has its own point release, rather than building off of trunk
• Will follow http://semver.org/ for version numbering when we get to .9, but we will have an 0.8.2 for KAGRA
• revisions of the Roadmap and prioritizing specific tickets done; need to get this in to Jira