OSIdM4HE-prov concall, 8/19/2011, 16:00 - 17:00 ET

• Attending: Rob Carter, Keith Hazelton, Lucas Rockwell
• Minutes of the 8/12 call: Attendees will review and forward Rob any amendments – meantime, minutes are posted in the Provisioning Team workspace on spaces.at.internet2.edu
• Agenda Bash: Nothing of significance.
• Action Items from 8/12 call:
  • Keith noted that we have roughly four weeks (as of 8/19) before our report back to the committee of the whole is due.
  • Rob: Generate Graffle architectural diagram. Done – putative diagram is posted to our wiki space, and we have an agenda item to review/discuss it later.
  • All: Review SCIM documentation, particularly scenarios. Agreed to review during agenda later in the call.
  • Keith: Send out SCIM documentation links. Done – links added to wiki space.
  • Rob: Send out additional discussion items before next conceal. Missed.
• New Business
  • SCIM Documentation Review
    • Rob asked if folks had had a chance to review the SCIM documentation, and in particular, the SCIM scenarios documentation linked off the OSIdM4He-prov workspace in the wiki, and added that he'd not yet had a chance to review the scenarios thoroughly. Keith and Lucas agreed that they could use more time to review the documents, too, although they both have some pre-existing familiarity with the SCIM effort.
    • Keith suggested that while all the documentation may be interesting, the key documentf or us to review is probably the scenarios document, when an eye toward whether we think there are use cases in our scope that aren't addressed in some fashion in the SCIM scenarios.
    • Keith explained that the scenarios are written around two actors – a CSP or Cloud Service Provider, and an ECS or Enterprise Cloud Subscriber. Normally, HE sites would be ECS's, but in enterprise scenarios, we might consider actors within an institution as both ECS and CSP. The scenarios aren't written to our use cases, but there may be strong enough analogies between our use cases and the SCIM scenarios that they can be mapped onto one another.
    • After some general review of the documentation, Lucas noted that the SCIM scenarios seem fairly complete, but may lack one potential scenario – CSP to ECS "push", in which the Cloud Service Provider might need or want to push identity information "backstream" to the Subscriber. He noted that this is a use case he'd hope to never actually encounter in the actual cloud scenario, since it seems to have some serious complications around data integrity, etc., but that it might be a use case that could come up in the mapping of CSP and ECS both onto enterprise-internal services (albeit with a similar set of complications).
    • Keith asked if there might be an AI associated with trying to spec out a SCIM CSP -> ECS (push) scenario.
    • Lucas suggested that the CSP->CSP scenarios may be of limited interest in the Higher Ed environment as compared to the ECS->CSP and possible CSP->ECS scenarios.
    • Keith agreed, but noted that there might actually be some analogies to CSP->CSP scenarios in research organizations and VOS.
    • Lucas agreed to take an AI to post his thoughts on additional scenarios not covered in the original SCIM scenarios document to our mailing list and/or to the wiki.
  • Architectural diagram
    • Rob then asked if folks had had a chance to review the diagram he'd posted shortly before the call. Given the short timeframe, no one had, so the group spent a few minutes reviewing the diagram and description.
    • Rob then explained the diagram in some detail. Keith indicated he found the model separating data collection, data delivery, and a middle "engine" layer applying business logic and access controls interesting. Rob noted that his mental model depicted in the diagram is probably heavily conditioned by his history using first Novell's dirXML product and now Oracle's OIM product, each of which implements a model that resembles the one depicted in the diagram.
    • Keith asked if we already have an "ideal" model in mind for how data should flow between the registry project's product and ours, or whether that's in some sense what we're working toward.
    • Lucas noted that the diagram seems to point up a crucial dichotomy in potential models – between a provisioning facility that incorporates an "engine" implementing business logic and one that operates in a largely "pass through" mode, applying none of its own logic, instead effecting operations as directed by an "upstream" registry for delivering data to "downstream" consumers.
    • Rob suggested that simple data walk-through might be helpful. As an example, he described a possible walk-through for a name change recorded by a "person" registry. The registry might invoke an "update" trigger in the collection layer, passing in a unique identifier for the person whose name changed and providing the old and new values for the person's surname. The provisioning engine might in turn determine based on its business logic that the name update affects three consumers – two attached to the SCIM connector and one connected directory. In the directory case, the change may be affected by a business rule that requires a check for an override attribute, so the provisioning engine might invoke a part of the collection interface to use an API adapter to retrieve override data from the registry and marshall it to modulate the arguments sent to the "Custom 2" connector for updating the appropriate directory. At each step, the routines involved write audit logs through the audit logging layer in the diagram. In the event that one of the target systems fails to accept the update, the persistence mechanism is invoked to persist the transaction for later retry by the scheduling mechanism.
    • Keith noted that the data walk-through comes close to being a functional architecture description, which he noted is something worth putting together in addition to a technical architecture. Rob offered to put together a couple such walk-throughs and add them to the wiki.
    • Lucas noted that he has a few ideas about a somewhat less complex architecturethat he'd like to share, and offered to put his ideas into diagrammatic form and add it to the wiki.
  • Action Items
    • Rob will add one or two walk-thru descriptions to his diagram for discussion.
    • Lucas will pass along descriptions of additional SCI scenarios
    • Lucas will post simplified diagram(s) to the wiki for alternative ways of considering the architecture
      //
      Next meeting scheduled for 4pm ET 8/26