Coordinates

8-10 December 2014
Seafirst Fifth Avenue Plaza
800 Fifth Avenue, Suite 4100
Seattle, WA

Agenda

Monday

1. SDCI Issue Triage (Stabilization Planning)
2. Upgrade shell for post v1.0 changes?

Tuesday

1. QA Planning
2. Requirements for search (MFA 85)
3. Should IdP Asserted Email Address Should Be Considered Verified?
4. Consuming ePTID along with ePPN and checking if ePTID changes to indicate ePPN has been remapped
5. Attribute Authority approach when platform has multiple COs and users may be in more than one CO
6. Long term rearchitecture: Event Sourcing?

Wednesday

1. UX Consistency Review
   1. When clicking save, flow is sometimes to an index view, sometimes to the same page, sometimes to some other page
   2. Tabs vs Canvas (vs. Accordion, which mostly seems to be gone)
2. Acknowledge multiple notifications
   1. Bulk operations UX
   2. Auto-acknowledged (i.e., email only)
3. Review CO-361
4. Application integration/Dashboarding

As time permits

1. SDCI VM
2. VO Outreach (if time allows)
3. January LIGO Meeting?
4. Managing MFA and LARPP (note: normalization now works; should discuss if it works as we want)
5. Revisiting LIGO COmanage Deployment Architecture
   1. Add first class support for management operations to Org Identities? (credential management, identifier assignment, etc.)
   2. Two types of org identities: synchronized (SAML, batch, institutional LDAP, etc.) and managed (self set up, admin set up, etc.); perhaps indicated by enrollment flow? (PasswordChangePlugin would only apply to the latter, synchronized attributes to the former)
   3. See also MFA 52, MFA 54

Specific tickets: MFA

• MFA 52 - Improve updating of IdP-based attributes
• MFA 54 - auto-verify IdP asserted email
• MFA 117 - enrollment issues
  really hard to solve; come back to it later
• MFA 85 - Search
• MFA 67 - Best Practices
  how to turn this into a technical document, not a policy document?

Notes

Monday

SDCI Issue Triage (Stabilization Planning)

• We have an average of 40 hours/week that we need to burn down
• Minimal feature addition, aim for bug fixing and QA (unit testing infrastructure)
• Note: use the I2 Jira for anything that involves a code commit; for client things, use the Atlassian instance (which is internal only to SCG)
• we will use a single stabilization label: ssp
• Started with 420 tickets still open across the board; tightened that up to xxx tickets that have been re-prioritized to match current stabilization goals

Things to clean up:

• LDAP discovery
• SAML authN support (was part of CO-46, 47, 48)

Documentation

• for 1.0 release, review all documentation and make sure there is a step-by-step set for installation for the inexperienced architect in this space (e.g., the physicist who in charge of IdM for their VO) — CO-970

Possibilities for Mike

• look at REST API (it’s “fraying” around the edge and could use some attention, possibly re-writing)

Upgrade shell for post v1.0 changes?

How are we moving forward on this stuff?

• Starting January 1, team will focus more on this; over the next three weeks, we’ll continue to shake out priorities
  Top-level priorities are:
• Scott/Arlen plans in January to get the unit testing infrastructure in place
• Benn will focus on simplifying installation
• more application domestication
• documentation

Tuesday

QA Planning

• http://book.cakephp.org/2.0/en/development/testing.html — "CakePHP comes with comprehensive testing support built-in.” Would give us a framework for the unit testing, based on their methodology and code
• Arlen to check whether we would be able to run Selenium web driver (http://docs.seleniumhq.org/) on top of the PHP test structure as well ---> https://phpunit.de/manual/current/en/selenium.html
• Scott to spend ~10 hours in January to get the CakePHP/PHPUnit testing working and we’ll make further plans based on what he discovers
• when we get this tool and methodology sorted out, we will revise documentation to state that any code you commit must have at least one unit test

How do we track QA tasks?

• we want to make sure we check on mobile during QA (for instance)
• we need a document that describes our QA tasks - Scott to write that up

Requirements for search (MFA 85, CO-209, CO-819, CO-820, CO-821)
Directory-related searches are now out of scope
“Find this Record” is the use case of choice and should drive the UI

• sidebar thing goes away; simple CO-209/819, advanced CO-820, and filter while you type CO-821 look and feel need to merge in terms of functionality
  List of things that should be searchable:
• Default=ALL
  • name - multilingual
  • identifier
  • email address
  • affiliation/Title
  • Group membership
  • Org identity attributes (find CO Person by org identity email/ePPN/etc)
  • extended attributes
  • status

Note: CO_people index and search should be the same thing; index is just what you see before you provide any search parameters

Should IdP Asserted Email Address Should Be Considered Verified?
“verified” has a very specific technical meaning, and under that meaning, we should NOT consider the email address verified. Note that not all individuals use the email address the IdP may assert. For ongoing behavior, if the IdP offers a new email address that has not been verified by the user, we will not change it in our records.

Consuming ePTID along with ePPN and checking if ePTID changes to indicate ePPN has been remapped

• many COmanage deployments rely on the ePPN as the key to identify user across services, then we query attribute authorities for attributes; however, ePPN can and will change, esp. in Europe. What we should be doing is consuming ePPN and ePTID at the registry, and watch for changes in ePPN.
• Can the registry even see this? Or is it purely an SP problem? The SP could store the SP’s version of ePTID in the registry with an identifier tag, effectively working around the point of not being able to correlate identifiers. Bad Idea.
• For LIGO, LARPP, and Cohortium, we’ve used the model of services (different SAML SPs with different entity IDs) and when the user goes to any one using SAML for SSO, then we get the ePPN to act as the single key. A different architecture would be to have one logical SP entity ID and different ACS (Access Consumer Service; a URL) bound to that SP so they would just act as different endpoints. Advantage: the IDP see the whole unit as one thing and so will send one ePPN and one ePTID, and we would then be able to use either. That might be an issue, however, in a multi-tenancy model such as with one instance of Sympa that is in use by multiple COs that aren’t supposed to know about each other. Alternatively, the SP can be specially privileged and say “here’s the identifier, give me back info” but if the user is in multiple COs, you still have a problem. It needs to know which CO_person you are, but the applications can’t do that. Maybe create a discovery service for SPs? “We find three different accounts - which one do you want to use?” Not sure if that’s even possible.
• If any authN can get you back to the Registry, the Registry may be able to be smart enough to know what application you’re trying to do. We can do hacks in front of the applications.
• possibly create an Apache module that would sit right after mod_auth_shib that looks in the Registry for whether you are multiple users. If one, keep going, if not, add that discovery point of “what user do you want to be"
• If you are using only one SP, then you wind up with how the application knows to signal back to registry that it is querying on behalf of a particular co_person? If you take the apache module approach, that becomes moot. Still may be a problem when integrating a cloud service without an apache infrastructure. Could go full SAML IDP-SP bridge? This could even work in a cloud scenario.

Attribute Authority approach when platform has multiple COs and users may be in more than one CO

• see above topic

Long term rearchitecture: Event Sourcing? (CO-95)

• If you maintain historical knowledge to state change (related to point-in-time audit), then event sourcing records both the change and updates a separate model table that acts as a journal. This makes it easy to do point-in-time audit.
• Right now, we do human-readable log, which clients seem to be like. But the above model could still be interesting. In theory, with event sourcing we could say “set current time to noon last sunday” then everything in registry would behave as if it were that date/time. Show us everything in the system during that state.
• If we do this model by model, can minimize impact of the change.
• Could this be combined with the human-readable history? Is there a demand for that?
• Grouper already does this, and could be a powerful feature for COmanage.
• Given the amount of time left for funding of this project, not likely we’ll get to this before Q2 2015 at best, which makes the overall likelihood low.

Wednesday

Arlen’s structure for the discussion
UI Audit - where are the problem spots / inconsistencies
Place in context of new menu approach
Where to place CO selector?
Known inconsistencies
Breadcrumbs (need finishing)
Where does save land?
Search functionality

What does UX cover?

• contextual help *should do a page-by-page review to figure out where to use that most effectively*
• new menu + CO selector
• Dashboard
• Edit in Place/Validate in place/Normalization
• Cleanup
• Touch-friendly for mobile is important, but it’s not critical

Priorities:

• menuing
• canvas / lightbox approach

See whiteboard

Application integration/Dashboarding

• Use case: when a CO admin comes in, after a CO has been bootstrapped, an admin will have some type of menu for applications that are available and can be provisioned to his or her CO. e.g., set up a new space in a wiki, create email lists that are attached to groups, sets up calendar(s). Then, for users who have gone through an enrollment flow, the notification will include a link (or when logging into the platform) will see the list of applications to which the user has access and some way to get to them (e.g., URI)
• this may be a simple as a bunch of provisioner plug ins ; plugins can add themselves to menus, but we would need to have a space to add them (not at the top level menu)
  • in use cases (wiki, lists, calendar, domain specific app) each have a “for this group” in common

So...
1. Add new *provisioner
2. Add n group authZ

My applications for TextCO

• wiki
  • first wiki
  • second wiki
  • third wiki
• calendar
  • my calendar
• Mailing list
  • list one archives
  • list two archives
  • list three archives
• UNIX Login
  • cluster A

see whiteboard