Federated Identity Management Task Force Recommendations for Federated

raspgiantsneckServers

Dec 9, 2013 (3 years and 10 months ago)

407 views







Federated Identity Management Task
Force Recommendations for Federated
I
dentity

in the State of North Carolina
for 2010 and Beyond



Based on the outcomes of the NCTrust Pilot Federation




January 2010


Authors/Editors:


Mark Scheible, NC State Univ
ersity

Steve Thorpe, MCNC

Mike Veckenstedt, North Carolina Department of Public Instruction

Tim Poe, MCNC

Susan Johnson,
Charlotte
-
Mecklenburg Schools


Page
2

of
36



Table of Contents


Table of Contents

................................
................................
................................
................................
..........

2

EXECUTIVE SUMMARY

................................
................................
................................
................................
..

3

PILOT OVERVIEW

................................
................................
................................
................................
..........

5

INTRODUCTION

................................
................................
................................
................................
.........

5

SCOPE OF PROJECT (NCTrust)

................................
................................
................................
...................

6

PILOT PLANNING

................................
................................
................................
................................
.......

7

DECISION PROCESS (InCommon vs. Stan
dalone 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
3

of
36


EXECUTIVE SUMMARY

In November, 2007 a group of ind
ividuals 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 c
ases)



Provide

onlin
e 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 p
roject to identify what challenges would be encountered in a K
-
20
federation for the state

(i
ncluding 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 fede
ration. 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 pilo
t
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 sta
te

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
4

of
36


training (ShibFests) to the participants of the pilot, we found th
at 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
possibl
y 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 an
d 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
5

of
36


PILOT OVERVIEW

INTRODUCTION

North Carolina is fortunate to ha
ve 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 supp
ort 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
-
institu
tional purchases.

One of the cornerstones of a K
-
20
technology platform is the implementation of
F
ederated
I
dentity
M
anagement.


Federated I
dentity

Management infrastructure
based on the open
-
source Shibboleth
1

software
allows multiple organizations (unive
rsities, 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
easi
ly

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 organ
ization 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 Shibbol
eth components.





1

http://shibboleth.internet2.edu/

Page
6

of
36



SCOPE OF PROJECT (NCTrust)

The
NCTrust

pilot was developed to span K
-
20 education in North Carolina. From an
I
dentity
P
rovider

(IdP)

perspective, this includes:



K
-
12 Public Schools


o

Davie County Schools

o

Rockingham County Schools



Communit
y Colleges


o

Central Piedmont Community College

o

Wake Tech
nical

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 an
d Education
Network

o

MCNC

Page
7

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 f
rom 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 relev
a
nt organizations



Educational vendors (Discovery Lea
rning, 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 Carolin
a 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.



PILOT PLANNING

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.


"
L
o
cal" experience
was available
in that the UNC
System had recently create
d

its own federation for shared resources, in particular an inter
-
institutional class registration application.


In this case the UNC System IT organization set up its
own standalone f
ederation, 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 mem
ber IdPs for the user to authenticate
against. The user selects their “home” organization and is redirected there to login.

Page
8

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

a
dministrative 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
explore
d

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 U
niversity of
T
exas

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 applicat
ion 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 t
he 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 wit
h 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 t
heir
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
9

of
36


first requirement was that ev
ery member of UCTrust had to join InCommon.


They opted to use
the existing federation

for convenience sake as InC
ommon

took care of all the federation
infrastructure and services.


They then built much more stringent requirements into UCTrust
around assur
ance 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
.


DECISION PROCESS (InComm
on vs.
Standalone Federation
)

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 pol
icy 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 I
dentity

management technology
6

include

En
d
-
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 th
e 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 be
nefits 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.o
rg/benefits.cfm

Page
10

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
ser
vice 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 var
iety 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 infras
tructure 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 tec
hnical 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 onli
ne
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 forma
tion 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 exe
cutive 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
documen
ted 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
11

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
par
ticipants; 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
: Po
licy
-
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.



Economi
es 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 do
cuments. 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 contr
ol 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 cos
t based resources. The results of which lead to a more consistent
accounting of which resources are actually being utilized and by whom.

In short, s
ince InCommon clearly meets these three key requirements we proceeded to utilize
them for the NCTrust Federa
tion'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
12

of
36




TRAINING (

ShibFests

)

In October 2008 then again in February 2009, MCNC hosted two
-
day hands
-
on Shibboleth
Training workshops.


Slides and lab materi
als 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 we
ll 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://edsp
ace.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 sa
id,
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.

SHARING OUR NCTrust

EXPERIENCES

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 NC
Trust 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 ass
igned 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 s
ite is
able to manage its own login / password information. This talk will provide a brief overview of
the ongoing
NCTrust

pilot project."

Page
13

of
36


Although very early in the pilot, it was the first public presentation of the vision for a statewide
identity federat
ion 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 t
he US.

Led by George

Laskaris of
NJe
dge
.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
incl
uding 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
Me
eting in Arlington,

VA. This took place in late
April
, 200
9
. 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 presentati
on.

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 Univ
ersity of California
-

UCTrust).


We then
explained

why
the Task Force

chose the UCTrust model
and
bas
ed 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 na
tional 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 pr
ovide 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 NJV
ID
: a Collaborative Portal for Statewide Video Access, which
discussed New Jersey's efforts at fede
rated 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.

CHALLENGES

As expected, several challenges

emerged

during the initial two
-
year NCTrust project.


In fact
these
anticipated
challenge
s 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
14

of
36


future I
dentity

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 organ
izational 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 technol
ogy
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 interac
t 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 partic
ipants to sign.


The MOU
12

outlined expected roles and



11

https://edspace.mcnc.org/confluence/display/FIM/Shibboleth+Technical+References

12

https://edspace.mcn
c.org/confluence/display/FIM/MOU+Signature+Status+Page


Page
15

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 a
uthorized institutional legal team and executives to approve and sign these
documents.


T
he cost aspect of InCo
m
mon membership ($750 startup fee plus $1000/year as of
2009) was
also
a
challenge

-

although these are not huge amounts, they weren't necessaril
y
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 fo
r the Services (SPs) and Identity
Providers (IdPs) did take some effort to get off the ground.


SP configuration is done on a case
-
by
-
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 fo
r that SP.


On an as
-
needed basi
s, 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 stil
l 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
exc
hange 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
part
icipants 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 wou
ld 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 Shibbolet
h 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
-
idp
-
appliance.readme.txt

Page
16

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.


SUCCESSES AND LESSONS LEARNED



VCL


The

Virtual Computing Lab

was well into its pr
oduction 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 wit
hout 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
take
n

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 ad
ded security
of
users

enter
ing

their credentials directly
in
to their

own

institutions' authentication
server
s instead of sending them to the VCL

site which then sent them to the correct
institution's server
.
(
Although passwords are always encrypted when t
hey are passed
a
round with LDAP, Shibboleth cut

out
the VCL

site as a
“middle
man
”.


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 wa
s 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 universitie
s 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
17

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 po
sitive experience with this VM.


For further information,
please see
https://edspace.mcnc.org/confluence/download/attachments/8258684/in
common
-
nctrust
-
idp
-
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 t
he 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 to
ol 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 Coun
ty 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.


MOVING FORWARD

OPPORTUNITIES, PEERS, and COLLABORATION

Opportunities moving forward would incl
ude 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
inclusi
ve

K
-
20 federatio
n.


We will be following up in future US Trust Federation
collaborative call
s

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 NJe
dge.net, Rutgers University,
William Patterson University, NJ Digital Highway and VALE New Jersey (Virtual Academic
Page
18

of
36


Library Environment). The University of Virginia’s Virtual Library Consortium did something
similar with their VIVA project (providing acce
ss 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.

NEW VENTURES

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 Caro
lina 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 federatio
n, 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
w
hich 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
manda
tes and requirements around student instruction, federal reporting, and
accountability standards (such as Carl D. Perkins Act). Specifically, CIMS will provide
for the development of sec
ure/non
-
secure test itembanks;
benchmark and online
assessment creatio
n, 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 growin
g number o
f

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 be
ing 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 curr
ently 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
19

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
consi
dered 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 a
nd/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

Successful implementation of the project to provide

the unique Identifier lookup

o

Internal support system e
stablished at NCDPI for smooth transition to ownership
of the application and pr
ocess at the end of the project

(Note:
The authentication o
f 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

Regional?

o

State wide?



Users from non
-
NCTrust

organizations

o

NC STEM users

o

Protect Network


DECISIONS, RECOMMENDATIONS, AND NEXT STEPS



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 imple
mentation 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
whi
le
simultaneously

protecting the identity of the student.


The suggested attributes would be
Page
20

of
36


the following (actually, the same attributes used or suggested by some of the
universities):

o

EPSA
-

EduPerson Scoped Affiliation (an attribute that indicates the a
ffiliation 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.

o

EPTID
-
EduPerson Target
ed 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 (benefi
cial 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 recog
nizable 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

o

Requirements

o

Certificate Authority

o

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 t
echnology
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 ne
w 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
21

of
36


possibility is t
hat 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 se
rvice 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 f
orward.



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 us
ually associated with

"level of assurance" an organization has that the user of the creden
tial 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 i
ssued 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
-
def
ined 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
District
s

elect to maintain credentials for parents/guardian
s 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 se
rvice 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
22

of
36


with InCommon to dev
elop an acceptable K12 / InC
ommon

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 en
d up be
ing a supportive context for NC
Trust, 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 year
s 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 a
n 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.


SUMMARY/CLOSING


The purpose of NCTrust (to prototype a state K
-
20 identity federation) has been met. The next
steps (as m
entioned 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 abo
ve 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 Asso
ciated
Community Colleges



NC Department of Public Instruction and associated LEAs

Page
23

of
36




Independent Colleges and Universities



ITS



MCNC



Libraries, etc.



Service Providers

Who will
govern NC
Trust?


A g
overnance

body for NC
Trust
(to be referred to as the FIM Gove
rnance Task Force)

will be
appointed by
April 15
, 2010 and

assemble for the first time no

later than
May

1
5
, 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 comprise
d 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



I
TS
-

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 pr
imary 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 Fede
ration 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
24

of
36


2. IdP and SP Hosti
ng

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 prefer
red 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 publ
ic 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 pro
cess

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
25

of
36




We suggest InCommon, subject to fa
vorable 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 sta
te
-
wide K
-
12 IdP (DPI
-
sponsored, 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 alternati
ve 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 pr
oposes and approves enhancements?



Requests for enhancements can come from any of the participants, service providers or
stakeholders



E
nhancements can be discussed and proposed by the
FIM Technical Services Task Force

to the
FIM Governance Task Force.




Th
ank 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 Edu
cational 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
26

of
36


Oscar Knight, Appalachian State Unive
rsity

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
27

of
36



Appendix A

Operational Aspects for NCTrust

Different models for IdP hosting:


One way to categorize IdP hosting mod
els would be according to
:

1) W
ho does the s
ystems administration?

2)

W
here does the IdP actually run?


Systems administration could be handled locally by member of the inst
itution the IdP is
representing versus

by a central administrative body that mana
ges 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. L
ocally 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 Univ
ersity, 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
28

of
36


3.

Managed Hosting

(hosted and managed centrally (e.g. at MCNC)). MCNC has some
experience with this in terms of d
evelopment/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 rela
ted 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 inst
all, 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, t
he 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 re
mote 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 organi
zations 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 ar
eas 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 te
rms 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 sc
enario, 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
29

of
36


improved.

On example of such technology is the Cisco ACE GSS 4400 Series
14

that is bein
g
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 addition
al 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
hardwa
re (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 ba
ckup 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
30

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
31

of
36


Appendix B

Documentation for current and proposed NCTrust





The NCTrust federation architecture is essentially a workflow that produces then consumes
Shibboleth metadata. The NCTrust metadata includes web addresses and public crede
ntial
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 infrast
ructure
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 Provide
r(s) if applicable.


By
Page
32

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 me
tadata to enable a baseline
trust among those closely cooperating NC
Trust

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 fi
le read by the NCTrust metadata
-

thus enabling
the entity to be p
ublished 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 m
ember 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 Y
ou 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 th
e federation.


The idea is for the Service
Page
33

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 c
ustom
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 ha
nded 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 im
portance 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 wherev
er
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 pl
ace 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 MC
NC 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
-
expire
d SSL certs behind ldap and httpd services encrypted over SSL.




Page
34

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 con
tinued 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 t
he 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 discuss
ion
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 b
e 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
35

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.



Assist
ance 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 “w
hite
-
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
36

of
36


Appendix C

North Carolina

Demographics



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.or
g/fast_facts.html
 )



About 2,000,000 faculty, staff and students are active in North Carolina's k
-
20 education
system.