Based on the outcomes of the NCTrust Pilot Federation
January 2010
Authors/Editors:
Mark Scheible, NC State University
Steve Thorpe, MCNC
Mike Veckenstedt, North Carolina Department of Public Instruction
Tim Poe, MCNC
Susan Johnson, Charlotte-Mecklenburg Schools

Table of Contents .......................................................................................................................................... 2
EXECUTIVE SUMMARY .................................................................................................................................. 3
PILOT OVERVIEW .......................................................................................................................................... 5
INTRODUCTION ......................................................................................................................................... 5
SCOPE OF PROJECT (NCTrust) ................................................................................................................... 6
PILOT PLANNING ....................................................................................................................................... 7
DECISION PROCESS (InCommon vs. Standalone Federation) ................................................................... 9
TRAINING (“ShibFests”) .......................................................................................................................... 12
SHARING OUR NCTrust EXPERIENCES ..................................................................................................... 12
CHALLENGES ........................................................................................................................................... 13
SUCCESSES AND LESSONS LEARNED ....................................................................................................... 16
MOVING FORWARD .................................................................................................................................... 17
OPPORTUNITIES, PEERS, and COLLABORATION ..................................................................................... 17
NEW VENTURES ...................................................................................................................................... 18
DECISIONS, RECOMMENDATIONS, AND NEXT STEPS ............................................................................. 19
SUMMARY/CLOSING ................................................................................................................................... 22
Operational Aspects for NCTrust (Appendix A) ......................................................................................... 27
Documentation for current and proposed NCTrust (Appendix B) ............................................................. 31
North Carolina Demographics (Appendix C) ............................................................................................. 36
Page 2 of 36

In November, 2007 a group of individuals representing various educational institutions and functions within the state of North Carolina met to discuss Federated Identity Management for the state’s K-20 community. Tasked by MCNC’s Collaborative Services Working Group
(CSWG) to find a way to provide better access to the state’s online web resources, the Federated
Identity Management Task Force (FIM-TF) set out to:
•
Identify a way to make use of the NCREN network bandwidth now being provided to K-
20 schools (develop use cases)
• Provide online web-based resources and services to the K-20 community in a more efficient way (eliminating the need for a separate local username and password at each resource)
• Explore how the state could provide federated access to these resources
•
Establish a pilot project to identify what challenges would be encountered in a K-20 federation for the state (including K-12 in the mix of participants would be a unique aspect of the pilot)
• Make recommendations for expanding the pilot based on outcomes and findings.
Early meetings focused on the development of use cases for a pilot project – what problems would be resolved or benefits obtained by implementing a statewide K-20 identity federation?
Additionally, the group focused on choosing a framework for an identity federation. The two viable options were to create our own federation (as the UNC System General Administration had done) or use an existing trust federation such as InCommon, and layer our pilot federation on top of it. This latter approach was taken by the University of California System in building their federation and was ultimately the option chosen for the NCTrust Pilot Federation. The benefits of using InCommon included:
 Participation in an existing and functioning identity federation, with many users capable of providing answers to technical questions we might have
 Use of established procedures for new participants, along with legally vetted agreements
 and documentation
Access to the resources (Service Providers) of the larger federation - as each pilot organization had to join InCommon as part of the NCTrust pilot
 The freedom to concentrate on the primary mission of the pilot – to understand what challenges we would encounter in creating an identity federation to serve the K-20 communities of the state
After two years of planning and implementation, the NCTrust Pilot Federation is a reality! We have three working Service Providers (SPs) - VCL, NC Live and MCNC’s web site, with
Identity Providers (IdPs) from eight institutions (MCNC, NC State, UNC-CH, Duke University,
Wake Technical Community College, The North Carolina Department of Public Instruction,
Rockingham County Schools and Davie County Schools). Although we provided technical
Page 3 of 36

training (ShibFests) to the participants of the pilot, we found that the level of technical expertise required to install and support Shibboleth entities was only available at the larger institutions.
This highlighted the necessity of an “Appliance IdP”, which was provided to many of the participants through a virtual (VMware) machine. The benefit of using InCommon for the federation continues to be reinforced; however, the cost of membership for all K-20 schools in the state will require a creative funding solution, a way to reduce the number of IdPs needed, or possibly a state-run alternative.
The future success of NCTrust will depend on how well we can develop a process for bringing new participants into the federation – both IdPs and SPs. “Shibbolizing” new and existing applications and web resources will provide a growing benefit to federation members as well as encourage new participants. Development of a governance structure and ongoing funding sources will be the primary challenges as we move forward.
Page 4 of 36

North Carolina is fortunate to have the key organizations of our K-20 educational community
(K-12 public schools, community colleges, public and independent universities) working together in an increasingly cohesive fashion. There is now a clear recognition that all of the students of our state benefit when there is cooperation between all of the educational organizations in North Carolina. As we see greater cooperation between K-20 organizations, we also see opportunities for the procurement and sharing of resources in ways that were not possible in the past. It is now possible to imagine software as a service (SaaS) or Cloud
Computing deployments that can benefit all K-12s, community colleges, etc. Similarly, we can begin to plan for digital, web-based resources that can be reused to support learning (also known as learning object repositories
) that can be securely accessed as needed across the K-20 community. Costs to licensing and infrastructure can be drastically reduced due to economies of scale that can be leveraged with multi-institutional purchases. One of the cornerstones of a K-20 technology platform is the implementation of Federated Identity Management.
Federated Identity Management infrastructure based on the open-source Shibboleth
1
software allows multiple organizations (universities, community colleges, K-12 schools, government organizations, etc.) to authenticate to shared, Web-based resources using their home institutions' existing identity management environments. When a new person joins an organization, she or he can easily be given access to whatever resources are relevant to her or his role within that organization. Similarly, access to all resources available through the Federated organization can be immediately changed or revoked when the status of a member of an organization changes.
This will greatly reduce the administrative overhead associated with managing both large and small organizations’ access to services.
The power of Federated ID Management lies in the notion that each organization is best able to determine those members that are legitimate, and what their roles are in their organization. In this way a multitude of Web-based services can be securely maintained, with efficient and appropriate access provided for each member of each organization. It should be noted that, when deemed appropriate, resources from organizations in other states, or national resources (for example, documents from The National Science Foundation) may also be securely accessed.
See the diagram below for a high level example of Shibboleth components.
1 http://shibboleth.internet2.edu/
Page 5 of 36

The NCTrust pilot was developed to span K-20 education in North Carolina. From an Identity
Provider (IdP) perspective, this includes:
 K-12 Public Schools o o
Davie County Schools
Rockingham County Schools
 Community Colleges o Central Piedmont Community College o Wake Technical Community College
 Public Universities o North Carolina State University o University of North Carolina at Chapel Hill
 Independent Schools o Duke University
 Provider of the North Carolina Research and Education Network o MCNC
Page 6 of 36

Service Providers (SP) in the federation include:


The Virtual Computing Lab
2
(VCL) at NC State University
NC LIVE 3 – licensed online content from print and digital media (e-books, e-audio, streaming video)
 MCNC's web site and (soon) Confluence Wiki site
 DPI's test application (soon)
 Other SPs are mentioned in the New Ventures section of this document
The full scope of the project, moving forward, will be to benefit all North Carolina educational entities and their related vendors (as service providers) including (but not limited to):


Libraries
 Museums
North Carolina Zoo


Other educationally relevant organizations
 Educational vendors (Discovery Learning, etc.)
Email providers (Google, Microsoft, etc.)
 Cloud/VM hosted infrastructure
This makes NCTrust somewhat unique, compared to efforts in other states which tend to focus on higher education. While the pilot was not able to include the North Carolina state IT organization (ITS), there are currently discussions under way to accommodate the inclusion of
ITS as both a service provider and an identity provider. This is of vital importance because:
 ITS provides services to many of the schools in the state.
 ITS already includes all state employees, including all public school teachers in the state.
Once it was decided to move forward with the pilot, the Task Force was faced with a choice on the technical implementation of a federation. "Local" experience was available in that the UNC
System had recently created its own federation for shared resources, in particular an interinstitutional class registration application. In this case the UNC System IT organization set up its own standalone federation, managed their metadata and ran a Certificate Authority and WAYF 4 .
2 http://vcl.ncsu.edu
3 http://www.nclive.org
4 A “Where Are You From” service provides a list of member IdPs for the user to authenticate against. The user selects their “home” organization and is redirected there to login.
Page 7 of 36

This is how the University of Texas system federation is configured. However, this approach requires significant technical expertise and more importantly a heavy investment in administrative and policy work. A second technical approach was showcased by the University of California through their implementation of the UCTrust federation. This federation was built on top of the national higher education and research federation InCommon 5 . The Task Force explored each of these options via video conference as described below.
InCommon Video Conference with John Krienke
In March, 2008 a discussion was held with John Krienke from InCommon on federation membership information and how UCTrust had been established. While he couldn't go into too much detail, he did explain the benefits of following that model and provided more information on the InCommon Federation. The Task Force decided to talk with the architects of both the
University of Texas federation and UCTrust to find out why they had chosen different paths, and to learn from their experiences.
UT Federation Video Conference with the UT federation team
The FIM Task Force held a video conference with the University of Texas System team (Clair
Goldsmith, Paul Caskey, and Miguel Soldi) in June, 2008 to discuss their reasons and requirements for a federation. The UT federation had been built with seed money from a 2004
National Science Foundation Middleware Initiative (NMI) grant, and at the time of their decision
InCommon had not been set up. The UT Trust decided to build their federation using Internet2's
Shibboleth application (over a federation application from the Liberty Alliance), because it was designed to be used by higher education and better fit their requirements and security needs. The sixteen member federation (9 Universities, 6 Health Care institutions and the UT System) was built to enable the participants to share applications and resources between participants. The initial application to leverage the federation was a high speed wireless network accessed via local institutional credentials. Institutions that weren't part of the federation had to use a slower wireless network when visiting member institutions. Other applications were added over time.
The biggest challenges were setting up the governance and policies and procedures for running the federation.
UC Trust Video Conference with David Walker
In early July, 2008 a discussion with David Walker from the University of California System was held. He had been instrumental in establishing the UCTrust project to set up an identity federation for the UC system. In their case, InCommon was being formed at around the time UC was developing their federation policies. Today their twelve member federation includes ten campuses, the UC Office of the President, and the Lawrence Berkeley National Laboratory. The
5 http://www.incommonfederation.org/
Page 8 of 36

first requirement was that every member of UCTrust had to join InCommon. They opted to use the existing federation for convenience sake as InCommon took care of all the federation infrastructure and services. They then built much more stringent requirements into UCTrust around assurance levels and policy requirements. If InC-Silver had been around when UCTrust was being setup, they might have foregone this extra "local layer" letting InCommon take care of the certification process for "Silver" requirements.
During August, 2008 the Task Force made the decision to approach the pilot by using
InCommon as the foundation and building the NCTrust federation on top. This decision was made primarily because of the administrative and policy benefits offered by the already established federation. However, the technical support and environment provided by InCommon also factored into the decision. General benefits of the Shibboleth-based Federated Identity management technology
6
include
End-User Benefits



Ease user account management : Users no longer have to remember an array of accounts and passwords.
Privacy maintained : Users identify themselves locally with their home institution, and then pass only relevant and necessary attributes to the resource, maintaining privacy as necessary.
Convenience and security : Single sign-on reduces opportunities for accounts to be compromised and also allows users to access any number of resources while signing on only once
Administrator Benefits
 Easier and faster integration of new users, services, and resource providers


Reduce need for per service account provisioning
 Extend existing identity management and resource services
Create layers of federation for various constituencies and consortia
The above benefits become significant to members of any Shibboleth-based federation when:
1.
Policies and procedures of varied member institutions are suitably vetted for other members to safely rely on ( legal/policy assurance );
6 http://www.incommonfederation.org/benefits.cfm
Page 9 of 36

2.
Sufficient technical infrastructure is in place to manage and publish the federation's metadata that provides addressing and public certificate information for member entities
( technical infrastructure ); and
3.
Federation membership levels are (or will become) large enough to provide significant service provider/consumer opportunities among the member organizations ( membership levels )
Meeting all three of these baseline requirements to realize significant Federation benefits is a high bar to achieve, especially if seeking participants from a wide variety of organization types
(educational, government, commercial). Bi-lateral vetting of policies and procedures between each service provider/consumer pair within a Federation quickly becomes an unwieldy effort.
To effectively manage the technical infrastructure of reliable metadata management and distribution, a single trusted management entity is needed. And finally, achieving large member participation can be an uphill battle due to the time and effort required for the legal / policy assurance and technical infrastructure stages. While the NCTrust Federated ID Management pilot could have attempted this on its own, instead we chose to take advantage of the nationally known InCommon Federation which for a very reasonable participation cost allowed us to relatively quickly meet all three baseline requirements.
The mission of the InCommon Federation is to create and support a common framework for trustworthy shared management of access to on-line resources in support of education and research in the United States. To achieve its mission, InCommon facilitates development of a community-based common trust fabric sufficient to enable participants to make appropriate decisions about the release of identity information and the control of access to protected online resources. InCommon is intended to enable production-level end-user access to a wide variety of protected resources
7
.
InCommon Federation's formalized infrastructure is an enormous benefit to participants, in that it eases the overhead required in formation of bilateral trust arrangements between service providers and identity providers across a wide variety of boundaries encompassing the higher education, commercial and government communities. Organizations applying to join InCommon must agree at an executive level of their organization to the terms and conditions of federation participation (legal framework and federation policies), which include documenting an organization's practices and procedures used to grant and manage user accounts. These documented practices and procedures are available for review by other Federation participants, enabling them to decide on a case-by-case basis whether to allow interactions with entities hosted by other Federation members. Finally, contacts for the organization must be official representatives and will be verified by InCommon as such
8
.
7 http://www.incommonfederation.org/about.cfm
8 http://www.incommonfederation.org/docs/guides/faq.cfm
Page 10 of 36

As of August 2009, the InCommon Federation member institutions served a growing community of more than 3.6 million end users. Member institutions included 118 higher education participants; 6 large national laboratories, research centers and agencies; and 43 sponsored partner participants
9
. A small sample of these illustrious institutions includes the National
Institutes of Health, the National Science Foundation, Apple Computer, Microsoft, University of
North Carolina at Chapel Hill, North Carolina State University, Duke University, Clemson
University, and Massachusetts Institute of Technology just to name a few.
Additional benefits gained by joining InCommon
10
:


Higher security : Policy-driven methods, using strong authorization controls over secure access channels, provide a higher-level security. This higher level also provides a secure mechanism for ensuring privacy in the exchange of identity and authorization attributes.
Economies of scale for contractual agreements: Some or all of the policy and legal requirements for bilateral agreements between institutions for sharing of resources may be consolidated by or leveraged from the Federation policies, agreements and requirements documents. This could minimize the need or scope of multiple relying party agreements.
 Provide a standard conduit for collaboration : The Federation acts as a collection point

 and conduit for those wishing to provide and gain access to collaborative web based resources. Using a standard mechanism for connecting to this conduit provides economies of scale by reducing or removing the need to repeat integration work for each new collaborative work.
Reduced account overhead : Account creation and management can be reduced for resource consumers who are not affiliated with the institution offering those resources.
As a federation member, these resources are made available to other federation members who are responsible for managing those accounts.
More granular control over access to and auditing of online resource distribution :
Institutions currently offering resources restricted by IP address or other gross controls will be able use authorization decisions to enforce more granular control for the distribution of cost based resources. The results of which lead to a more consistent accounting of which resources are actually being utilized and by whom.
In short, since InCommon clearly meets these three key requirements we proceeded to utilize them for the NCTrust Federation's baseline infrastructure:
1.
legal/policy assurance;
2.
technical infrastructure; and
3.
membership levels
9 http://www.incommonfederation.org/participants/
10 http://www.incommonfederation.org/benefits.cfm
Page 11 of 36

In October 2008 then again in February 2009, MCNC hosted two-day hands-on Shibboleth
Training workshops. Slides and lab materials were based on those provided by Internet2, slightly modified. The lead instructor was Duke University's Shilen Patel, assisted by Duke's Rob
Carter and MCNC's Gonz Guzman. Topics included Shibboleth Identity Provider and Service
Provider theory, as well as hands-on exercises with VMware virtual machines. For a look at the materials including slides, labs, and video streams of the lectures, please see https://edspace.mcnc.org/confluence/display/FIM/Shibboleth+Training+Workshop
.
Overall these workshops were a fantastic success. Shilen Patel was a very knowledgeable instructor and the labs reinforced the presented materials. Approximately 50 people from dozens of institutions attended the two fully attended workshops. That said, because there is such a large amount of content and topic area expertise required to learn Shibboleth it was somewhat overwhelming for many of the attendees. We found that follow-up consulting with attendees
was often very helpful. See the " CHALLENGES " section of this document for further information.
The first presentation of the NCTrust K-20 Federation Pilot was made at NC State University as a session at their OIT Expo, October 9, 2008. Tim Poe of MCNC was asked to make a presentation describing the project. The abstract from the event stated:
"As more and more web-based services become available in North Carolina, it is neither feasible nor desirable to create and manage user IDs for each Web-based service. A more scalable solution is needed to create or utilize a federated identity management trust and allow service providers to use the existing identity management systems of organizations that need access to their online services. The NCTrust Pilot project was recently formed among several institutions, including NCSU, MCNC, and others. It will create a Federation to test web resource sharing for the K-20 organizations throughout the state of North Carolina. The NCTrust Federation Pilot will consist of various K-20 identity providers (universities, community colleges, LEAs, etc.) and online service providers (Virtual Computing Lab, NC Live, etc.). Participants will gain access to online resources using their usernames and passwords as assigned by their home organizations.
Service providers will be able to provide authenticated access to their resources by utilizing the identity management systems of the participants. The underlying technology enabling the pilot is
Shibboleth: a standards-based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner, and each site is able to manage its own login / password information. This talk will provide a brief overview of the ongoing NCTrust pilot project."
Page 12 of 36

Although very early in the pilot, it was the first public presentation of the vision for a statewide identity federation to provide access to K-20 resources, many of which were suggested or proposed in the session.
One of the collaborative groups sponsored by Internet2 is US Trust Federations. The group has a conference call once a month to discuss Federations within the US. Led by George Laskaris of
NJedge.net, the calls usually involve a presentation of a state or "system" federation, followed by a question and answer period. The introductory call took place in December, 2008 and was followed by discussions of the UT Federation, InCommon and Becta (the K12 federation in the
UK). In March, 2009, George asked whether "North Carolina" would be interested in presenting for the April call. Mark Scheible agreed to do a presentation on North Carolina federation efforts including both NCTrust, and the UNC System Federation. The presentation was well received and there was some discussion of K20 efforts taking place in other states.
Mark also had a proposal accepted by Internet2 to present on NCTrust at their Spring Member
Meeting in Arlington, VA. This took place in late April, 2009. Steve Thorpe also presented remotely from MCNC. The session - Building Strong K20 Initiatives: NCTrust K-20 Federation
Pilot and MAGPI's Collaboration with Kentucky - was a joint panel presentation.
The NCTrust presentation discussed the formation of the Federated Identity Management Task
Force and how the pilot project was started, including the early exploration into how other federations were established (University of Texas Federation and University of California -
UCTrust). We then explained why the Task Force chose the UCTrust model and based our federation on the InCommon infrastructure. The rest of the talk focused on Challenges, Lessons
Learned, Unexpected Benefits, Future Challenges and Next Steps - followed by a question and answer segment. This presentation took place just after the Rockingham County Schools LEA was admitted to InCommon - the first K-12 organization to join. Through these and other presentations and discussions at national meetings and conferences (Tim Poe at the Internet2 Fall
Member Meeting in October, and Mark at the EDUCAUSE Annual Meeting in November),
NCTrust and North Carolina have become recognized as leaders in implementing federated identity management to provide access to K-20 resources in the state.
At NCREN's 25th Anniversary Community Day Event there was a presentation by George
Laskaris of NJEdge.net on NJVID: a Collaborative Portal for Statewide Video Access, which discussed New Jersey's efforts at federated access to a video object repository. This was followed by a presentation by Mike Veckenstedt of the North Carolina Department of Public
Instruction on NCTrust and comparisons were made between the two efforts. This provided additional visibility to educational and state leaders of our efforts to provide a state wide federation for K-20 access to shared state resources.
As expected, several challenges emerged during the initial two-year NCTrust project. In fact these anticipated challenges were a primary motivation for casting the federation as a pilot rather than a production effort. During this phase, the Task Force gained experience in many aspects of creating a federation ranging from technical to administrative, and we plan to apply these in
Page 13 of 36

future Identity Management efforts that are to be more production in nature. Some areas of particular note included:
 Technology Learning Curve
 Legal approval


NCTrust Memorandum of Understanding
 InCommon Application
Cost of InCommon membership
 Identity Provider hosting and implementation
 Service Provider hosting and implementation
 K-12 participation and content
Shibboleth Federated ID Management technology is quite beneficial towards enabling authorized access to web-based resources across organizational boundaries. To help administrators learn about the technology, various on-line documentation and training resources are available.
However during this pilot effort we learned the technical implementation aspects are non-trivial.
To some extent this is due to the myriad technologies through the application stack required in the implementation process, above and beyond the concepts related to Shibboleth attribute sharing among federation members. There is a veritable fire-hose of related technology information, which was a high barrier for many of the participants to overcome, especially those without significant systems administration and programming experience. For example, students in the "ShibFest" training workshops were expected to interact with the following technologies during the two-day sessions:


RPM packages
 network configuration
Linux service configuration
 bash command line shell interaction
 vi editor
 Java
 Tomcat application container


Apache web server
 X509 Certificates
XML editing
To help our team members better grapple with these technologies, the FIM Task Force maintained a wiki page of technical references
11
.
The initial efforts of the pilot included development of a Memorandum of Understanding (MOU) for the various NCTrust participants to sign. The MOU 12 outlined expected roles and
11 https://edspace.mcnc.org/confluence/display/FIM/Shibboleth+Technical+References
12 https://edspace.mcnc.org/confluence/display/FIM/MOU+Signature+Status+Page
Page 14 of 36

responsibilities of participants, including the need to apply for InCommon membership which has its own documentation to sign (as well as fees to pay). It was sometimes a herculean effort to get the authorized institutional legal team and executives to approve and sign these documents. The cost aspect of InCommon membership ($750 startup fee plus $1000/year as of
2009) was also a challenge - although these are not huge amounts, they weren't necessarily budgeted for and also 2009 was a very difficult economic year. MCNC was able to partially mitigate the financial hurdle for most of the initial participants, by bearing those first-year costs.
Hosting and implementation of the web application servers for the Services (SPs) and Identity
Providers (IdPs) did take some effort to get off the ground. SP configuration is done on a caseby-case basis with each particular service being offered. The typical scenario requires the
"owner" of the web service to be shibbolized within NCTrust to take the lead on Shib configuration for that SP. On an as-needed basis, collaboration within the NCTrust federation, the shib-users email list, the InCommon support staff would help with any problems that were encountered.
To help with the IdPs, MCNC developed a generic virtual machine appliance preconfigured with the Shibboleth IdP software and some InCommon settings. This was implemented within a
VMware virtual machine, and was accompanied with a documented set of steps
13
to transition the generic appliance to a host-institution's customized setup with its entityId information published within the InCommon metadata.
This InCommon IdP appliance VM was quite helpful, though even with the appliance the installation process still wasn't a simple matter. It was usually smoothest when MCNC worked closely with a participating institution to assist. The typical scenario was that MCNC systems staff would coordinate ahead of time with systems staff of a new NCTrust participant to exchange configuration information. Then MCNC would prepare and test appliance VM, customized with the appropriate Active Directory/LDAP and Look-and-Feel settings for that organization. Next, MCNC would make a site visit where the VM was installed and any final tuning performed. Then as a final step in most cases, MCNC would monitor the IdP service using its monitoring tools to confirm its continued availability.
K-12 participants have probably even more stringent privacy and participation issues than participants from higher-education, though the topics in this paragraph could easily apply to higher-education as well. For example on the IdP side, the K-12 institution may wish to prohibit certain users from using Shibboleth at all. Another possibility would be to allow a user to take advantage of Shibboleth services but to release only a minimal set of attributes, or to limit the user to only certain services. These requirements are in fact "easily" handled using appropriate configuration of the Shibboleth entities, however like many other computer software configuration issues its only easy once you know how to do it. It's the figuring out how to do it that can often be quite the opposite - very hard!
13 https://edspace.mcnc.org/confluence/download/attachments/8258684/incommon-nctrust-idpappliance.readme.txt
Page 15 of 36

The challenges outlined in this section motivate the Task Force to recommend a centralized technical resource to assist with managing and operating a statewide K-20 federation, as further discussed elsewhere in this document.
 VCL – The Virtual Computing Lab was well into its production phase when approached about using Shibboleth for federated access to the application site and participating in NCTrust as a Service Provider. Federated access by means of Shibboleth enabled VCL to authenticate users from many new institutions without having to configure their server to be able to look up users in each institution's LDAP server. This was the method they had been using for previous clients. The amount of work it took to set up Shibboleth was roughly double what it would have taken to set up authentication via LDAP for a single institution. By doing some extra work (setting up Shibboleth) to be able to authenticate users from one institution, we gained the ability to authenticate users from many institutions. We also gained the added security of users entering their credentials directly into their own institutions' authentication servers instead of sending them to the VCL site which then sent them to the correct institution's server . (Although passwords are always encrypted when they are passed around with LDAP, Shibboleth cut out the VCL site as a “middleman”. This was both more secure and reinforced the training of users to only enter their passwords on their own institutions' sites). Another benefit was that once Shibboleth was installed and the
SP configured, VCL could be accessed not only by NCTrust participants but those within the UNC System Identity Federation (with a minor xml code change). This was a “win” for VCL as their client base consisted of UNC system universities as well as some of the participants that were (or will be) in the NCTrust federation. They were also looking at providing access to VCL for K12 schools, and we were making that population available to them via the NCTrust pilot. VCL became the first SP in NCTrust in May, 2009 and provided us a great test bed for further participant IdP implementations.
 NC LIVE – Our second Service Provider for NCTrust highlighted one of our lessons learned in establishing the pilot. Frequently, the challenge is not the technical implementation of a project, but the administrative hurdles required to accomplish what appears to be relatively simple task.
Due to the unique nature of NC LIVE’s collaborative Communities of Interest (the libraries of the University of North Carolina
System, the North Carolina Community College system, the public libraries of North
Carolina – serving all 100 counties, and the North Carolina Independent Colleges and
Universities), getting the InCommon Participant Agreement signed turned out to be a challenge of herculean proportions. In the end, perseverance prevailed, but it took months of effort for NC LIVE to get their InCommon agreement signed and executed.
 The Shibboleth Identity Provider installation is a complex procedure . The FIM Task
Force realized the difficulties could be significantly reduced by the creation of an automated procedure to assist with the process. MCNC therefore created what we call the "IdP Appliance", a VMware Virtual Machine that comes complete with the CentOS
Page 16 of 36

OS, Java, Tomcat, Apache, and the Shibboleth IdP software. All that remains is completion of the configuration, along with deployment of the running VM into the freely available VMware server host software. Ultimately the IdP virtual machine appliance setup enabled easy configuration and delivery to many of the participants in the NCTrust pilot, including DPI, Rockingham County Schools, Davie County Schools, and Wake Tech. We definitely would recommend similar approaches to other federations, based on our positive experience with this VM. For further information, please see https://edspace.mcnc.org/confluence/download/attachments/8258684/incommon-nctrustidp-appliance.readme.txt
as well as the CHALLENGES section of this document.
 K-20 Trust - One of the most unique aspects of the NCTrust pilot was the realization the federation needed to reflect the K-20 needs of the state of North Carolina. Our state is increasingly embracing a vision of education that reflects the interactions of K-12 schools, community colleges, public universities, and independent colleges and universities. Our trust federation needs to be a tool to enable secure and fluid exchanges across a K-20 landscape, and the efforts to date have been consistent with this vision. The members of the task force worked with InCommon to gain acceptance of K-12 districts into their organization. Rockingham County Schools and Davie County Schools were the first two K-12 districts in the nation to join InCommon, and Wake Tech was the second community college in the nation. Combined with public universities, and one independent university, NCTrust demonstrated that a trust federation could truly be a K-20 entity.
Especially when combined with NC Live, a service provider with resources relevant to all members of the trust.
Opportunities moving forward would include collaboration with other state federations, organizations or university systems that are planning on including K-12 participants. As a result of presenting our NCTrust pilot efforts, we've heard of a number of other states that are pursuing an inclusive K-20 federation. We will be following up in future US Trust Federation collaborative calls with the suggestion to create a K12 Federation sub-group to focus on issues specific to the K-12 audience (SPs, vendors, ARP, privacy regulations, etc.). Also, discussions on how to include K-12 within the “higher education”-focused InCommon federation.
Many states are using access to video as a use case for implementing state K-20 federations.
NJVID is an example of one such effort and is a collaboration of NJedge.net, Rutgers University,
William Patterson University, NJ Digital Highway and VALE New Jersey (Virtual Academic
Page 17 of 36

Library Environment). The University of Virginia’s Virtual Library Consortium did something similar with their VIVA project (providing access to their 500 hours of PBS streaming video).
Discussing these types of projects with peers in other states or with Internet2 or InCommon representatives, allows us to gain new insight in moving efforts forward and at the same time allows us to share our experiences for the benefit of others.
There are several opportunities for adding new SPs and IdPs to NCTrust. Some would be relatively quick wins for the trust, while others are longer-term propositions.
Near Term


NC LOR (SP) - The North Carolina Community College System has licensed a learning object repository (utilizing Equella) for all community colleges. There are opportunities to expand the licensing to K-12s and universities. The LOR would be an excellent opportunity for using federation, both for administration of resources, and for access to restricted resources.
DPI Testing Application (SP) - The North Carolina Department of Public Instruction’s strategic plan calls for using NCTrust as the authentication middleware for applications which provide services to the School Districts as well as to NC-DPI. Examples are CIMS and data collection applications. CIMS will provide an streamlined, customizable, instructional management system to help NCDPI and LEAs meet increasing legislative mandates and requirements around student instruction, federal reporting, and accountability standards (such as Carl D. Perkins Act). Specifically, CIMS will provide for the development of secure/non-secure test itembanks; benchmark and online assessment creation, administration, validation, and scoring; automated course roster management; and extensive reporting on student performance/standards mastery detailed by demographic, exceptionality, economic, and other subgroup attributes.


LMS (Moodle, etc.) - A growing number of K-20 organizations across the state are migrating to Moodle, and Moodle is already a Shibbolized application. Thus, it would be an easy win to include instances of Moodle in the trust. NC DPI is already considering this for a Moodle instance being set up for professional development.
Google Apps (SP) - A growing number of K-20 organizations are adopting Google services for email and other applications. Inclusion of Google into the trust would be an easy with for many trust members. There is currently an issue with password resetting using other email clients (Apple Mail, Thunderbird, etc.) that needs to be resolved.
 NC Libraries (SP)
– There are projects underway in many states to provide federated access to different types of library services. The most notable of these deal with access to streaming video (e.g. The University of Virginia’s VIVA project and NJVID), however, other services may be made available over time – depending on licensing restrictions of the content.
Page 18 of 36

Longer Term



NC ID (IdP) - The NC state technology organization (ITS) utilizes a system called NCID for all state employees. Making NCID a member of NCTrust would allow for the entire state employee base to have relevant access to SPs in the trust. Additionally, it should be considered that ITS could manage SPs in the trust.
WiseOwl (SP) - NC WiseOwl is a resource in DPI which manages several resources that are collectively licensed for K-12. NC WiseOwl recently began collaborating with NC
Live (already an SP).
State identifier for K12 students (IdP) - The goal of this project is the successful assignment of state level unique ID’s to both students and staff in the pre-secondary educational system of North Carolina and to implement a system which will give the capability to lookup and/or assign the IDs through a defined set of interfaces. In order to achieve this overall project goal the following objectives will need to be met: o o
Successful implementation of the project to provide the unique Identifier lookup
Internal support system established at NCDPI for smooth transition to ownership of the application and process at the end of the project
(Note: The authentication of users is currently using NCID)


OnFizz (SP) - OnFizz is a YouTube-like application that allows students and teachers to publish videos. What distinguishes it from YouTube is the ability for teachers to moderate any comments made to videos.
 NC STEM (SP) - This organization provides resources and structure for local communities to support localized efforts to improve STEM-related education.
Statewide K12 IdP (see second point above)
 o o
Regional?
State wide?
Users from non-NCTrust organizations o NC STEM users o Protect Network
 Create an Attribute Release Policy (ARP) for NCTrust - An Attribute Release Policy defines which "attributes" or identity information about an individual will be released to
Service Providers (SPs) in the Federation. It is a recommendation to be followed by
Identity Providers (IdPs), however, the technical implementation of an ARP is defined explicitly in the "attribute-filter.xml" file on each IdP.
For NCTrust, as the intention is to include minor children, the policy needs to be very restrictive so as not to violate any federal or state privacy regulations while simultaneously protecting the identity of the student. The suggested attributes would be
Page 19 of 36

the following (actually, the same attributes used or suggested by some of the universities): o o
EPSA - EduPerson Scoped Affiliation (an attribute that indicates the affiliation of the user, and their domain or institution. An example would be student@ncsu.edu. A better attribute to be used in the future might include some eduOrg information to identify the actual school and/or school district.
EPTID -EduPerson Targeted ID is a privacy preserving identifier that is a hash
(encrypted algorithm) of some non-name identifier, coupled with information from both the IdP and SP being accessed. It allows a user to revisit the site and be recognized as a returning user (beneficial for taking an online course, or for bookmarks, etc.), without using any Personally Identifiable Information (PII).
More discussion on this topic will need to take place. Approval for the release of these identifiers, although not containing any recognizable PII, may still need to go through organizational legal review and in the case of minor students a possible "parental review”.
 Create a state-supported federation o Administrative details
Requirements o o o
Certificate Authority
Divisions within the Trust





K-12
Community Colleges
Public Universities
Independent Universities
Other
 Centralized hosting model as an option for NCTrust participants (also see Appendix
A) - One of the most challenging aspects of technology in the K-12 environment is sustainability. Far too often the main focus of discussions among educators and IT staff concern problem perception, solution identification, the myriad of vendor's feature sets addressing the solution and, of course, funding. Rarely is significant attention paid to the ongoing care and planning required by the solution, the redundancy necessary to support the commitment to the solution and the IT staffing & skill set changes required for both of these crucial areas. Relying on an inadequate support structure once the technology solution has been put in place is an assurance of failure.
Federated Identity Management, however, promises so much of an immediate solution to an overwhelming & longstanding problem in the K-12 environment, that K-12 IT staff must be open for new models of sustainability. On one hand there is the much needed technology solution available but on the other there is the support structure necessary for its success - how can a school district that lacks the structure move forward? One
Page 20 of 36

possibility is that the support be centralized and offered as a service to the K-12 community. An organization that offers this centralized service, such as MCNC perhaps, can provide what is necessary, and much more efficiently than if each K-12 agency attempted to do so individually.
The option for centralized hosting can also provide the foundation for added services for all NCTrust communities. For example, a K-12 participant, not having an existing internal system, could be offered hosted Identity Management system in addition to a hosted Identity Provider service. The same service might be of interest to Community
Colleges and other participants as well. Even more beneficial would be the benefits that centralization will provide for rapid adoption & integration of yet unforeseen Identity
Management collaborations & initiatives - technologies that are much more readily implemented, sustainably, by groups of subject matter experts on behalf of NCTrust members.
While most K-12 agencies understand that such a centralized service option would likely require funding, they also understand the benefits that come from this kind of focused external support. Very serious consideration should be given to offering a Hosting Model as North Carolina's Identity Management efforts move forward.
 Identity-Proofing Discussion (Assurance Level ) - Identity Proofing is what's used to tie a physical person to a credential (e.g. username/password). It is usually associated with
"level of assurance" an organization has that the user of the credential is who they say they are. Self-service credentials (the user signs themselves up) provide little or no assurance to the institution that the user is who they've identified themself as. Identity
Proofing usually involves a user showing a government issued ID and tying that person to their credential by having them change their password at the time they're ID-proofed. In a K12 environment, this might be somewhat different. A student that attends class on a regular basis and is "known" by the school's staff might attain a higher level of assurance by being personally "known" by a teacher or school staff member. Again, more discussion of this process needs to take place. Also, use of the eduPerson Assurance attribute my need clarification or be re-defined in the case of K12 use.
 Parent Access (IdP? NCID?) - Integration of parents into the realm of educational applications providing services is a very challenging task. Today some of the School
Districts elect to maintain credentials for parents/guardians which allow parents to access the school record information of their child. Assessing and proofing the identity of a guardian can only be done by the school. Based on existing solutions such as NCID and other authentication mechanisms at the State level, it will be very difficult to maintain parent/guardian information and to use such services as the authentication services.
NCTrust has such a capability because guardian and student information are associated at the school/level.
 Funding issues - Funding a shared service such as NCTrust requires the creation of a program on the state-level. Successful statewide initiatives normally go through an appropriation process at the State Legislature. It is likely that NCTrust will need to work
Page 21 of 36

with InCommon to develop an acceptable K12 / InCommon pricing model. For purposes of the pilot, it has been extremely beneficial to have the two designated LEAs in
InCommon. However, we recognize that this would quickly become expensive, given the 115 LEAs in our state. It should also be noted that some states have far more LEAs than North Carolina. We are aware that InCommon is developing a tool to allow for a single Org to delegate administration of IdPs and SPs to secondary contacts of their choosing. We hope this will end up being a supportive context for NCTrust, as well as other large entities/federations/universities that need some kind of delegated administration tool for their metadata management.
 Possible source(s) of funding (RTTT, state of NC, others?) - There is currently an effort under way to secure four years of funding for federation of all NC K-12s via a federal stimulus project titled Race to the Top. The outcome of the application will be known in April 2010. Additionally, it should be noted that there is an innovation process currently being proposed to the North Carolina Education Cabinet. If adopted, this would allow a pathway for projects such as NCTrust to, when deemed relevant, be adopted and funded for various needs across the NC K-20 public education environment. This innovation cycle should be further explored as an opportunity for funding and adoption of the NCTrust expansion.
The purpose of NCTrust (to prototype a state K-20 identity federation) has been met. The next steps (as mentioned in the preceding section) include making decisions regarding key questions of infrastructure, funding and support. Moving forward will be a slow, gradual process of adding participants (both IdPs and SPs) through the current process until the above issues have been resolved. It is critical that the number of IdPs and SPs grows steadily, as the true value of
NCTrust is directly related to the percentage of K-20 organizations participating.
In closing, the FIM Task Force reiterates some of the key questions that will determine the future direction and success of NCTrust, along with proposed answers for which we seek CSWG approval.
Who will "own" NCTrust?
The stakeholders of the NCTrust include:

Public Universities

Community College System and Associated Community Colleges

NC Department of Public Instruction and associated LEAs
Page 22 of 36


Independent Colleges and Universities

ITS

MCNC

Libraries, etc.

Service Providers
Who will govern NCTrust?
A governance body for NCTrust (to be referred to as the FIM Governance Task Force) will be appointed by April 15, 2010 and assemble for the first time no later than May 15, 2010.
Governance would be assumed by the FIM Governance Task Force, in a reorganized fashion of the FIM Task Force, such that it would be comprised of the following organizations in the following numbers:
 Public Universities – 1
 UNC-GA - 1
 NC Community College System – 1


Community College - 1
 NC Department of Public Instruction (also representing LEAs) - 2
Independent Colleges and Universities - 1


ITS - 1
 MCNC - 1
Libraries, etc. - 1
 Service Providers – 1
Governance costs would be paid for via the contributions of the members (via their time) and convened via the MCNC advisory and governance structure.
How will NCTrust be paid for?
There are four primary components that would need to be considered when factoring all costs of
NCTrust.
1. NCTrust Administrative Costs
These costs include:

Management of NCTrust metadata creation/signing/creation process

Hosting of a WAYF for optional use by NCTrust Federation Members

Limited technical consulting to NCTrust participants

Outreach
These costs would be assumed by MCNC as part of a more comprehensive set of services that is extended to all NCREN customers (pending final approval by MCNC).
Page 23 of 36

2. IdP and SP Hosting
This could be done by the member organization, which would assume these costs. Alternately, this could be done on a for fee basis by MCNC, with a service which would include:

Setup of the host in a secure, redundant server environment

Technical support for setup and maintenance (incorporated into the cost of setup)

Additional support on a for fee basis
A pricing model would be created that would recover the costs of this service.
3. NCTrust Membership and Identity Proofing
As stated earlier, the preferred model for this has not yet been determined, and may vary from community to community (K-12, community colleges, etc.). The expectation would be that each member or community of members would pay for this element of the service, via InCommon fees, etc.
4. Research and Development
Work will be required to ensure that the members of NCTrust can adapt to the needs created by:

Additional IdPs

Additional SPs

Developments in Identity Management

Security Requirements
This work will be done by a subgroup of the FIM Governance Task Force, called the FIM
Technical Services Task Force, which will report to the FIM Governance Task Force. The group would help to coordinate and prioritize the work being done by member organizations. Funding options will be recommended the FIM Governance Task Force and decided by parent organizations (UNC GA, Community College System, DPI, MCNC, etc.) with recognition that there is an opportunity to pursue collective, ongoing funding from the state legislature to serve all relevant public organizations, with opportunities for relevant independent organizations to
“buy in” to the trust.
Who hosts NCTrust? Who administrates it?

MCNC could take a leadership role on the technical infrastructure o NCTrust metadata creation and distribution process o An ideal location to host IDPs o SP hosting, when desired o Technical consulting to NCTrust participants

Hosting of NCTrust is dependent upon a number of yet unanswered questions: o What trust infrastructure will be used?
Page 24 of 36


We suggest InCommon, subject to favorable pricing terms

Each and every participating organization has a responsibility (and level of accountability) for maintaining their role in the trust. o What IdP solution will be used (many options)?

For K-12 if at all possible, we suggest a single state-wide K-12 IdP (DPIsponsored, MCNC-hosted?). Additional information will be required to finalize on the optimal solution to meet K-12 needs.

Otherwise, our suggestion is for each organization to have its own IdP

Regional IdPs would be another alternative to consider.
Who determines policy and standards?

Policy and standards will most likely be proposed by the FIM Governance Task Force.
Authorization for Policy and Standards implementation will come from the MCNC advisory and governance structure.
Who proposes and approves enhancements?

Requests for enhancements can come from any of the participants, service providers or stakeholders

Enhancements can be discussed and proposed by the FIM Technical Services Task Force to the FIM Governance Task Force.
Thank you!
The Federated Identity Management Task Force (past and present members - alphabetically):
Kristin Antelman - North Carolina State University
John Baines, North Carolina State University
Brian Bouterse, The William and Ida Friday Institute for Educational Innovation
Lee Cummings, Rockingham County Schools
Joel Dunn, University of North Carolina at Greensboro
Jason Godfrey, North Carolina Community College System
Gonzalo Guzman, MCNC
William Haney, ITS
Susan Hensley, University of North Carolina at Greensboro
Steven Hopper, University of North Carolina General Administration
Paul Hudy, University of North Carolina General Administration
Klara Jelinkova, Duke University
Susan Klein, North Carolina State University
Page 25 of 36

Oscar Knight, Appalachian State University
Darryl McGraw, Wake Technical Community College
Pam McKirdy, Greensboro College
Tim Miller, Wake Forest University
Grant Pair, State Library of North Carolina
Shilen Patel, Duke University
Tim Poe, MCNC
Bill Randall, North Carolina Community College System
Brent Roberts, North Carolina Information Technology Services
Tim Rogers, NC Live
Butch Rooney, Davie County Schools
Mark Scheible (Co-Chair), NC State University
Chris Summers, Wake Forest University Baptist Medical Center
Jan Tax, UNC Chapel Hill
Steve Thorpe, MCNC
Mike Veckenstedt (Co-Chair), North Carolina Department of Public Instruction
Jon Wilmesherr, Mayland Community College
Page 26 of 36

One way to categorize IdP hosting models would be according to:
1) Who does the systems administration?
2) Where does the IdP actually run?
Systems administration could be handled locally by member of the institution the IdP is representing versus by a central administrative body that manages it on behalf of the institution.
The physical and/or virtual infrastructure upon which the Shibboleth IdP runs could also live locally at the institution or be hosted remotely at some central location. Thus there are four categorizations using these two metrics, of which three are represented within today's NCTrust
Federation:
1.
Locally Managed (hosted and managed locally at the IdP's institution). Current examples within NCTrust Federation include UNC, NC State, Duke University, and
MCNC IdPs. Locally managed IdPs appear to be an excellent choice for institutions with significant computing infrastructure, especially where there are many services that would be protected by Shibboleth. So for example NC State University, UNC Chapel Hill,
Duke University, and MCNC would fit this category. The steps required to administer an
IdP system tend to be easier to manage for such large-scale institutions.
2.
Co Location (hosted centrally (e.g. at MCNC) but managed remotely by+ the IdP's institution) No current examples in NCTrust. Co Location is an attractive option for a skilled systems administrator who would be comfortable maintaining and IdP but simply desires a very reliable, always-on 24x7 hosting environment living in a remote data center. The data center itself provides only the hosting environment and connectivity, while the administrator is responsible for all system maintenance, backups, etc.
Page 27 of 36

3.
Managed Hosting (hosted and managed centrally (e.g. at MCNC)). MCNC has some experience with this in terms of development/test versions of the IdPs for Rockingham
County Schools, Wake Technical Community College, and Davie County Schools.
Managed Hosting is a great option for institutions without a strong knowledge base in
Shibboleth, Linux, XML, and the other related technologies mentioned earlier in this document. Here the institution would coordinate with the hosting data center on appropriate Active Directory or LDAP information to get the IdP started, and the data center would take on the responsibility to install, maintain, update, and monitor the IdP itself.
4.
Remotely Managed (hosted locally at an institution and managed remotely (e.g. by
MCNC)). Rockingham County Schools, Davie County Schools, Wake Technical
Community College, Department of Public Instruction IdPs are in this category today.
This scenario has been quite useful during our initial NCTrust Federation activities, in that it allowed simplified setup of an institution's IdP. MCNC developed a test version of an IdP within a VMware virtual machine for these organizations, which allowed sufficient time in advance to work out any problems. Then once it was working the VM was delivered to the hosting institution and easily installed within a VMware Player environment. In most of these scenarios however, the host institution was a Windows shop without much experience administering the Linux OS used within the guest VM appliance. Essentially this scenario is the reverse of the Co Location scenario - the IdP's institution hosts the infrastructure while the remote organization does the actual administration.
All four of these scenarios have their merits, though among them we would generally recommend choosing Managed Hosting for the majority of NCTrust member institutions, and for a few technically deep organizations Locally Managed is a viable option - especially those hosting their own services.
Managed Hosting provides economies of scale with regards to human effort, technology learning curve, installation, security, maintenance, monitoring, redundancy, etc. With appropriate installation, hosting, and monitoring systems in place it can become a relatively straightforward process to add additional IdPs into the mix. Generally speaking the deltas between one IdP and another are broken down into only the areas that would differ among institutions: the Look-And-
Feel issues of the login page, Active Directory / LDAP configuration issues, organizational policy issues, and depending on the size of the institution there may be differing system requirements in terms of CPU, memory, clustering etc. It is certainly quite possible within a managed hosting environment where several hundred IdPs could be hosted as Virtual Machines within a small number of high-capacity physical hosts.
With a Managed Hosting IdP scenario, the Federated Id Management Task Force recommends using at least 2 identically configured (possibly virtual) machines at all times , ideally in separate physical locations, behind a monitoring infrastructure that can automatically detect failures in one of the VMs and then immediately make adjustments to direct DNS and associated IP traffic to the correctly functioning IdP. In this way reliability is significantly
Page 28 of 36

improved. On example of such technology is the Cisco ACE GSS 4400 Series
14
that is being used around MCNC's IdP.
Another recommendation is to start out with a small memory/disk/CPU footprint for the
IdP, with the realization that depending on usage experience it may be necessary later to increase that footprint to accommodate the additional use.
 Working with MCNC SysOps staff to develop costs associated with SW/HW/support infrastructure if go with centralized service hosted at MCNC or another external provider. (this is currently in progress) All figures are initial ballpark estimates and will be changing . Costs will include:
1.
A primary "small footprint" Virtual Machine. Includes prorated share of underlying physical HW such as CPU, RAM, disk).
2.
(Optional) A secondary "small footprint" Virtual Machine living in separate physical hardware (ideally in a separate location). This is recommended for reliability purposes.
3.
Image storage
4.
Network connectivity / data transfer
5.
SSL Certificate for apache web server:
6.
Shibboleth IdP installation & maintenance. Includes a.
OS Installation b.
Periodic OS updates c.
Shibboleth IdP installation d.
Interaction with IdP’s institution's systems administration staff on AD/LDAP and policy configuration issues. e.
24x7 monitoring and alerts f.
Automated failover as needed using GSS-initiated DNS modifications (if secondary backup machine is utilized). Recommended for reliability purposes. g.
Access to MCNC helpdesk and support staff as needed in case of problems with the IdP's proper functioning h.
Assistance interacting with InCommon
7.
Plus don't forget InCommon membership fee (cost will vary depending on institution size/type)
See http://www.incommonfederation.org/fees2010.html
for more information.
8.
Initial ballpark estimate for IdPs for 115 LEAs plus 100 charter schools would be approximately $2.95M
9.
NOTE: The $2.95M estimate covers InCommon membership, plus IdP setup and hosting as noted above. PRESUMABLY WE MAY WISH TO ADD SOME
14 http://www.cisco.com/en/US/products/hw/contnetw/ps4162/
Page 29 of 36

ADDITIONAL FUNDING FOR EXAMPLE FOR HIGHER-ED and/or DPI NEEDS
THAT ARE NOT COVERED THEREIN!
10.
See attached 2009.EOY.FIM.Scratchpad.xls
for more details.
Page 30 of 36

The NCTrust federation architecture is essentially a workflow that produces then consumes
Shibboleth metadata. The NCTrust metadata includes web addresses and public credential information associated with each of the Shibboleth entities (SPs and IdPs) in the federation. It allows entities to authenticate communications with each other.
The InCommon federation is the technical and (more importantly) the legal trust infrastructure upon which the NCTrust federation is built. Each NCTrust participant is required to join
NCTrust through signing the NCTrust MOU, and to join InCommon. These memberships allow submission of metadata for their Identity Provider and Service Provider(s) if applicable. By
Page 31 of 36

virtue of being an InCommon participant, that alone would allow a member's IdP and SP(s) to interact with potentially hundreds of other InCommon shibboleth entities.
The NCTrust metadata process provides a subset of the InCommon metadata to enable a baseline trust among those closely cooperating NCTrust entities. After an NCTrust entity's metadata has been published by InCommon and per agreement of the NCTrust governing body the new entity's name is added to the properties input file read by the NCTrust metadata - thus enabling the entity to be published as part of NCTrust.
The NCTrust "subset" InCommon federation establishes a different (higher?) confidence level among the NCTrust participants, based primarily on familiarity. The NCTrust metadata subset enables straightforward configuration of NCTrust Shibboleth entities, so they can easily trust each other and also automatically be updated with changes to the NCTrust metadata. None of these are requirements per se; just options member organizations can choose to take advantage of. See the attached diagram ("NCTrust Federation Metadata Process") for a depiction of the
NCTrust metadata workflow.
NCTrust WAYF
As a courtesy to NCTrust participants, MCNC also hosts a "Where Are You From", or WAYF.
This WAYF performs the function of Shibboleth Discovery Service, allowing a user logging onto a Service Provider to choose their home institution. The NCTrust Federation portion of the
WAYF displays a list of Identity Providers from the federation. The idea is for the Service
Page 32 of 36

Provider to be configured to send new users to the WAYF, then the WAYF the user goes to their home institution's Identity Provider where they enter their home login / password. Assuming successful login, the user's browser directs them back to the Service Provider where they'll now be in a logged-in state. It is possible and in many cases desirable for individual Shibboleth
Service Providers to host their own WAYF directly with the SP itself, in order to allow a custom look-and-feel as well as to enable only specific IdPs to authenticate. However this WAYF hosted has proven to be a great convenience for NCTrust participants, therefore MCNC has maintained it in operation.
As of the time of this writing (December 2009) all of the pieces described above are currently operational out of MCNC, with the exception of the NCTrust metadata signing process that is being completed now. The intent is to mature this metadata maintenance process sufficiently so it could be handed off to a production system (rather than a pilot system), that would be operated by MCNC's Systems Operations staff.
Security Issues
It is critical to be cognizant of security issues related to administration of Shibboleth technologies, due to the importance of the online identities shared using shibboleth. It’s imperative to ensure against compromise of any of the identities in the Federation, since that could allow electronic impersonation. Therefore security is practiced at multiple levels wherever practical. Some examples:




User passwords have a maximum duration before they must be reset
 Operating System updates are periodically installed
The Shibboleth IdP, SP, and WAYF releases are kept up to date
 Hardware and software firewalls are put in place to minimize open ports and limit access ranges as appropriate
Metadata signing is done using password-protected private credentials
For systems maintained by MCNC's automated configuration management system,
 configuration, software updates, and system monitoring are handled consistently on a
24x7 basis
System logging is extensively utilized for troubleshooting and forensic purposes
At present, MCNC is performing automated 24/7 monitoring of several shibboleth-related entities. This monitoring alerts MCNC staff in case of interruptions in service. For example, current monitoring includes checks for ping responses, functioning apache web server, functioning Tomcat web application container, running Shibboleth Identity provider web application, non-expired SSL certs behind ldap and httpd services encrypted over SSL.
Page 33 of 36

A goal for 2010 is to improve the monitoring capabilities to include end-to-end checks simulating a user's successful access of a Shibbolized service. Such tests the following checks, with monitoring for appropriate responses from the various entities:
1.
Visit login section of Service Provider
2.
Confirm successful redirection to WAYF
3.
Choose Identity Provider at the WAYF
4.
Confirm successful redirection to Identity Provider
5.
Login as a test user at the Identity Provider
6.
Confirm successful redirection back to the Service Provider
7.
Confirm logged in state at the Service Provider
These higher level tests would not only confirm successful SP, WAYF, and IdP operations, but would also implicitly confirm continued operation of the back-end login systems (e.g. Active
Directory / LDAP) and the properly functioning NCTrust metadata interoperability.
Another point of discussion for future NCTrust Federation activities would be communication channels. To date the FIM Task Force has primarily used two channels: the fim@mcnc.org email list and the confluence
15
wiki. A likely consideration would be setting up an additional channel such as a more public-facing web site. It is recommended this be an item for discussion by the future governing body of the NCTrust federation.
Moving the NCTrust Federation “Into Production”
Assuming a suitable budget and governance model can be identified that works for all members of the federation, it is anticipated that MCNC would be willing to assist in many of the operational aspects of a future, production version of the NCTrust federation. Some of those aspects are:


Operation of the NCTrust metadata sub-setting and distribution process
 Consultation on Identity Provider, Service Provider, and WAYF options
OS installation
 IdP installation
 Periodic OS updates
 Interaction with IdP's institution's systems administration staff on AD/LDAP and policy configuration issues.
 24x7 monitoring and alerts
 Automated failover as needed using GSS-initiated DNS modifications (if secondary backup machine is utilized). Recommended for reliability purposes.
15 https://edspace.mcnc.org/confluence/display/FIM/confluence
Page 34 of 36



Access to MCNC helpdesk and support staff (support@mcnc.org/ 919-248-4111) as needed in case of problems with the IdP's proper functioning.
Assistance interacting with InCommon
NCTrust Shibboleth Technical References
This 16 confluence reference page has links to many other useful documents including:
 Notes on Getting Shibboleth Service Provider metadata published by InCommon by
Steve Thorpe
 Examples of “white-listing” within an Shibboleth SP's and local WAYFs by Steve

Thorpe
 Instructions on connecting your NCTrust SP to the NCTrust WAYF by Steve Thorpe
MCNC shibboleth-idp test installation notes by Steve Thorpe


MCNC's test WAYF setup notes by Steve Thorpe
 NCSU IdP Configuration Notes by Charles Brabec
Notes on setting up NCSU's VCL SP within NCTrust Federation by Josh Thompson
 2/25/2009 NCTrust Techie Q&A Notes by Steve Thorpe
 attribute-resolver.xml example for LDAP/AD configurations used during UNC

Federation Deployments of IdP configurations, by Steven Hopper login.config example for LDAP/AD configurations used during UNC Federation
Deployments of IdP configurations, by Steven Hopper


NCTrust VM Appliance README by Steve Thorpe
Outline of General IdP steps an NCTrust member and MCNC could follow by Steve

Thorpe
 Overview of various config files on the IdP by Steve Thorpe
Notes on getting an Apache cert signed by GoDaddy by Steve Thorpe
 Federated Logout Info by Steven Hopper
16 https://edspace.mcnc.org/confluence/display/FIM/Shibboleth+Technical+References
Page 35 of 36

 Local Education Agencies -LEAs (School Districts) - 115


Public School Student Enrollment - 1,452,000 students; 143,000 Faculty & Staff
 Charter School Enrollment - 29,000 students
North Carolina Community College System - 58 Colleges; 236,000 Students


University of North Carolina System - 16 Universities; 146,000 students
 36 non-profit private colleges with 80,000 students (North Carolina Independent Colleges and Universities http://www.ncicu.org/fast_facts.html
)
About 2,000,000 faculty, staff and students are active in North Carolina's k-20 education system.
Page 36 of 36