Web Applications as Shibboleth Service Providers within the NCTrust Federation

yoinkscreechedInternet and Web Development

Nov 13, 2013 (3 years and 9 months ago)

526 views





Web Applications as Shibboleth Service Providers within
the NCTrust Federation

by Steve Thorpe
1

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




1

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.


Web Applications as Shibboleth Service Providers within the NCTrust Federation


-

2

-

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 account
s

and applications
, by cleanly separating
between management of the application (Service Provider, or SP) and
m
anagement
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 Architect
ure



Web Applications as Shibboleth Service Providers within the NCTrust Federation


-

3

-

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 applic
ations 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: SA
ML
-
based 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 ide
as, 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
-
b
ased 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
know
n

up front.


Web Applications as Shibboleth Service Providers within the NCTrust Federation


-

4

-

Service Providers within NCTr
ust 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 select
ion, 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 th
e 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 ena
bled 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, personalizat
ion, 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 a
dditional elements may be ad
de
d,
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.htm
l
.


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 provide
rs. 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
In
Common
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 ven
dor, 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 metadata
2
. From there, the NCTrust federation metadata can replicate



2

http://wayf.incommonfederation.org/InCommon/InCommon
-
metadata.xml



Web Applications as Shibboleth Service Providers within the NCTrust Federation


-

5

-

the service’s metadata within the NCTrust metadata
3
. 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 Providers
4

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 the
ir

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 dat
abase, 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 stan
dard 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



Your college or university customer maintains the i
dentity directory and
controls security and privacy




3

https://shib.mcnc.org/NCTrust
-
metadata.xml


4

Mu
ch of this content was borrowed from
http://www.incommon.org/partners/


Web Applications as Shibboleth Service Providers within the NCTrust Federation


-

6

-



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 cust
omer 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 Federation
5

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 tr
ust 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
r
esources. As of April 2010, InCommon supported a growing community of more
than 4.5 million end
-
users at 240 different educational, research, and commercial
organizations
6



including two North Carolina LEAs (Rockingham County Schools
and Davie County Sch
ools).

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, a
nd 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 col
leges, 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 convenien
t 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 InComm
on Participation Agreement
7
.

A fundamental expectation of InCommon Participants is that they provide
authoritative and accurate attribute assertions to other Participants, and that



5

InC
ommon Federation
:

http://www.incommonfederation.org

6

InCommon Participants: http://www.incommonfederation.org/participants/

7

I
nCommon Participation Agreement
:

http://www.incommonfederation.org/docs/policies/participationagreement.pdf


Web Applications as Shibboleth Service Providers within the NCTrust Federation


-

7

-

Participants receiving an attribute assertion protect it and respect privac
y
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,
includ
ing 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 t
he 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 Parti
cipant'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 Oper
ational Practices
8

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 Federation
9
. It also provides the SA
ML 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
infra
structure 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 t
o 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 Univ
ersity 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
-
orga
nizational agreement that is probably needed among the



8

InCommon Participa
n
t Operational Practices:
http
://www.incommonfederation.org/docs/policies/incommonpop_20080208.html

9

UNC Identity Federation http://federation.northcarolina.edu/


Web Applications as Shibboleth Service Providers within the NCTrust Federation


-

8

-

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 follo
wing 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