TechEDge | California Community Colleges

Tech>ology: Federated Identity–Part II

Last Updated on Thursday, 01 July 2010 Written by Tim Calhoon Monday, 28 June 2010

In a previous blog post, I relayed that we are currently engaged in the development of a new infrastructure for systemwide applications, a key component of which is Federated Identity. In part one of this two part blog we discussed the advantages for colleges adopting a federated, standards based, single sign-on approach to dealing with the proliferation of cloud based applications (e-mail, library resources, learning management systems, etc.) moving into campus IT. In addition to these commercial services, we also have systemwide service offerings to colleges such as CCCApply and the California Virtual Campus Catalog.

Currently separate logins exist for various systemwide services. Under a Federated ID system, one login would exist for all making it much easier to link account data in these services together. Consider for example the power of correlating student’s college placement test scores (CCCAssess) to transcript data (eTranscript California).

Federated ID will allow us to better transfer account data when a student transfers to California State University (CSU) and University of California (UC). For example, via a linkage established through Federated ID, a student filling out a UC application may be able to access data in their CCCApply account to help fill in the form or populate their new UC account.

Access to a California Community Colleges systemwide service may come either through a link on the Web, a systemwide student portal or a college’s portal. If a student is already logged in at a college’s portal, they should not have to re-authenticate to access a systemwide service from that portal. To accomplish this seamless linkage, software called an Identity Provider (IdP) is connected to the college's account database.

Central to linking systemwide and college data may be the application of a systemwide identifier (CCCID). Commonly, the CCCID associated with a systemwide student account would be generated when a student first applies to college with CCCApply. The CCCID would be passed to the college with the application data file. When the college creates the student account locally in their account database, the CCCID could be stored as an attribute of the student. When accessing a systemwide service from a college portal, the CCCID would be passed to identify the student.

Alternatively, an anonymous encrypted token, called a TargetedID made from the student’s college username and the college’s name, may be matched to the CCCID in a lookup list at the systewide CCC IdP, if the college does not store and pass the CCCID. The TargetedID is generated by the college’s IdP from data in the college’s account database. This alternate method is not as seamless as passing the CCCID and may require a one-time systemwide account login when a student tries to use a systemwide service to establish an entry in the lookup list.

Even though we can get around storing and passing a CCCID, there is a strong case to be made that the future of our community college system is at stake. For reasons discussed in part one, many of our students do attend several colleges over the course of their academic lives. Tying their disparate data together not only will help us do a better job of serving each student, but will also allow us to analyze data, identify trends and strengthen our effectiveness as a system. <>