Page History

1) Shortcut to Planning Pages for the TechEx Demos

• Grouper Messaging Demo for TechEx 2017:  Overview;  Detailed planning doc (coordinators: EthanK, Chris Hyzer)
• Registry Messaging Demo for TechEx (coordinators: EthanK, KeithH)
• Provisioning (coordinator KeithH)
• Client/Service Registry (coordinator: JimF)
• Person data APIs (coordinators: GaborE, WarrenC, BennO)

See the Demo Planning pages for further details on specific TechEx demonstrations

2) Deliver APIs

1. (A, m) Definitive TIER API Guideline document; The excavation, sifting and winnowing are likely to be the labor intensive bits.
2. (B, s) Evaluate need for Grouper permission and policy management
3. (A, m) SoR/Registry/ODS/Groups (for TechEx needs; Ultimately it will end up being Large)
4. (A, s) 

5. APIs for Entity Registry, (or any other APIs by Category Name) that we are ready to deliver by Tech Exchange

6. Definitive TIER API Guideline document

7. List of TIER APIs to be delivered

8. Grouper permission and policy management

9. SoR to Registry/ODS

10. Registry to Grouper: Registry is authoritative source of subjects

11. Registry to manage Basis Groups and memberships in Grouper

12. Provisioning

13. (LDAP, JDBC, API later?)
14. (A, s) Provisioning (for demo purposes, based on UW-Madison Global Summit demo)
15. (A, s) Consent-informed Attribute Release (CAR)
    1. External API authored by Marlena
;  
16. 2. Presentation to TIER-API prior to their review of the API
:  
18. (B, m) 
19. Certificate API
?

20. 1. Idea that InCommon have an API for certificates.

    2. With Comodo API we/campuses are locked in.

    3. Is there an expert who can help? JimJ will help with the proxy that talks to Comodo.

    1. 1. An API for server certificate management for use by InCommon (check with ChrisHubing and JimJ)
       2. JimJ would help with a facade for Comodo APIs

    3) Define and implement an event-driven messaging approach

    1. (A, l) Asynch
    (asynch
    2. architecture, to complement the more synchronous API-based approach

       1. Messaging model where we only send identifiers of changed objects (probably modest effort)
          Demo: Grouper changelog publishes  events onto an AMQP message transport. What''s available now or soon (RabbitMQ, ActiveMQ); This can be demonstrated with 3.1.b

       2. [EthanK] A provisioning/de-provisioning message consumer (perhaps via midPoint) adds/removes people to an external system based on changes in group membership.

       3. [EthanK] Demo: “Human Resource” system puts HR events on a subscribable message queue; Message subscriber reflecting changes into Person Registry

    4) Publish Guidelines and Recommendations on Security Models for API Authentication and Authorization

    Co-develop
    1. (A, m) Develop guidelines and recommendation in cooperation with InCommon TAC OIDC WG and REFEDs WG
    Demonstration relying on a first version of the
    2. (A, m)  First version of Jim Fox's Client-Service Registry (as an advanced CAMP un-conference session)

    5) Design, implement an Entity Registry

    1. (A, s) Refine data model for minimal Registry (AI - Warren)

       1. More robust Group demonstration,

       2. SCIM - user… (AI - ? )

       Midpoint Install -  support for i and ii
       3. 1. Map minimal entity registry to midPoint schema (EthanK, WarrenC)
       4. (A, s) SCIM - user
       5. (A, m) Midpoint Install
          1. JimJ has packaged MidPoint and an integrated OpenLDAP into a container so we can implement Warren and Ben's work on the Thin Registry as a start
          2. Provisioning is a strength of Midpoint that we want to test out
          3. Perhaps use a Canvas connector for this.
          4. Implementation to support requirements for Provisioning in the WG
       6. (A, m?) COmanage  Install - support for
       c.i through c.iv.Simple
       7. 3; Minimal Registry implemented in COmanage
       8. (Post TechEx) add support for non-person entities

       6) Implement simple identity matching and related features

       1. (B, s) Single package used by both midPoint and COmanage; testbed instance was running last fall; Implemented the draft API; Miami demo: COmanage worked with an agent that actually invoked the ID Match API; 

       7) Define Person Registry and ODS connection

       1. (B, l) TIER HAS to do the API for identity data a la ODS. Longer run we’ll need an implementation package for those APIs.

          1. when APIs are largely defined, consider polling/surveying community for viability with existing systems as input to determining whether or not TIER needs to go build something.

       2. (B, s) Demonstrate Person data APIs (using the registry, ODS, group repository to populate the user SCIM schema.

       4. Grouper:

       1.  WarrenC has a master data project that we could use as a model ODS for demo; 

       8) Advance Grouper training and adoption

       1. (A, m) Building a training course for Grouper, leveraging both the Grouper Deployment Guide and Bill Thompson and Chris Hyzerpre-conference Grouper training session at Apereo.

       2. More advanced demos at Tech Ex

       ...

       1. , 

       2. (B, m) Demonstrations of more advanced features at Tech Ex (adv camp unconference session proposal)

       9) Implement Provisioning tools

       1.  demos

          1. (A, s)  Provisioning from midPoint to Slack and/or LucidChart via their SCIM APIs

          2. (A, m) Canvas API connector(s) for midPoint and/or COmanage

       ...

       1. 1. ; See 2.

       ...

       1. 1. 5

       2. (B) See above 5.3 and 5.4

       10) Take next steps in Documenting TIER Components

       1. (B, m?) BennO

       ...

       6. Response to Packaging Good/Needs Work discussion (get that ready to send to community and take remediation action)  - starting now in Packaging

       7. Documentation Next Steps based on Feedback. - starting now in packaging (for component and operations environment)

       Ben

       1. - Consideration for COmanage Deployment Guide

       or more like screen shares and web cases.  Not

       2. 1. Not sure that the GDG approach is possible

       3. Paul - looking at using COmanage in TIER/InCommon Shibboleth Training as an SP integration example

       4. 1. More likely to take form of screen shares and web cases

       5. (B, m) Would like to offer trainees either Grouper or COmanage as general tools for SP integration examples

       6. Marlena: Before GS (back in January), I proposed the idea of a "Quick Start Install Guide" for IdP V3. It depends on a TIER installer.  This was "on the plate" pre-GS, but may not be anymore.   I'll check with Steve Z.

       Paul - New InCommon updated training is just starting to gel.  Will have an installer but not sure exactly what form that will take

       7. 1. Enrich SAML-delivered attributes with COmanage identity information to make sure SP gets everything it needs(?)

          2. Related to provisioning, see 5.3, 5.4, JITime and JICase provisioning; IdP Proxy

       8. (B, m) Drill down on the integration pipe in Tom's reference architecture diagram. Add detail, substructures; will provide a basis for the overall demo narrative flow we want to include. Keith will draft a "TIER Integration Architecture" document for WG review.