MEETING NOTES: (Call Recorded)

Policy Reminder

  http://www.internet2.edu/membership/ip.html

  1.  Roll call, agenda bash
  2. Working with Vendors around K12 Federation



    1. Steve Thorpe of MCNC


      1. IdPs:
        1. Hosted / Managed by Us (MCNC)
        2. Davie County Schools
        3. (Davidson Community College)
        4. Rockingham County Schools - very proactive
      2. DIY
        1. Durham Public Schools - can do a lot on their own (pretty big)
          1. Hosted at AWS / Built and Managed by Identity Automation
        2. Entire K-12 in NC (115 LEAs, 100+ Charter Schools, 2500+ schools, 1.5M users)
      3. SPs:
        1. Instructure / Canvas LMS
        2. Digital Designs / Online Pay Stubs app
        3. NC State / VCL
        4. NCLive / Licensed library content
        5. MCNC / Portal (drupal based?)
        6. MCNC / Confluence
        7. Davidson & Davie / OrgSync (campus groups)
        8. Davidson & Davie / UpSwing (tutoring)
        9. Davidson & Davie / Moodle
      4. Plus for NCEdCloud:
        1. Follet Destiny - K12 library app
        2. Discovery Education - K12 content app
        3. Google Apps for Education
        4. Zscaler - content filtering
        5. Pearson OpenClass - learning platform
        6. SchoolNet – assessment
        7. Pearson PowerSchool - Student Information System
        8. TNL / NCEES - Professional development
        9. Office 365
        10. Edmodo
        11. etc.
      5. Questions: (most from Shaun Abshere | Deputy CEO | wiscnet.net)
        1. Let's assume that the primary question is:  What are the most important practices for working effectively with vendors around K12 Federation?
        2. Compare and contrast lessons-learned from working with:
          1. SPs vendors who are/want to be service providers to your federation/consortium members
            1. With SPs, want to clarify UP FRONT will there be any additional charge for the integration, and if so how much and who pays?  Do NOT want bait and switch!
            2. With SPs, often times it is difficult to get them to do the right thing of publishing their Metadata into a federation such as InCommon.  Many SPs are resistant, perhaps because then can be clueless about the benefits to themselves and others.  (e.g. think Moodle).  Sadly, many SPs only want to support direct point-to-point.  Vendors need to be educated on benefits of true federation!!!
            3. Ideally can have very clear instructions / guidelines / expectations published so prospective SP vendors understand how they can play nice (e.g. with respect to protocol supported, attributes, privacy, etc)  We have a limited start on NCEdCloud IAM info site but may work on improving it. https://ncedcloud.mcnc.org/sites/default/files/Integration%20Methodologies%20for%20the%20NCEdCloud.pdf
          2. Versus IdPs vendors who provide identity and access management infrastructure services to your federation’s operator?
            1. Want a very clear agreement to the requirements, deliverables for IdP provider
            2. If of interest, I could share the RFP used for NC’s statewide K12 IAM service (not comfortable if it is posted on a world-readable web site but happy to share to specific individuals if of interest)
          3. For vendor types 1a (SPs) and 1b (IdPs)  (above), what are the important deliverables that the federation operator will buy?
            1. First Its not clear to me the federation operator necessarily would be the one buying the SP services.  To my mind it could easily be the federation members (e.g. representing users behind the IdP(s) in the federation) (perhaps indirectly)
            2. SLA (uptime, service response time)
            3. As one of the requirements include 24x7 end-to-end monitoring of successful uptime (possibly with financial repercussions for downtime?)
            4. Data protection / compliance with all the “ERPas”
            5. etc.  Develop a clearly defined RFP to specifies what you want to buy.
            6. As part of the RFP evaluation process, require a rigorous proof-of-concept before accepting vendor (NOT a demo specified by the vendor(s) -- rather, a demo specced out by the buyer)
          4. Which types of deliverables ought to have a “positive-approval” requirement before payment
            1. After the service is built, need to have it thoroughly tested to meet RFP requirements before continuing to the next phase (production) and receiving payment for the first part (setup)
            2. As the service continues in production, uptime (as confirmed by 24x7 end to end monitoring) can be a factor in whether full payment is received for next phases.
            3. Examples for Statewide IdP:  (see RFP) could include standing up service, integrating with specified number of target applications)
          5. What’s your process (e.g., test-in-lab; deploy-and-test) for deciding to approve payment?
            1. Work with vendor throughout the year
            2. Prior to payment vendor submits report detailing deliverables for prior year
            3. Payment is approved assuming vendor has indeed met the deliverables which we would know from working with them and we have it in writing in the contract.
          6. Under what circumstances should a vendor of type 1a or 1b (above) work directly with a K12 member of your consortium?
            1. If an IdP talks directly to the K12 directory, IdP vendor would need to synch up with K12 member on connectivity coordinates for accessing directory.  As part of that consulting on best practices to ensure high availability of said directory.
            2. If an SP has an arrangement directly with the K12 member, either the IdP and/or the SP’s SMEs may need to have integration meeting(s) and follow-on interactions to coordinate on the technical connectivity.
          7. What does the federation operator need to know/evaluate, and from whom, following such an example interaction?
            1. My thought is operator may initially wish to lurk on a few of the meetings to best understand the process. That way the operator can most effectively educate future participants on what to expect.
            2. After that, perhaps just ask the K12 / Vendor to acknowledge connectivity has been made?
    2. Bernie A'cs of NCSA/ University of Illinois

      1. There are multiple points-of-view needing some illumination to establish a baseline of objectives, goals, and experiences that will help to a degree frame responses to your finely crafted and articulated questions.  The below is a bit primer for the discussion this afternoon which will be somewhat short (30 minutes with two perspectives to accommodate) so I is my hope that the narrative and details provided in sections below are consumable and that the rough questions lead-in will help to set the stage for a productive session that achieves the sharing goal of our collective collaboration.
      2. Introduction
        1. 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).
      3. Background Context
        1. 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:
          1. enterprise-application (in-house resource, LEA operated); examples are
            1. Supportive services for Educators and Students.
              1. Support Staff services
              2. Parent services
            2. wireless tablets, phones, laptops, and other technologies
            3. Office/Desktop common-tools
            4. …
          2. operational-applications (business needs of LEA);
            1. SIS data ETL operations for State and Federal Reporting requirements
            2. Time-card systems, RFI monitors, and other accounting tools
            3. HR management tools
            4. Food Service tools
            5. Transportation Service tools
            6. Shared collaboration resources (disk space, folders, files, or other)
            7. Integration of (de- &) provisioning Students and Staff enterprise-wide including critical SP applications
            8. ...
          3. external service provider applications (could be sub-population specific Teacher/Student/Section-Course);
            1. SIS data ETL to provide "roster-feeds" for some SP applications to function
            2. Shared collaboration resources (disk space, folders, files, or other)
            3. Integration of (de- &) provisioning Students and Staff with SP applications
            4. ...
          4. federated services and applications provided directly by the "operator" for federation members.
            1. Data Service Objective:  provide a means by which LEA partners are empowered to leverage a common data-model structure that can be used validate data-values, facilitate automated operations to support ETL needs, and support migration of values between predominate data-models.
            2. Identity Service Objective: provide a means by which LEA partners are empowered to leverage federated identity and Single Sign On (SSO) features for web-based applications (most SPs) and to the degree possible enterprise-applications required to conduct the day-to-day business including Students.
            3. Presentation Service: provide a means by which LEA partners are empowered to leverage applications on any-device from any-where using a very simple portal interface that enables segregation of content presented to users by
              1. Org (Org) and/or
              2. School (OrgUnit) and/or
              3. Affilitation (Faculty, Staff,Employee, or Student)
            4. The fourth pillar, Infrastructure Service: provide a means by which LEA partners are empowered provision virtual machines, persistent storage, and disaster/recovery services.
        2. Okay with context at least presented in the course-grained outline and bullets above, as IlliniCloud 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.
      4. Identity Service
        1. 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.
        2. 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.
      5. Data Service
        1. 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.
        2. 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.
      6. Presentation Service
        1. 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.
      7. How Far Have We Gotten
        1. 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".
        2. The high-level workflow-segments for a new LEA operational partner are:
          1. "Organization Registration"
            1. http://stream.illinicloud.org/step one.mp4  short demonstration video (good)
            2. operator must screen and approve applications submitted.
          2. "Account Claim and Registry Activation"
            1. http://stream.illinicloud.org/part two.mp4  short demonstration video (okay, needs some refinement)
            2. organization account activated in the registry.
          3. "Connectivity"
            1. http://stream.illinicloud.org/step three.mp4 short demonstration video (okay, needs some refinement)
            2. LEA provides details necessary to delegate authentication and interrogate authorization attribute from source-systems
              1. primary data source database OR directory service
              2. multiple data sources may be required to answer some requirement authoritatively
            3. minimal operational capability
          4. "Attribute-Resolution"
            1. Video being produced (not yet available)
              1. Entitlements are the challenge, the core general purpose attributes are generally easy to resolve.
              2. Many case require interrogation of multiple source-systems, ie. teacher-of-record is not in directory, but rather in SIS.
            2. Simple single-value attributes and  complex multiple-value arrays
            3. meets core general purpose attribute requirements (meets app-launcher requirements)
          5. "Registered SP Enrollment"
            1. Custom application-specific attribute resolution rules
            2. Authorize IDP to enable service operations with a SP on behalf of the LEA
        3. The high-level workflow-segments for a new SP operational partner are:
          1. "Organization Registration" 
            1. http://stream.illinicloud.org/step one.mp4  short demonstration video (good)
            2. operator must screen and approve applications submitted.
          2. "Account Claim and Registry Activation"
            1. http://stream.illinicloud.org/part two.mp4  short demonstration video (okay, needs some refinement)
            2. organization account activated in the registry.
          3. "Connectivity"
            1. establish IDP/SP connectivity and minimal attribute assertion propagation (no LEA)
            2. exchange metadata, declare attribute requirements, and provide any additional functional requirements
        4. Active Partnerships achieved and in-progress:
          1. 18 LEA organizations registered (most are in progress)
          2. 7 SP integration completed with one or more LEA using service
            1. Pearson
            2. PowerMyLearning
            3. BrainPop
            4. Moodle
            5. MasteryConnect
            6. Isle Dashboard (NIU educator dashboard)
            7. Isle OER (Search with CWD)
          3. 5 SP integration actively in progress
            1. DiscoveryEd
            2. ReadingPlus
            3. iSafe
            4. EdAutomate
            5. Symphony Learning
      8. What Have We Learned
        1. 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.
        2. As the owner/operator, primary architect, and funding facilitator of the FSS concept, IlliniCloud as engaged several vendor (partners) to help achieve a vision that promotes and enhances the K12 community's ability to be competitive, cost effective,  be more efficient, and to seed the need to flip the business equation from a vendor dominated market to a customer dominated market.
        3. IlliniCloud's central services Vendor/Partners (involved in the three pillars focal efforts) are:
          1. CPSI  an Illinois based company that specializes in K12 (SIF) implementations for States and LEAs.
          2. Unicon an Arizona based software consultancy organization with strong roots in the Apero Foundation community.
          3. Aegis Identity a Colorado based organization developing and marketing the TridentHE and TridentK12 (identity provisioning management)
      9. Brief Question Lead-ins:
        1. (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.
        2. 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.
          1. Vendor partnerships have been channeled into two camps:
            1. software licensing: is always an equation focused on the potential to provide resources to community members (LEA partners)
            2. professional services: development requirements and the artifacts produced are cast as "work-for-hire"
          2. Vendors that sell software services or professional services to LEA partners are:
            1. FSS SP operational partners
            2. professional service providers do not have a role in the FSS as it is currently manifested.
          3. 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:
            1. For example, DiscoveryEd is SAML ready and can be accommodated with a roster prerequisite and IDP configuration. However the use of this service option comes with a one-time  professional service fees of ~3K. In the IlliniCloud case, as an IDP/Proxy the level of effort for all LEA enrollments beyond the first is greatly reduced on both sides (SP and IDP).  This fact is a strong basis for negotiating reduction in the flat fee structure currently imposed and defined in context of business model that was based on a per LEA engagement basis.
            2. As general rule of thumb, all SP implementations must be performed on behalf of a member LEA and will use a strategy that:
              1. must be configured in the per-production (dev) platform
              2. must include a pilot group of users to validate and verify the functional goals are satisfied.
              3. production promotion is generally cast as exposure to fully population of a given LEA (or building or classroom-set).
            3. Payments should always be contingent upon production deployment and use.
          4. 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.
            1. upon successful implementation of the mechanical requirements to make functional the SSO (and other ETL requirements) the LEA should be working with the professional development component of the resource vendor to enhance their potential to realize the best benefits available to them through the use of the product(s) the LEA has selected to use.
            2. There is no direct role with the possible exception of direct or in-direct support (helpdesk, and issue resolution) where a vendor of the operator is acting a customer-facing representative of the operator (this is a potential conflict of interest scenario)
            3. Customer feedback and confirmation are always at the top of the list of evaluation, followed closely by peer feedback.
              1. Choosing vendors and products will always be a decision process that is in the hands of the LEA customers.
              2. As an operator, it is important to facilitate strong operational capacity with the broadest possible range of resources beneficial to their community of customers, as defined by the customers.
  3. Next All Pilots call: Thursday, March 26, 2015 at 4pm ET




  • No labels