Web Applications as Shibboleth Service Providers within
the NCTrust Federation
by Steve Thorpe1
Systems Programmer Analyst
MCNC
Version 1.0
February 1, 2011
thorpe@mcnc.org
Introduction ...............................................................................................................2
Service Providers – NCTrust Federation Onboarding Requirements and Process ..........3
Shibboleth ....................................................................................................................................................................3
Discovery Process.....................................................................................................................................................3
User Attributes ..........................................................................................................................................................4
NCTrust Federation is a Subset of the InCommon Federation ..............................................................4
InCommon for Service Providers .......................................................................................................................5
What is InCommon? .................................................................................................................................................... 5
Why InCommon? .......................................................................................................................................................... 5
More Details on the InCommon Federation .................................................................................................... 6
Configuring Shibboleth Service Provider .......................................................................................................8
The author wishes to thank Jon Wilmesherr, Tim Poe, the NCTrust Federated ID Management Task Force, the
InCommon Federation, and the UNC Identity Federation for their valuable contributions to this document.
1
Web Applications as Shibboleth Service Providers within the NCTrust Federation
Introduction
Web-based application may be deployed using Single Sign On (SSO) architecture
such as the Shibboleth middleware provides, that utilizes the Security Assertion
Markup Language (SAML) protocol. This technology provides scalability and
security with regards to user accounts and applications, by cleanly separating
between management of the application (Service Provider, or SP) and management
of accounts of applications users, which are maintained at their home institution
behind an Identity Provider (IdP). SAML assertions allow appropriate
authentication and authorization decisions to be made at the user’s home institution
then at application, based on a shared trust set up between the application provider
and home institutions of the users. Furthermore, using the Shibboleth/SAML SSO
technologies, it is straightforward to enable thousands of users from many different
administrative domains to all utilize the same web application. All these benefits
are realized without giving up control or ownership at either the application or the
user/institution side.
Figure 1: Shibboleth/SAML Single Sign On Architecture
-2-
Web Applications as Shibboleth Service Providers within the NCTrust Federation
MCNC, in cooperation with many organizations throughout North Carolina’s K-12
research and education community, has organized a federation of organizations and
applications called NCTrust. We encourage web application providers to enable
their applications with Shibboleth technologies and, where appropriate, to become
part of the NCTrust Federation.
Web application providers (also known as Service Providers, or SPs) wishing to
deploy within the NCTrust Federation need to understand several points: SAMLbased Shibboleth software, the InCommon trust federation, the Shibboleth
Discovery process, Shibboleth user attributes, and finally the mechanics of
Shibboleth software installation and configuration. In this document we highlight a
few of the key ideas, along with references to further information.
Service Providers – NCTrust Federation Onboarding
Requirements and Process
Web-based application service providers wishing to deploy within the NCTrust
Federation need to understand several points: SAML-based Shibboleth software,
the InCommon trust federation, the Shibboleth Discovery process, Shibboleth user
attributes, and finally the mechanics of Shibboleth software installation and
configuration. The installation and configuration aspects are covered in an
appendix to this document, while we discuss the other aspects here within this
section.
Shibboleth
The NCTrust Federation employs SAML (Security Assertion Markup Language)
technologies to enable cross-institutional access to web-based applications. In
particular, Shibboleth is usually used. Shibboleth is an open-source implementation
of SAML that is in wide use among educational, research, government, and
commercial entities.
Discovery Process
When a user of an NCTrust participating service (Service Provider, or SP) would like
to login with Shibboleth after accessing a web-based service directly, the user's
home Identity Provider (IdP) must be identified. That process is known as IdP
discovery.
If the user is coming from a source that knows the user's home IdP by definition,
that source can send the user directly to the resource, either having already
authenticated for that SP, or having preselected the IdP for the user. This can be
done on campus portals, URL paths specific to users from one customer, or on
library pages, for example. Generally speaking, services within the NCTrust
federation can’t be configured so simply, however, as the user’s home IdP is not
known up front.
-3-
Web Applications as Shibboleth Service Providers within the NCTrust Federation
Service Providers within NCTrust must support use of a Discovery Service (DS), a
service that presents a standard interface for users to select their IdP from. A DS
presents in some form, highly customizable, a set of IdP's from which the user can
choose. After the user makes a selection, the user is presented with a login page on
their organization’s IdP, and then after authentication they are directed to the
service where they are given authorized access. More information about Shibboleth
Discovery Service options can be found at the link
https://spaces.internet2.edu/display/SHIB2/IdPDiscovery.
User Attributes
Finally, depending on the SP requirements, user attributes will likely need to be
consumed by SPs as enabled by the underlying SAML protocol employed by
Shibboleth.
It is essential that NCTrust participants support and use common definitions for
certain basic identity attributes. These attributes might include a unique identifier
(traditionally a "user ID") or other information such as organizational affiliation,
status, email address, etc. (this information is also called "claims" in some products).
In many scenarios identity attributes are very useful to Service Providers for access
control, personalization, and other purposes.
The formal specification of typical identity management attributes for use within
NCTrust consists of the eduPerson attributes that are used by InCommon. From
time to time and on a case-by-case basis additional elements may be added, but the
definition and meaning of existing attributes is not expected to change. A discussion
of the InCommon attributes can be found at
http://www.incommonfederation.org/attributes.html.
NCTrust Federation is a Subset of the InCommon Federation
The NCTrust federation utilizes processes and protocols of the InCommon
Federation to identify and authenticate members of its community to web-based
applications and contracted service providers. It is required that any web-based
applications and services proposed for multi-campus use also utilize these
processes and protocols to obtain end-user identity information.
Web-based application service providers may need to become a member of the
InCommon Federation. If the service is hosted on a DNS address controlled by a
member of InCommon, the vendor providing the hosted software will not
necessarily need to join InCommon. However, if the service is hosted on DNS
address(s) controlled by the vendor, InCommon membership will be a prerequisite.
Further information about InCommon is available at
http://www.incommonfederation.org.
Once an SP is deployed, it can be registered as an entity within the InCommon
federation’s metadata2. From there, the NCTrust federation metadata can replicate
2
http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml
-4-
Web Applications as Shibboleth Service Providers within the NCTrust Federation
the service’s metadata within the NCTrust metadata3. At that point, properly
configured Identity Providers (IdPs) within the NCTrust federation will recognize
that assertions presented by the SP are indeed from that SP. (Whether to authorize
any of these assertions is another matter – that is entirely up to the administrators
of the service).
InCommon for Service Providers4
What is InCommon?
InCommon provides a way for you to save money, to save time and effort every time
you add a new client or customer, and to get out of the business of managing user
credentials.
You focus on your core business and let your school, college and university clients
manage their user accounts. And you do it in a way that scales - eliminating custom
integration work because InCommon participants follow standard practices.
Users enjoy single sign-on convenience and privacy, your college and university
clients maintain the credentials database, and you see dramatically reduced help
desk expenses and account provisioning expenses.
InCommon provides the policy and technical framework that makes all of this
possible.
Why InCommon?
Cost Savings





No more account provisioning
Significantly reduced help desk calls
Eliminate custom integration work with clients
Focus on your core business rather than identity management
Adding new clients and customers is a snap
Standard Practices




Policy is standard throughout the federation
Technology is standard throughout the federation, centered on SAML
Well-defined attributes make interaction consistent with all other participants
Integration work with new customers is greatly reduced
Security and Privacy

3
Your college or university customer maintains the identity directory and
controls security and privacy
https://shib.mcnc.org/NCTrust-metadata.xml
4 Much of this content was borrowed from http://www.incommon.org/partners/
-5-
Web Applications as Shibboleth Service Providers within the NCTrust Federation


Fewer data spills through the use of attributes
Your customer does the authentication; you do the authorization
Simplified Operations





Policy and technology standards means federation scales!
Adding a customer takes very little time
Single sign-on provides a simplified user experience
East of set-up saves time and money
You eliminate the need to provision accounts
More Details on the InCommon Federation
The mission of the InCommon Federation5 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 enables production-level end-user access to a wide variety of protected
resources. As of April 2010, InCommon supported a growing community of more
than 4.5 million end-users at 240 different educational, research, and commercial
organizations6 – including two North Carolina LEAs (Rockingham County Schools
and Davie County Schools).
One of the important InCommon benefits is the framework they've designed for
obligations and responsibilities among the many legally distinct entities that are in
the federation. That InCommon framework puts all members on the same playing
field, and obviates the need for bilateral agreements between every pair of
federation members. In our opinion, this is a significant benefit, and probably it’s a
necessary benefit because each LEA is a distinct legal entity, not to mention the
many community colleges, independent colleges, state university system, MCNC,
commercial entities, government labs, etc. that are also part of InCommon and can
provide shared services. All of these are distinct legal entities and the InCommon
framework provides a convenient trust mechanism for them to share services and
identities. Of course, each entity always maintains the ability but certainly not an
obligation to collaborate with any of the other members. To better understand the
legal framework, please see the InCommon Participation Agreement7.
A fundamental expectation of InCommon Participants is that they provide
authoritative and accurate attribute assertions to other Participants, and that
5 InCommon Federation: http://www.incommonfederation.org
6 InCommon Participants: http://www.incommonfederation.org/participants/
7 InCommon Participation Agreement:
http://www.incommonfederation.org/docs/policies/participationagreement.pdf
-6-
Web Applications as Shibboleth Service Providers within the NCTrust Federation
Participants receiving an attribute assertion protect it and respect privacy
constraints placed on it by the Federation or the source of that information. In
furtherance of this goal, InCommon requires that each Participant make available to
other Participants certain basic information about any identity management system,
including the identity attributes that are supported, or resource access management
system registered for use within the Federation.
Two criteria for trustworthy attribute assertions by Identity Providers are: (1) that
the identity management system fall under the purview of the organization's
executive or business management, and (2) the system for issuing end-user
credentials (e.g., PKI certificates, userids/passwords, Kerberos principals, etc.)
specifically have in place appropriate risk management measures (e.g.,
authentication and authorization standards, security practices, risk assessment,
change management controls, audit trails, etc.).
InCommon expects that Service Providers who receive attribute assertions from
another Participant respect the other Participant's policies, rules, and standards
regarding the protection and use of that data. Furthermore, such information should
be used only for the purposes for which it was provided. InCommon strongly
discourages the sharing of that data with third parties, or aggregation of it for
marketing purposes without the explicit permission of the identity information
providing Participant.
InCommon requires Participants to make available to all other Participants answers
to the questions asked in the Participant Operational Practices8 document (see
footnote), which detail their related internal practices and procedures.
The University of North Carolina system runs another Shibboleth/SAML2 based
federation known as the UNC Identity Federation9. It also provides the SAML 2.0
metadata definition and operational infrastructure needed to enable federated
service delivery, in this case among the constituent members of the University of
North Carolina. In short, the Federation encompasses both the policy and technical
infrastructure needed to establish trust, security, and cooperation between its
members. Participants include all 17 constituent institutions of UNC (16
universities, 1 high school) along with the Center for Public Television (UNC-TV),
and MCNC.
As compared to the InCommon Federation, the UNC Identity Federation is fortunate
to avoid the need for such a legal framework as provided by InCommon (plus they
save a few $ to boot). The reason is they are all considered the part of a *single*
legal entity - the University of North Carolina. And therefore the UNC-GA can run
the whole thing.... this would be comparable to us sharing services among different
departments within MCNC. Because we're all within one legal entity, there isn't the
same need for an inter-organizational agreement that is probably needed among the
InCommon Participant Operational Practices:
http://www.incommonfederation.org/docs/policies/incommonpop_20080208.html
9 UNC Identity Federation http://federation.northcarolina.edu/
8
-7-
Web Applications as Shibboleth Service Providers within the NCTrust Federation
LEAs and between LEAs and non-LEA organizations.
Configuring Shibboleth Service Provider
The Shibboleth Service Provider (SP) installation and configuration varies
depending on whether the target is Linux, Mac OS X, Solaris, Windows, or Java
Servlets. The official source of documentation can be found in links from the “Native
Service Provider (SP)” section of
https://spaces.internet2.edu/display/SHIB2/Installation.
Other useful references on the NCTrust Federation and related technical
information can be found at the following two links, respectively:
https://edspace.mcnc.org/confluence/display/FIM/Home++Federated+Identity+Management+TF
https://edspace.mcnc.org/confluence/display/FIM/Shibboleth+Technical+Referenc
es
-8-