The objective of this document is to identify issues and/or gaps in having a fully functioning federated identity solution and highlight possible solutions in order to drive action towards assigning responsibility to close these issues.
In our opinion, answers and/or plans to address these questions need to be developed either between the CCCTC and the campus/district CTOs or between the CCCTC and Unicon. We see these as prerequisites to a successful larger scale roll-out of this new Single-Sign-On capability throughout the CCC system that meets the federated identity goals of the CCCTC.
As part of the overall identity federation project, Unicon has configured and deployed a CCC IdP Proxy through which applications available across CCC campuses can centralize authentication requests. The IdP proxy then contacts the appropriate “real’ IdP to complete requests. The goal of this design is to simplify and accelerate system wide technology adoption and provide uniform experiences for key users.
The IdP Proxy and supporting components are currently operating in three environments, Continuous Integrated (supporting development activities), Test (supporting functional testing), and Pilot (for early stage proof of operations with early adopters). It will soon be deployed to a Production environment. In addition to the question of how Unicon will be able to support a critical cog in the CCC infrastructure on a 7x24 basis with very high, e.g. 99.999% availability, several “bigger picture” questions have been raised, primarily by Unicon’s Mike Grady. Mike is an architect in Unicon’s IAM practice with broad experience deploying IAM solutions to higher ed institutions, including federated identity.
Background
Canvas LMS and Hobsons Retention systems only require a single identifier that must match the identifier the college/district already sent in a "provisioning feed". For the campuses Unicon has worked with on Canvas, that's been the user's "username", usually in
the form of the eduPersonPrincipalName (EPPN), e.g. jsmith@bestcc.edu. This may or may not be consistent across the colleges.
The first task that needs to be done is to commission a project to document the identifier that was used for the provisioning feed for all of the onboarded colleges.
Second, for the cccId to be relevant for Canvas and Hobsons systems, someone will need to to work with those companies to change their SAML integration on their SP side to also look for and take appropriate action with the cccId.
A key item for both Canvas and Hobsons systems is that the identifier in the feed needs to match the identifier setup to send from the IdP. For the Proxy to be effective, this identifier needs to be standardized as the EPPN. CCC will need to dictate this as a standard practice to the campuses.
An outstanding question that needs to be answered is how do the Canvas and Hobsons systems tie the identifier, hopefully EPPN, in the provisioning feed with the cccId that the Proxy ultimately will be sending?
Note, if a student is enrolled at multiple colleges, they will have unique EPPNs at each college but the cccId will be unique for that student and thus provide a way to correlate their records in the external service.
The contracts for the Canvas and Hobsons systems are between the campus and each service provider. As part of that, the campus designates the person(s) who have an "administrative role" with that service and can update/change settings on the service side. Unicon is unable to do that for them, unless they designate our organization as having that administrative role.
Background
Existing colleges/districts using Canvas and Hobsons systems thus far are connected directly to the CCC applications, i.e. they have configured their IdPs to auth with Canvas or Hobsons via SAML, and NOT through the IdP Proxy.
The appropriate designee will need to work with colleges/districts to migrate over to including the IdP Proxy in the auth path to the services.
For Canvas and Hobsons as well as additional CCC services, it seems like one positive to get colleges/districts to get on board with the IdP Proxy, even without the value add of the cccId, would be that the IdP Proxy would exchange metadata with all the services and that the college/district would only need to to exchange metadata with the Proxy to be able to auth to all the backend services. This would greatly lessen the colleges/districts IdP maintenance effort. That is, we'd work out the metadata exchange for the the new external services on the Idp Proxy and all of the college/district IdPs could access that services without modifications to their local IdP configuration.
It also simplifies for attribute release, because the campus does not need to add a new attribute release rule for that service. They just have the one key attribute release rule to release all the information that might be needed by any service to the Proxy.
Background
From our work for in the IAM space for college/districts, it appears that CCC is very much in need of some standardization of operational practices, for example provisioning and policies, as well as a much better overall understanding of identity management if it is actually going to function as a "system", not just a bunch of disparate parts.
In our opinion, the best model is to have the lightest weight IdP footprint on each campus/district, ideally hosted, all just talking to the IdP Proxy. This limits the campus staff and knowledge limitations that often surface. However, if a campus knew what it was doing and wanted use their local IdP for more, then that should also be a viable option.
This also includes a support model in place with a plan for such things as the release of a software update to patch a Shibboleth vulnerability.
Unfortunately, there is a lot of work to be done now due to not having a model and standardization in place from the start.
Background
A major aspect of the IdP Proxy that has not yet been addressed is the policy around its operation and handling of the data that is shared with and through it.
The setup and operation of the IdP Proxy is simplified if the campus/district IdPs send the full set of available attributes to the IdP Proxy every time, regardless of the service that is asking the Proxy for attributes. That means any attribute that any service integration requires. That not only simplifies the IdP Proxy, but it also minimizes the need for local campus/district IdP changes as new services get integrated into the IdP Proxy. Unless an entirely new attribute is required, no change has to be made to the campus/district IdP. It would be incumbent on the Proxy, in this scenario, to filter the attributes it has received from the campus, and only share those attributes that the particular service requires.
The IdP Proxy also enables the "operational manager" of the IdP Proxy to decide to add new services that it supports and will share attributes with. That's a big advantage of the Proxy in the first place, but it must also be recognized that takes some control of campus data out of the hands of the data custodians on each campus.
With the above, it is important that a data policy, and IdP Proxy operational policy, be developed and communicated to the campuses so they fully understand the role that the IdP Proxy will be serving, and how that will ease the demand on campus operations. But also so they can understand the governance and data handling practices of the Proxy, such as:
Who governs the IdP Proxy and how it is monitored
Security practices around the IdP Proxy
The IdP Proxy will retain no individual person data itself, only logs for security/problem solving/statistics
The IdP Proxy will only add services that are vetted and/or contracted for such that all CCC data policies are satisfied/observed
The IdP Proxy will send only the subset of attributes it receives from a campus that a given service requires
Background
FERPA considerations have also been raised by our IAM practice, based on experience in other Higher Ed institutions. At some institutions, a field in the directory indicates whether a student has "elected" to exercise rights to withhold data release under FERPA. The reality is that generally very few choose to exercise this option, but the numbers don't really matter, the capability of making a discrimination does. We don't know if this has been considered across the colleges/districts but raise it as a discussion point.
Our IAM practice finds that the "data steward" for student data is the Registrar. Release of student data ultimately comes under their purview, and often with legal counsel weighing in on what becomes a "joint interpretation of what FERPA allows and does not allow". What data is released to cloud services and what the services can and can't do with that data is presumably defined in college/district contracts the with cloud services. With the IdP Proxy sitting in between colleges/districts and the service, some might consider things to be less clear. Again, this is raised more as a discussion point.
Can the CCCTC lead a campaign to get campuses/districts thinking about these issues of data stewardship and get agreement that it is ok that these attributes be shared with the services the IdPs and the IdP Proxy support? With the proxy, the possibility exists that the release rules and services to which they are released could be managed "centrally", i.e. in the proxy, but global agreement as to what attributes should be shared should be gained.
