Working with Vendors for K12 Federation

Email from Bernie A'cs for All Pilots call of March 12, 2015

There are multiple points-of-view needing some illumination to establish a baseline of objectives, goals, and experiences that will help frame responses to the questions. (Click to see questions submitted by Shaun Abshere below on this page) .  Here is a primer for discussion.


Introduction

IlliniCloud is the "owner"/"operator" of what we call the Federated Service Stack (FSS). The business objective for this is to establish an operational reference model and implementation catering to the special needs of the K12 community to adopt, participate, and leverage the strengths and advantages federated identity, centralized data automation services, and the means access applications that are easy to access by the user community supported by a Local Education Authority (LEA or school district).  

Background Context
The three pillars: data, identity, and presentation are intimately inter-woven in the day to day activities of students orchestrated by LEA administration, faculty, and employees in very general terms using a given Student Information System (SIS).  The activities from the perspective FSS fall neatly into just hand full of baskets: 
With context presented in the course-grained outline and bullets above, as IlliniCloud's significant investment in design, development, discovery, and deployment has produced an operational representation of the three pillars of support with predominately open-source software resource. 

Identity Service
The strategy for the FSS focused on implementing a Shibboleth IDP equipped with a custom JAAS implementation that functionally determines the demographics defined for an authoritative source system to be consulted based upon user-input at the challenge prompt.  This module returns these connection parameters to the IDP and interrogates additional authoritative source system values for assertion assembly, packaging, and delivery to SP. The interrogation processor collects and writes the resultant values to a database service (MySQL) that is use store minimum schema needed to satisfy the core general purpose attributes defined. The database service is exposed to the IDP service as resource that is consulted during the attribute-resolution phase of the assertion preparation logic including complex LEA specific attribute-resolution rules. The attribute-filter phase of IDP processing is used primarily to implement rules that constraint attributes for delivery and provide the mechanical means to arbitrate LEA/SP attribute agreements.  One design goal for this functional model to realized is that the "operator" of the FSS maybe a single LEA or a regional service facilitator like the IlliniCloud where many LEA organization tenants use a centrally managed deployment, the model accommodates both of these scenarios, for example for a single-site deployment with the Shibboleth IDP would be sufficient, in the regional case and more complex scenarios the IDP/Proxy hybrid deployment described here could be implemented.

The Illcloud IDP/Proxy hybrid introduces LEA tenants using a common services deployment which seemed to poorly addressed in products that were evaluated. Given this fact, the design requirement dictates the need to develop interfacing that empower operators of the FSS model to establish two one-sided operational-partnerships: 1) LEA Operational Partners; and 2) SP Operational Partners; these partnerships represent a digital contract that defines how delegated administration and responsibilities are facilitated and how the IDP/Proxy operations are managed.  A more complete executive-level summary of the operational-partnerships is available at: http://confluence.illinicloud.org:8090/display/TP/IDPOperationalPartners and this short article also explains that the AAF Federation Registry software has been adopted to provide "self-service" administrative interface to negotiate the workflows that are punctuated by sequences of human actions necessary to manage configuration of the central service.  One of the primary design goals for the AAF software adoption was to address IDP/Proxy needs to define connection properties necessary to facilitate delegated authentication and interrogation of authoritative source systems operated by the LEA tenants served.  Another goal was to facilitate establishing similar connectivity with SP entities enabling them to define their declared assertion attribute requirements, this was done in a fashion that strongly supports the core general-purpose-attributes and further provides the SP to define "application-specific" attributes. Iin the subsection Identity a table defining the "general-purpose-attributes" is presented in the document at: http://confluence.illinicloud.org:8090/display/TP/ThreePillars   

Data Service
The most important component of adding value for LEA organizations revolves around the relationship of of the data service with the identity service. In most LEA cases the SP applications come with a prerequisite to supply some data-extracts that, in general, can be cast as "Roster" information.  The spectrum of requirements ranges from heavy-weight extract, transform, and load (ETL) operations including list of Teachers, Students, and Section/Courses that are used to per-populate application-specific databases managed by the vendor to operator one or more applications. At the other end of the spectrum are vendors that are ready and able to dynamically provision application user-accounts based upon attribute assertions provided by the IDP. The mechanical requirement to prepare and deliver "Roster" data-feeds on a regularly scheduled basis, is a significant liability for LEA staff to enable the educators and students to use applications.   Another flavor of ETL operations that every LEA are liable for on a regular basis is meeting reporting requirement for State and Federal entities.  The data service pillar essentially provides a common-data-model schema that can be sourced to develop and implement logic once that can be used by many LEA organizations. For example, one of the districts engaged has been piloting a focused development effort to automate a series of State level reporting requirements, the logic implementation is constructed to enable re-use by other LEA entities.  The estimated labor reduction benefit to the pilot district is approximately 5 hours per week for the staff member that was responsible for manually producing these data-feeds.  
The predominate achievement has been that 32 LEA organization have adopted the use of this service pillar and in so doing are provided the immediate benefit of automated record validation enabling data-correction in their SIS source system. The IlliniCloud central data service implements a School Interchange Framework (SIF 2.6) Zone Integration Service (ZIS) and the primary reason for this is that many of the SIS vendors widely used by the LEA organizations support SIF agents, these can be used to migrate record-level details to the ZIS in real-time, transparent to the end-user that use the SIS. For cases where the SIS is not SIF ready/enabled alternative ETL tools are provided for LEA to define, implement, and manage data-migration on a scheduled basis to the Operational Data Store (ODS).  An advantage of this ODS model is the ability to develop-once and to use those development for many organizations.  In addition, the ODS has been enhanced to enable bidirectional automated data-model level migration between the SIF 2.6 ZIS service and an implementation of a SIF 3.0 ODS and/or a EdFI ODS.  These function capacities open the doors of opportunity for the LEA entities to consider using applications that were developed to operate over one of these emerging and/or established standard data-models. 

Presentation Service
The presentation service implementation has produced a number of contributions to the Apero foundation's uPortal platform, including an operational model that reflects upon the notion of the service "operator" and the relationship with LEA tenants. This strategy has empowered IlliniCloud to set a baseline of minimum requirements needed to present content tailored to targeted sub-population of LEA organizations based upon the eduPersonAffiliation and eduPersonOrgDN attributes. These values enable portal administrators to define content that will be conditionally provided for Faculty, Staff, Employees, Students and/or the building (school) where they are assigned.  The operator manages and controls the "Public Apps" content which is optionally presented to all LEA tenants. This feature is intended to seed and nurture the development and implementation of an application market place that can be used by register SP partners to provide "public" user experience (demos) or to increase awareness of their product(s) and service(s) for educators and learners.
How Far Have We Gotten 
The Registry focused initially as an aide to work with LEA operational-partners, the overall functional service is really about how these entities manage IDP/Proxy connectivity, provide core attributes, and subsequently enable register SP applications. The first application goal is enable the LEA to leverage the App-Launcher portal offered by the "operator".  
The high-level workflow-segments for a new LEA operational partner are:
The high-level workflow-segments for a new SP operational partner are:
Active Partnerships achieved and in-progress:
  • 18 LEA organizations registered (most are in progress)
  •  7 SP integration completed with one or more LEA using service
    • Pearson
    • PowerMyLearning
    • BrainPop
    • Moodle
    • MasteryConnect
    • Isle Dashboard (NIU educator dashboard)
    • Isle OER (Search with CWD)
  •  5 SP integration actively in progress
    • DiscoveryEd
    • ReadingPlus
    • iSafe
    • EdAutomate
    • Symphony Learning

What Have We Learned
The most significant challenge faced with the design, development, and implementation of the FSS for IlliniCloud has been to achieve a reference implementation model that is vendor/product agnostic while utilizing vendor partners to help satisfy professional services demands to develop functionalists that mechanically satisfy the operational requirements without inherently creating dependencies on a particular vendor propriety products or tools.  This single objective has been difficult to manage and keep on track, primarily due to the fact that vendor partners come to the project with a vested interest in promoting wares and hedging their position with proprietary resources. In a matter of speaking, the potential conflict of interest is both a philosophical and physical hurdle that can only be mitigated by conscience and deliberate attention on modular component implementation where alternatives approaches would be supported.   
Brief Question Lead-ins:
1. a.  (I will use the word SP versus vendor).  The strategy adopted to engage with potential SP-operational partnerships is to be lead by the LEA community  (as an existing customer of a given product) to vendors to explore and/or implement integration where possible.
1.b.  The IlliniCloud objective has been to develop the capacity to be vendor/product agnostic and with the description provided above in mind: in regards to the "operator" we have purposefully focused on instrumentation using open-source resources do nearly all the heavy lifting to manifest the IDP/Proxy.
2.  As an operator there is certainly an opportunity to engage with SP-partners where specifically the FSS mitigates LEA on-boarding with SSO and roster automation to negotiate terms:
 
3.  There is no circumstance where a vendor should be acting in the capacity of an agent for the operator, however as in many industries where IT consultants are engaged to enhance staffing and in-house expertise, there may be circumstances that would leverage external resource augmentations to perform well-defined and specific tasks at a customer's site on behalf the operator.  The hardest earned assets an operator can hold is the "trust" of their community being serviced, it is so valuable and important that it is never worth risking by placing it in the hands with an interest that are NOT precisely focused on the tasks and goals set by the operator.

 



Questions from Shaun Abshere

From: qt-incommon-pilot-bounces@thequilt.net [qt-incommon-pilot-bounces@thequilt.net] on behalf of Shaun Abshere [sabshere@wiscnet.net]
Sent: Wednesday, March 11, 2015 1:33 PM
To: Quilt All Pilots List
Subject: Re: [Qt-incommon-pilot] Next All Pilots call: Thurs., March 12, 2015

Questions and Requests:

 

1)   Compare and contrast lessons-learned from working with:

(a) vendors who are/want to be service providers
     to your federation/consortium members versus
(b) vendors who provide identity and access management
     infrastructure services to your federation’s operator?

2)   For vendor types 1a and 1b (above), what are the important deliverables
that the federation operator will buy?  Which types of deliverables
ought to have a “positive-approval” requirement before payment
What’s your process (e.g., test-in-lab; deploy-and-test) for deciding
to approve payment?

3)   Under what circumstances should a vendor of type 1a or 1b (above)
work directly with a K12 member of your consortium?
What does the federation operator need to know/evaluate, and from whom,
following such an example interaction?