TIER: Trust and
Identity in Education
and Research
InCommon TAC Proposal: TIER-IAMaaS
Authors: Shelton Waggener / Steven Zoppi
Revision 1● February 9, 2016
This Draft Document Contains confidential proposal
of community work sponsored by internet2 member
institutions and developed in coordination with TIER
Charter Development participating representatives
from Internet2 member institutions.
This document is intended to facilitate discussion within the community of
Technology Architects, Campus Technology Leadership, and Functional
Identity Stewards within Higher Education, as well as anyone who finds
comfort in addressing the longer-term vision while keeping an eye on the
road directly in front of them…
The contents identify the central themes around which future materials will
be crafted for other audiences … such as the campus CIOs.
Internet2
6001 Shellmound Street
Suite 850
Emeryvillle, CA
94608
Tel: 510-858-0881
Last edited: 09 February 2016
Copyright © 2014 Internet2. All rights reserved.
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system,
or translated into any language, in any form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without prior written permission from Internet2.
All copyright, confidential information, patents, design rights and all other intellectual property rights
of whatsoever nature contained herein are and shall remain the sole and exclusive property of
Internet2. The information furnished herein is believed to be accurate and reliable.
However, no responsibility is assumed by Internet2 for its use, or for any infringements of patents or
other rights of third parties resulting from its use.
The Internet2 and its subsidiary project and organization names InCommon, Shibboleth, Grouper,
and CoManage, Internet2, InCommon, Shibboleth, Grouper, and CoManage, logo are trademarks or
registered trademarks of Internet2
All other trademarks are the property of their respective owners
THE STATE OF TIER
The State of TIER ........................................................................................................... 3
General Timeline To-Date ............................................................................................... 5
The State of Identity (as viewed by Internet2 and the NET+ Program) ........................ 6
Problem Statement ......................................................................................................... 8
Other GENERAL Concepts ............................................................................................. 9
The Case For TIER (An Architectural discussion) ........................................................ 10
Overview ....................................................................................................................... 10
Current Position ............................................................................................................ 10
Current Services Components ................................................................................... 10
Current Technology Environment Description ............................................................ 11
InCommon Services .................................................................................................. 11
Open-Source Software .............................................................................................. 12
NET+ Services........................................................................................................... 12
Future Process .............................................................................................................. 12
Process Description ................................................................................................... 13
“The Problems” Re-Framed for Discussion ................................................................... 15
Proposed Technology Response to “The Problems” ..................................................... 17
Methodology for Technology Selection .......................................................................... 19
Technologies that will be introduced by this project. .................................................. 20
Process with Technical Architecture Committee. ....................................................... 20
Expected Risks ............................................................................................................. 23
Reactions To Draft....................................................................................................... 26
Appendix A: Participants To-Date ................................................................................ 29
Appendix B: Identity Management in Higher Education: A View of the Landscape June 17, 2013............................................................................................................. 31
1. Executive Summary .................................................................................................. 31
2. Identity in Higher Education ....................................................................................... 32
2.1. Why Must Higher Education Address This Issue? ............................................... 33
3. The Process We Used .............................................................................................. 35
4. What We Learned ..................................................................................................... 35
4.1. Project Survey Results........................................................................................ 36
4.2. Identity Thought Leader Discussion Results ....................................................... 37
4.3. Likely Trends and Concerns ............................................................................... 37
5. Observations and Recommendations ........................................................................ 38
5.1. Organizational Preparedness.............................................................................. 38
5.2. Extending the Reach of Identity Management and Federation ............................ 39
5.3. Overlaps (Or the Lack Thereof) and Eliminating the Gaps .................................. 41
5.4. Governance and Financial Sustainability ............................................................ 42
6. Appendix - A Functional Model of the Identity Landscape ......................................... 43
6.1. The Global Perspective ....................................................................................... 43
6.2. Putting It Together - Federations......................................................................... 44
Page
-3-
6.3. Putting It Together - Interfederation .................................................................... 46
6.4. Putting It Together - IdP Operators ..................................................................... 48
7. Appendix - Implications for CIOs ............................................................................... 50
7.1. The CIO as Institutional Enabler Perspective ...................................................... 51
7.2. The CIO as Technology Provider Perspective..................................................... 52
7.3. The End-User Perspective .................................................................................. 52
7.4. The Service Provider Operator Perspective ........................................................ 53
8. Appendix - The Project Survey .................................................................................. 54
8.1. Questionnaire ..................................................................................................... 54
8.2. The Projects ....................................................................................................... 55
9. Appendix - Top 10 IT Issues from EDUCAUSE ......................................................... 55
10. Acknowledgments ................................................................................................... 55
Appendix C: Selected Excerpts from Use Case Library (V-1, V-2) ............................... 57
Page
-4-
GENERAL TIMELINE TO-DATE
April 6, 2014
TIER Announced at 2014 Global Summit
May 12, 2014
Shaping of TIER “Anticipated” Program goals and Functional structure
constructed in response to requirements embodied in the MACE
Document “Paccman Use Case Classification” Dated September 11, 2011
whose principle contributions included Rob Carter (rob@duke.edu); Keith
D. Hazelton (hazelton@wisc.edu); Emily Eisbruch (Internet2); Steve
Olshansky (Internet2); Thomas Dopirak (tgd@cmu.edu)
(User Stories V-1 and V-2 in Appendix C to this document for reference)
May 30, 2014
Budgets (and models) to I2 Finance. Preliminary budget constructed from
Block Diagram of expected “end state” of components.
June 2014  Ongoing
TIER Charter committee formed to establish the mission and goals of the
new TIER initiatives and describe the need, levels of contribution,
governance and goals of TIER (short and long-term).
[ON HOLD] As of June (with the formation of the TIER charter group), no
further development of the solution or vetting would have been
productive until the TIER Charter, Budget, and other parameters had
been brought into focus.
June 25, 2014
Internet2 Executive Leadership Team Reconciliation of the Budget and
variances for presentation to the board.
August 15, 2014
Internet2 TIER Budget Approved “Provisionally” by the board.
(Pending the ratified funding model from the participating institutions.)
August 21, 2014
Conversations resume with Internet2/InCommon Federation Operations,
CSG and InCommon TAC leadership to develop a possible end-state
vision (read: “straw-man proposal”) for broader discussion with the
Architects and the broader community representatives identified later in
this document.
Sept 10, 2014
Proposed presentation to the CSG group at fall meeting (hosted Cornell)
for discussion and consideration in advance of community release.
Oct 1, 2014
Proposed Community Release of document in parallel with application
and investment request of community members to participate in funding
the TIER work.
Page
-5-
THE STATE OF IDENTITY
(AS VIEWED BY INTERNET2 AND THE NET+ PROGRAM)
Audience – Why is this document specifically addressed to the campus Architects?
“I just had my weekly meeting with the Deputy CIO here. I gave a brief description of
the longer-term TIER vision; [the] response, literally, was "why should I give a [darn]
about any this? Solve my problems today."
(And some CIOs will say "I won't be here when you deliver that vision.")
Someone has to construct the steps forward, the steps between here and there,
because that's what he's worried about, and I think many of [the campus CIO’s and
Technology Leadership] are worried about.”
Internet2 exists to act on behalf of the members it serves. For this reason: We believe that
this document, developed to date through engagement with the community through
historical review, interview and other meeting contexts, will result in a credible and mostly
complete straw man which can be put forward in response to statements of pain by the
Campus CIOs. We do not expect the TIER Charter Committee to provide Internet2 a complete
or detailed statement of requirements (technical or functional) because we believe that the
Architects will do that. However, we do expect the charter committee to express the type of
pain they believe needs to be addressed so we may begin with the end in mind.
Primary Goal
Our primary goal in sharing this background document is to develop a relationship and
mutual trust that the community depends upon; with the intent of developing a lighter-weight
format of communication for broader consumption by other interested parties. Internet2
sees both a set of short-term and long-term problems that must be addressed while
simultaneously using the membership as a guide and pilot community to address those
problems. We recognize that the TIER story must be relevant to vast majority of the
members’ rather diverse set of problems, while also anticipating the needs of the future and
future members. Therefore, TIER is being designed to construct both short-term AND longterm sets of deliverables.
Landscape
The following landscape and problem statement narrative provides the portion of the Identity
and Access landscape that is the environment that we can see – the metaphorical “Tip of
the Iceberg”. The Landscape document (contained herein) is relied-upon for guidance
throughout this document and demonstrates the complex and multi layered challenge (and
opportunity) that higher education has in addressing scholarly identity.
Our current position is that the academy can no longer characterize the "whole individual” as
has been necessary when describing interactions within and between institutionally
managed resources or services. In today’s environments, institutions are a hybrid of these
traditionally managed, internally facing systems and the collective sum of a constantly
shifting portfolio of external resources and services. We now conduct activities that are
affiliated with, but by definition not owned or internally managed by the institution. In short,
Page
-6-
the nexus of the academy and commercially
offered services is now best architected and
described as both “the individual” as well as
“the institution.”
For this reason (and for purposes of articulating the
concepts in this document) we try to use pre-existing
vocabulary wherever possible. But we start with some
basic building blocks:
An attribute
is a basic building block that can be a
wholly-managed institutional object or an
externally managed object
Historically an Institution, like a village,
town, or city, is not an inherently trustworthy
single entity but rather a collection of
personas and services that contribute to,
and benefit from, the assurance of the
institutional entity that they are valid. Such
a loosely coupled institution overcomes that
limitation by operating as singled entity that
provides a trusted brokerage. For example
within the institutional context there are
multiple “certified” (vetted by the institution)
personas or services that are authorized to
meet defined criteria necessary to achieve
appropriate levels of trust. Collectively they
achieve institutional trusted entity
status. Where external validation is
required, mutually agreed upon levels of
assurance must be achieved.
In the emerging context of rapid change
facing higher education, an institution must
develop a new and adaptive approach to
achieve the same level of assurance while
participating in the disaggregated, but vital,
academy ecosystem. Just as the previous
internally trusted brokerage model worked
to solve disparate personas and services
within an institution and appoint certified
versions of those, a scalable trusted pan
institutional brokerage must exist to support
reuse of those certified attributes, personas,
eduPerson designation and services across
entities. Such a brokerage must facilitate
the use of these components in both
federated and non-federated use cases and
be architected to avoid requiring unlimited
bilateral agreements (which will not be
possible in many to many institutional
context).
A "persona”
(or role) is a wholly-managed
institutional object (as defined by the institution
and made up attributes.
A Real Person (as contrasted with an “eduPerson“)
is made up of one or
more personas, yet the collection of
the personas cannot be managed by a single
entity of any type. Therefore the “Real Person”
can never be a wholly managed institutional
object.
An eduPerson
as defined by the object schema is an
object describing the institutional view of the
Real Person. It different from, but potentially a
highly-decorated view of the real person as a
“student”,’ “faculty member”, “staff”, “employee,
“affiliate”…
A service
is always a wholly managed object
and must be managed by either the institution
or an external entity. When owned by the
institution, the service may be a wholly
managed institutional object, externally it is not
an institutionally-managed object.
The sum of any identity transaction is constituted by a trust
relationship between:




Attributes
o
Are the origins of those attributes
authorized to assign that
attribute? (Certification by what entity for
the attribute?)
Persona
o
As what or whom are you acting and
o
What do you want to do?
o
Can you do what you are trying to do?
o
(Authorization as a managed object by the
institution)
eduPerson
o
Are you who you say you are?
o
Are you WHAT you say you are?
o
(Authentication & Identity Proofing by the
institution)
Service
o
Activity to achieve a result
o
(A managed internal or external object)
The objective for the envisioned “Brokered"
environment is not one of centralized
control. It is to be viewed as just one member of the federated trust fabric that acts as
a “Rosetta Stone” between services where the data being brokered relies upon the
Individual as an authoritative and trusted party; just as if it were another trusted
Page
-7-
institution. This expands upon the previous work of InCommon but spans across the
institutional architectures (? “Fabric") to provide a higher aggregation of possible solutions (in
the form of combined “services”) such that an institution can address current internal needs
as well as those which result from facilitated external providers.
PROBLEM STATEMENT
As the IAM ecosystem within higher education has evolved over the last decade, it has
attempted to address the emerging issues of multi institutional collaboration, online
engagement, hybrid models, and more that make up the changing educational community.
Commercial products simply didn’t face these same challenges and early architectural
leadership enabled a near decade long advance on what is now clear: no institution operates
alone and students, faculty and staff are increasingly reliant on resources not available
within the confines of the four walls of the primary institution. In evaluating options,
purchased solutions designed for the traditional non education institution (e.g. commercial
service providers) have been found to simply be too limited an definitional space, thinking of
everyone as a single role (employee, contractor, supplier, customer), always in a binary
context (current employee, former employee) and always controlled by the enterprise itself
(we say if you are an employee or not).
Higher education operates in virtually the opposite environment where individuals are often
(if not always) supported in multiple official (and unofficial bur recognized) roles of student,
employee, researcher, faculty, etc.), where those roles may be concurrent (alumni and faculty
at the same time), and defined by multiple parties (many authoritative sources to define
personas or roles on in an educational environment). Each attempt to address this
complexity has resulted in the purchase or creation of a piece of the solution, with each
subsequent gap filled by yet another piece.
Still the collection of the pieces does not provide a complete solution, nor is it viable for a
campus to continue operate multiple, parallel identity infrastructures indefinitely to
accommodate for the diverse needs of the community. Its time for a services approach, that
operates on common standards and delivers the management capabilities needed by an
institution while supporting the flexibility needs of individuals with multiple personas.
The TIER solution is expected to address the following:
Replace individual technology components (principally of internally managed software) in
preference to those that are easier to operate, better-integrate, and achieves the emerging
identity requirements. We prefer to deliver for the community, a properly curated selection of
open source developed, cloud based services that design and deliver identity and access
management solutions first from the perspective the individual person. We anticipate that
these “persons” will need access to an unlimited variety of internal and external resources
that may or may not be available via the traditional federated internal identity credentials.
The resulting services goal, while addressing the individual, will also meet the management
responsibilities required by the institution.
Page
-8-
OTHER GENERAL CONCEPTS
Create (for the institutions) that which institutions may be unable to create for themselves:
We will move authentication out into the cloud as a common “standard” service such that
the only mandatory requirement from the institution to benefit from the authentication is to
add institutional attributes to create personas that meet needed institutional roles. The
authentication mechanism will be a service that will exist as a hybrid, both as an external
service and one that may be run internally.
An institution will reach agreement with the “community brokerage” to accept certified
attributes (or whole personas) that come from authoritative trusted sources for reuse and
augmentation/decoration/enrichment with additional personas and attributes added by the
institution. EG: This will enable Amazon AWS to know that two of my identities are one in
the same (where I want them to be conflated ) and where the are NOT the same (where I
want my personal persona to remain independent).
The ability to revoke an identifier (e.g.. institutionally assigned attributes or personas) without
having to revoke the totality of the identity is an equally critical component of this solution
and introduces a type of complexity that is not unlike certificate assignment and
revocation. To help protect privacy of all participants (individual and institution alike), pairwise identifiers will (most likely) be core to the solution.
Page
-9-
THE CASE FOR TIER
(AN ARCHITECTURAL DI SCUSSION)
OVERVIEW
TIER – Identity and Access Management as a Service proposes to deliver an integrated cloud
service and an installable version of those components, with associated local components
that will provide full Identity and Access management (including Authentication,
Authorization, Assurance, and Federation) to the United States Higher Education Community.
It will be created through a combination of integration of existing open source components,
new development of software that will be delivered as a service, and use (and where
necessary establishment of) existing and new standards.
CURRENT POSITION
The current identity and access management landscape within higher education is one
dominated by the InCommon federation but dramatically fragmented in the level and quality
of Identity Provider and Service Provider deployments at campuses and commercial
providers within the higher education space.
The community has undertaken well over 30 open-source or community-source initiatives
during the past decade across numerous groups, with the largest concentration and greatest
area of adoption projects sponsored and driven by Internet2 and its institutional members.
That collection of open-source products is no longer sufficient to delivery the needed
functionality, ease of deployment and management facilities/interfaces required in the cloud
services era. Moreover, that collection of products may not longer be viable due to lack of
ongoing commitment to maintenance and long-term custody.
Internet2 proposes to be the long-term custodian of the (to be selected) best of breed
solutions and maintain their integration and viability for the sake of the community it serves.
CURRENT SERVICES COMPONENTS
[Insert a slide, which contextualizes the scope of the problem]
The processes and/or services that will be modified, connected or automated by the
project may be the items below.
Service Name
What does it do?
Service Area
CoManage
Internet2 Middleware
Future IdP (cousin of CommIT)
Individual Scholarly Identity Service
Grouper
Internet2 Middleware
Multi-Context Broker
Brokers between SP-requested
authentication contexts and those
for which the Subject is qualified
Page
-
- 10
PrivacyLens
Internet2 Middleware for
Discretionary attribute release and
management
Part of the Shibboleth Consortium.
Supports IdP and SP components
Shibboleth
The items below are potential “connector” candidates of related services (perhaps for
provisioning and other enrichment):
Service Name
What does it do?
Service Area
DocuSign
Electronic Signature
Duo Security
eduroam
Multi Factor Authentication Soft
Token
Device Identity and Access
Fischer Ignite-Federation Service
IdP Location Implementation
InCommon Assurance
Assurance Level for Higher Level
Access
(1) Web Security Certificates
(2) Personal x.509 Certificates
InCommon Certificate Service
InCommon Federation
Federation Operation
Kuali KIM
Kuali Identity Middleware
(Kuali.Org)
Password Encryption and
Management
Multifactor Authentication Hard
Token
Mutlifactor Authentication Soft
Token
LastPass
SafeNet
Toopher
Table 1 — Primary Services and Software Components Potentially Impacted by Proposal
CURRENT TECHNOLOGY ENVIRONMENT DESCRIPTION
The current services are a blend of different types of services, delivery approaches, financial
models, branding and intellectual property structures. The following is a overview of each of
the main components:
INCOMMON SERVICES
The original service, the InCommon Federation, was established in 2004 to provide an
exchange of metadata between participating institutions. It was established as InCommon,
LLC a wholly owned subsidiary of Internet2. Subsequently a proposal to offer a Web
Certificate service from Internet2 (developed by the Applications, Middleware and Security
Committee AMSAC) was assigned to InCommon team to develop with the intention of
providing subsidy to the close the gap of the unfunded liability associated with the operating
the InCommon federation.
Page
-
- 11
The service included two independent but aligned components, the web certs (including code
signing and ssl certificates) and personal certificates (X.509), both for unlimited deployment
to subscribing campuses.
Two multifactor authentication services were then added, SafeNET and Duo, with the same
objective of providing a needed service while providing subsidy financing to support the
InCommon Federation program. The InCommon Assurance Program, a certification effort to
raise the security and confidence level of certain metadata attributes, is a component of the
InCommon Federation.
OPEN-SOURCE SOFTWARE
Software Middleware developments proceed in parallel and aligned with the needs of
campuses to support federated identities, groups, and manage those environments. Each
of the primary projects, Shibboleth, CoManage, and Grouper, and later the Kuali Consortium
Kuali Identity Manager project developed independent middleware tools, were each
developed as independent open source codebases for download and local implementation.
One such project, Eduroam, began in Europe and in 2011 was brought into Internet2 where
Internet2 serves as National Roaming Operator for the United States.
During these formative years there have been at least 30 initiatives targeted to meet a
variety of needs, many of which overlap:
CAS, Shibboleth, Grouper, KIM, OpenReg, CPR, Identity Match, CoManage/CoCoA, InCert,
uApprove, InCommon Assurance, CommIT, ORCID, OpenIDM, Syncope, iRODS, CILogon, uProve, FICAM, NSTIC IDESG, InCommon Federation, SimpleSAML.php, COManage, IRMA,
PubCookie, InCommon Quilt, Kerberos, ConnID, OpenIDConnect, Oauth, OpenICF, SCIM,
XACML, Social2SAML, MDX, Metadata Aggregator, ABC4Trust, NSTIC Scalable Privacy, KOM,
OpenIdM, EduGain, Moonshot, …
NET+ SERVICES
Beginning in 2012 with the launch of the NET+ program, additional identity services were
nominated by the Internet2 member community for advancement through the NET+ Service
Lifecycle Program1. Those services related to identity including initial additions in three
areas: multifactor authentication (Toopher), electronic signatures (DocuSign) [with nonrepudiation] and password management (LastPass). Each is developed following the NET+
lifecycle model and has its own independent governing group of campuses lead by a
sponsoring institution.
FUTURE PROCESS
Through a combination of functional requirements gathering, technical standards
acceptance (and where necessary development), integration of existing tools, and ultimately
development of Identity and Access Management as a Service, TIER strives to deliver a fully
functional, easily deployed offering that meets the needs of the community.
1
http://www.internet2.edu/vision-initiatives/initiatives/internet2-netplus/
Page
-
- 12
PROCESS DESCRIPTION
The TIER-IAMaaS program is designed to take a holistic approach to address the
considerable challenge of deploying an appropriate, scalable federated infrastructure to
manage all aspects of identity on a campus while making additional à la carte services
available via the NET+ program.
The proposed solution recommends three distinct activities: all commercial and community
services operated as a NET+ Service, the InCommon Federation operated as a component of
a future TIER IAMaaS service but available independently from TIER IAMaaS, and the TIER
IAMaaS development effort which will deliver the TIER IAMaaS offering possibly as a
subscription-based service or as an on-premises deployable solution supported through
some form of sustaining funding by participating campuses. As history of these middleware
offerings has taught us, no viable solution can be offered without ongoing underwriting by
participating campuses and curatorial oversight.
We offer the following possible phases of evolution. The first two steps are provided for
completeness; the step most relevant to this paper is Step Three:
Step One:
Rebranding and alignment of all non-core services into the NET+ lifecycle and
operating model. All services will be listed as NET+[servicename} and InCommon will
only refer to the Federation and Assurance aspects. Each of the NET+ services will
be offered as an individual subscription service available to Internet2 members at
wholesale prices, InCommon participants at discounted price, and non members at a
value “non member price” better than standard educational pricing. Governance of
each services will be by the NET+ service institutional representatives “roadmap”
model and will following guidance from the NET+PAG and Internet2 board of
trustees.
Step Two:
The InCommon Federation will be operated as a stand alone individual service that
operates and enforces identity metadata policy as defined by a subcommittee of
InCommon Policy group as assigned by the TIER Group. The service will be run from
within Internet2 as an infrastructure service. The intention in the future is to have
the service bundled automatically as part of Internet2 membership.
Step Three:
Through the formation of the TIER Charter leadership group, the TIER Identity and
Access Management service will be developed under the leadership of the AVP for
Integration and Architecture within Internet2. The service development will create an
integrated full IdP as a service and SP as a service paired institutional offering, which
will be operated in a secure community owned (private, non public cloud)
infrastructure. The codebase will be available to load locally on a campus however
the objective is to focus on delivery as a service supported by the resilient high
availability private cloud infrastructure. The charter partners will finalize the two
level approach to business development, the first focused on development of the
Page
-
- 13
TIER IAMaaS offering, then a second one for ongoing sustainability associated with
the subscription offering.
It is expected the charter members will receive the benefit of governance, direction,
prioritization, and decision authority associated with the TIER program. The group will also
determine the appropriate sustainability model and any discount levels for the subscription
service necessary to deliver sufficient resources, support subscriptions, and sustain the
environment
Page
-
- 14
“THE PROBLEMS” RE-FRAMED FOR DISCUSSION
Emergence of Viable and Varied Cloud Services + Increasing Geographic Diversity of
Research and Education creates a new focus on the individual:
•
It’s no longer just about who you are
•
it’s about the spheres of influence in which you operate
•
combined with the means to find the resources necessary to do research, education,
collaboration
•
and do these things, in scalable, elastic, and manageable ways
All while supporting the needs of enterprises (campuses), virtual organizations
(collaborations) and individuals.
Assertion: “Empower Individuals …” is a MUCH lower priority than the ERP connections.
Assertion: The primary issue identified in the Landscape Document cites the following for the
Enterprises/Institutions:
Many universities are struggling to implement effective identity management programs.
They need help with:




Organizational structure
Value and risk assessment
Business process, and
Technology support.
Assertion: for the 2,000 Educause members, the belief remains that these remain the
primary issues.
Assertion: that the specific stress points are


the need to "know something about" new communities outside their core
(applicants, alumni, guests, people taking online courses via continuing
education, federated users) that they have a "weaker" relationship with
the need to manage authorization to use the growing number of digital systems
supporting a wider variety of business functions (eg Career Development Offices,
Parking, Housing, Dining, etc)
Assertion: 90+% of campus use of Federation is really classic B2B use cases. Think Net+
(and all of the non-Net+ providers that we use). In all of these situations, Attribute Release is
determined by Contract; there is NO user control (or even awareness) of what is being
released.
The Goals
•
Cloud-Based Services Increase Management Complexity
•
We must
Page
-
- 15
•
–
Architect beyond our “four walls”
–
Facilitate multiple identities spanning multiple service providers
–
Empower individuals with the means to self-administer (their own) attributes
–
Enable service providers to overcome their own limitations when connecting to
the Research and Education Communities
We do this by:
–
•
Addressing the problem ABOVE the Net … NET+
US Higher Institutions and Researchers say “We Want This NOW”
–
It’s too late for NOW; Expectations are to have meaningful implementation within
one year (unrealistic)
–
Requires a minimum of 30 months of work from the starting-gun
Challenges
•
The core needs are for AuthN and AuthZ for Interrealm Use
•
A wide assortment of open source software has been developed by the community to
address parts of those needs.
–
Excellent, Inconsistent, Non-Interoperable, Hard to Sustain / Maintain, Still has
significant gaps.
•
Lacking a common approach has led to a proliferation of approaches.
•
IMPORTANT: DELIVERABLES WILL BE PRODUCED AT A PREDETERMINED CADENCE (6-8
Month Intervals) REGARDLESS OF HOW THEY APPEAR BELOW:
Requirements Gathering and Preparation (Today / 2014)
High Level Plan (2015)
Convene TIER Charter
Committee
Establish the Funding Model
Begin Resource On-Boarding
Minimize “Fractional” resources
Coordinate with NREN CEO
Group
Establish Governance
(Members)
Build the Runway
Build the Showroom and
Factory
Build the “Underpinnings”
Integrate the Current Offerings
On-board Charter Participants
Showcase and Evolve Current
Solutions
Page
-
- 16
Detailed Planning &
Execution (2016 and
Beyond)
Convene Empower
Architectural Council
On-Board Long-Term
Engineering Resources
Isolate ongoing Maintenance
obligations from Discretionary
spending plan
Measure Twice Cut Once
PROPOSED TECHNOLOGY RESPONSE TO “THE PROBLEMS”
The majority of the target technical environment will be adapted from existing Open-Source
tools, which already exist, are in the process of being enhanced or modified, or are to be
developed in other projects and integrated into TIER IAMaaS in the future. While this is
mostly a systems integration endeavor, the project will also require the development of new
code to achieve its goals. Moreover, it will be necessary to focus on shifting the existing code
bases so they may be run as a service as well as an enterprise installable solution. Our
highest-level design objective is to construct a solution that anticipates the end state of a full
services model.
As of this writing, we still await the requirements document from the TIER charter team which
will, ultimately, describe the needs to which the solution must respond. This document
describes anticipated needs as described anecdotally from the community. The proper order
of our approach will confirm with the industry standard SDLC (Software Development
LifeCycle).
Regardless of the outcome prescribed by the TIER Charter group, it is expected that the
following major components will be required to address the high-order use case of crossenterprise integration:
Free-standing Identity Provider (IdP) which provides discretionary control of attribute
release to Individuals (irrespective of their institutional affiliation). This will empower
individuals to make the right decisions regarding controls on attribute release and
exchange between the individual’s “personal cloud”, their scholarly identity, and the
services contained in the intersection of the two.
Service
Provider's
Defn of
UserIdentity
Individual
Identity
Institution's
Defn of
Scholarly
Identity
The IdP will also serve as the IdP of record for Individuals who elect to coalesce or
transition their Social or Scholastic “primary” identity into this IdP. This solution
segment contains three mechanisms:
o Authorization Mechanism
o Authentication Mechanism
o Identity Repository (For Intrinsic Metadata)
o Identity Resolver (To coalesce Intrinsic and Extrinsic metadata)

Cross-Entity Group Management Facility (CEGMF)


Discretionary Attribute Release System (DARS)
Command Line Protocol Bridge (CLPB) for integration into non-web implemented
applications and services.
Page
-
- 17

Identity Workflow Engine (IdWE) whose purpose is to provide sufficient logic for
management of the identity and repository subscribers for purposes of provisioning
and de-provisioning across multiple services.

Global research grid-home dataset navigation facilities such as those provided by
Globus
In concept, this endeavor seeks to meet the goals of the Shibboleth project and build upon
them:




Easier setup and customization of the user authentication process, including nonbrowser based applications.
Easier injection of post-authentication processes and workflows, such as user
consent for release of data.
Avoidance of Single Sign-On (SSO) for shared devices, and Logout.
Support for non-SAML (in particular non-XML-based) identity protocols, such as
OpenID Connect, in future upgrades.
In Summary – the general block diagram being tendered as “Straw-Man” looks like this:
Secure Identity, Access and Metadata Services
Single Signon and Identity Components
AuthN (Who)
Multi Factor
Multi-Level
(Groups)
Lightweight
Workflow
Services
Persistence
and
Replication
Automated
Provisioning /
Deprovisioning
and Rules
Enforcement
Federated Registry
(Directory Search / Lookup)
AuthZ (What)
Business Rules
Engine /
Grammar
Metadata
Registry
Services
Network
Objects (Files,
Datasets, etc.)
People
Figure 1 — Composite Block Diagram
Page
-
- 18
Files /
Datasets
Nodes
METHODOLOGY FOR TECHNOLOGY SELECTION

METHODOLOGY USED FOR SELECTING THE PROPOSED TECHNOLOGIES.
This is a systems integration endeavor, the methodology to be applied in technology
selection is considered to be a search for Best of Breed (BOB) solutions whose core
functionality is considered to be:





“State of the Art” in design, implementation
Generally (or widely) accepted as a standard or deployed as a solution.
Well-supported by the community either through volunteerism, unwritten
by grant funding, or carries endorsement in the future plans of member
institutions.
Committed to the concepts and values of Open-Source communities.
Non-commercial (commercial implementations will need to be carefully
scrutinized as we seek to provide solutions which will be as cost-efficient
as possible for all levels of possible participants across all potential
participating institutions. Moreover, the benefit of favoring an opensource implementation enables future versions to evolve unencumbered
by the relatively short-term visions mandated by the quarter-to-quarter
mentality required of for-profit organizations.
What we propose is a Systems Software Solution and is, therefore not to be
considered akin to consumer applications that may change quickly in a truly “agile”
environment. This endeavor will be managed as a “hybrid” solution – wherein the UI
elements may be more aggressively evolved while the underlying systems would have
a much more deliberative cycle time. Systems Software (especially those whose
function is to assert authenticity or authority) must have a cadence of deliverables
which is sensitive to the needs of aggressive and exhaustive testing.
There are numerous contenders for each component, it is anticipated that working
groups will need to be formed to disambiguate features provided by the various
competitors and nominate the “foundation application” upon which the final solution
will be built.
The current candidate solutions that appear to have the greatest compliance with the
previous criteria may well, therefore, serve as the foundation solutions:

Shibboleth (3.0+) (IdP / Transport / Bindings)

Grouper (2.2+)

PrivacyLens

Repository/Registry (CPR [Central Person Registry])
Page
-
- 19
Other components have yet to be identified and may supersede these as “most
favored” once the requirements have been received from the TIER Charter
Committee.

Also under consideration are solutions provided by:

Kuali Software Foundation

Globus

Clemson University
TECHNOLOGIES THAT WILL BE INTRODUCED BY THIS PROJECT.
The technologies to be introduced (considered “new”) by this project are a series of
brokers, which enable the participating institutions to migrate to/consume these
services at their discretion. The primary issues we anticipate are:
o
Applications that are already bound to one or more of the previously noted
authentication systems. In these cases, an abstraction layer (façade) would be
constructed to redirect / transform the current call/protocol to that resident in
the externalized service layer.
PROCESS WITH TECHNICAL ARCHITECTURE COMMITTEE.
o
All TIER related software development will follow “agile-like” software
development and delivery practices including a fixed cadence for software
delivery and perpetual maintenance and grooming of the requirements backlog
(a “wish list” of features and functionality desired by the community and
reprioritized within each phase).
Page
-
- 20
InCommon TAC
•Provides Advisory Input to the TIER TSC and TIER ET.
•Characterizes "Requirements" to TIER Technology Steering Committee
•Receives proposed phase deliverables, approves additions to the
backlog and ratifies the committed deliverables to be made by the TIER
Engineering Team
•Communicates all status directly to the TIER Steering Committee.
•Receives Requirements as characterized by InCommonTAC.
•Collaborates with TIER Engineering Team to define actual deliverables
through analysis of Complexity, Cost, Time to Deliver and Dependencies
on other services and systems.
•With TIER Engineering Team, ratifies all proposed changes to standards,
protocols and tools.
TIER Technology
Steering Committee •Governance model TBD
(7 Members)
•Responsible for Defining / Aprpoving ALL standards, APIs, Interfaces
holistically across all constituent elements.
TIER Engineering
Team
(As Managed by
Internet2)
o
•Collaborates with TIER TSC to define deliverables, manage the
engineering effors, manages continuous integration and product QA,
Packaging and Phase Deliverables.
The objective will be to bring all TAC member experience to bear in crafting the
final delivery of solutions and their evolutionary decedents.
 The TIER Technology Steering Committee will be responsible for drafting a
proposal of direction for review by the TAC.
 The TAC will be responsible (by simple majority vote) for ratifying the
backlog prioritization and sequencing of the deliverables for each release
phase. Each release phase (whose cadence is TBD) will be offered by the
TIER Technology Steering Committee to the TAC for full-review within 3
weeks of “phase start.”
 The TIER Technology Steering Committee will be formed as a body of no
more than 7 members whose purpose is to provide appropriate
sequencing and prioritization with the TIER engineering team (managed
by Internet2).
Page
-
- 21




The TIER Engineering Team (comprised of voluntary and “paid”
contributors)
In the event that the TAC does not approve a proposal for new direction,
(they must provide alternative direction which must be deemed equally
feasible by the TIER Engineering team), the TIER TSC proposed direction
will prevail.
If the TIER engineering team cannot develop a coherent/feasible
response to the TAC proposed direction, the original plan (or as much of it
as possible) will be pursued. The cadence must not be interrupted.
In the event that the TAC Cannot provide a majority vote or alternate
guidance with respect to a phase deliverable, the cadence must not be
interrupted and absent new direction provided by the TAC, the direction
set by the TIER TSC will prevail.
Within the TIER engineering teams, the following general principles will be applied:
The Hierarchy of Need:
1. Develop Attainable Goals
The MVP “Minimum Viable Product”
… Begin with the end in mind
2. Integrate what has been built
… Yes, this is a form of Innovation
Page
-
- 22
3. Innovate: Renew and Refresh… where the pieces don’t fit together easily.
Invent ... where there is no satisfactory solution to be found.
EXPECTED RISKS
This section outlines the risks of undertaking this project. It does NOT identify the risks of
status quo nor of the impact to individual campuses or Internet2 of maintaining the many
existing open source components.
NOTE:
We intend to capture all risks in the project risk register listed below..
Potential risk areas include:


Technical Architecture
-
The architecture and deliverables of this solution is entirely dependent on
minimizing the volatility of requirements as supplied and verified by the TIER
Charter committee. Should these requirements be internally conflicted or
inconsistent, we would face a “garbage-in/garbage-out” scenario. This
requires a “gate review” for all fundamental architectural changes including
standards, protocols and toolkits.
-
The possible mitigation of this is to ensure that no requirement is admitted to
the engineering backlog until it has been fully vetted by the TAC. This body of
knowledge (in the TAC) is extremely rare and should have nearly complete
authority regarding the process of transforming requirements into technical
specifications.
Information Security
-
As previously noted, this is System Software. We must therefore be cautious
in attributing and properly treating all “machinery” related to the core of
“trust” – Authorization, Authentication, etc. versus purely user-interface
components when effecting change. This will enable us to categorize risk
appropriately. Our goal is to enable evolution of the user-facing elements
without breaking the underlying elements of trust and authority inherent to
this system.
-
A potential mitigation strategy would be to forge a relationship (to-date,
unsuccessful) with the REN to provide an evaluative framework and perhaps
a quantitative analysis framework for assessing the vulnerability / integrity of
the final solution.
-
The nature of the proposed solution is, at its core, “modular” – its
functionality is bounded by interface “contracts” and can consequently be
evaluated within compartments.
Page
-
- 23
-

Other issues to address

(1) software hardening to minimize vulnerabilities

(2) audit capabilities provided by the System Software.

There are tools and professional services for #1, and #2 must be
captured by technical and functional requirements. #2 especially is
typically required by security policies.
Operational Support
-
New Features

-
-
The risk to new features is dependent on: Stability of requirements;
funding of solution resources and flexibility of the extant codebase.
Should there be a new feature requirement which cannot be met
(reasonably) by the existing software, a new search for existing
solutions will need to ensue. Should no such viable integration option
be found, new software will need to be constructed.
Sustaining Support

The risk is (as it has been to-date) that sustaining support is
insufficient for ongoing viability.

The mitigation to this is to ensure that all current functionality is
underwritten by the community’s financial support in the form of an
annuity (subscription).
Scale

The concerns regarding scalability are potentially very broad. To-date,
the solutions (as-built) have been tested at the enterprise level.
Overall, federation utilization statistics don’t seem to be widely
understood or centrally aggregated. These levels of activity generally
do not have consistently reported, verified and catalogued
concurrency and other usage heuristics. As such, it’s unclear what
the usage patterns, performance dynamics and other attributes of
even the locally-deployed applications may be.

A possible mitigation strategy is to, within year “one”, instrument the
applications to appropriately and securely report utilization statistics
which would isolate the API utilization (e.g. invocation frequency,
interface response times, and other resource utilization information)
to determine which interfaces are most important and which may be
insignificant. This would inform the direction of new features,
ongoing platform refinement and other important vectors.
Page
-
- 24
-
Integrity Testing

One of the greatest risks presented in complex systems software is
attestation of the integrity of each solution as it is delivered.

The mitigating strategy is offered by state of the are software
development approaches to continuous integration, testing and
reporting. Incorporation of the concept of frequent builds (daily,
weekly, monthly) and continuous regression and unit testing using
commonly accessible open-source tools like Jenkins (continuous
integration, born out of Hudson after a dispute with Oracle) and
myriad other open-source continuous testing options such as: AutoIt,
CFUnit, CAMV XML, Check, CPPUnit, Curl-loader, DUnit, Fastest,
FindBugs, FitNesse, Framework for Integrated Test, FUnit, HttpUnit,
Apache JMeter, JUnit, PHPUnit, Litmus (Mozilla), Mauve (test suite),
NUnit, PyUnit, RSpec, Selenium, SimpleTest, soapUI, Splint, STAF,
TestNG, Watir, WET Web Tester, xUnit
Page
-
- 25
REACTIONS TO DRAFT
REVIEWER: The most striking thing to me was the extent to which the initial focus is on
aggregating existing components that are already in widespread use among top tier schools,
rather than on constructing a "product" that would address the needs of everyone else.
NET+: The aggregation effort is intended to result in a “product” which would address
the needs of everyone else without requiring them to learn how all the stitching is
done and, instead, learn how it looks when it’s all put together. The general idea is
that it’ll be nearly impossible (at this point) to determine what that product should be
in the fullness of time, but we are trying to anticipate the building blocks that
any institution would use as a starting point.
REVIEWER: I understand that some effort has to be targeted at consolidating the existing
stuff, and getting it to operate on a cloud base, in an integrated cohesive fashion. Hard,
thankless work, but necessary. But, I'm not sure there would be many customers for Phase 1
because so much of the really hard work is out of scope for that phase.
NET+: The problem with phase 1 (or any of the phases for that matter) is that we are
missing the agreement around the natural REQUIREMENTS (hopefully) borne out of
the TIER charter groups description of where the pain lives. The product would need
to be defined in response to that statement of pain by the architects. We need to
solve more than an integration problem but the integration problem is the one we
must first solve (somehow) to get the “Product”.
REVIEWER: I'm worried, though, that your target won't be sufficient. Your documents don't
mention IDM as a separate System/Service. That's the system that takes in changes (adds,
drops) from the campus Business Systems (applicants, students, HR (faculty, staff), guests,
alumns, federated users working with local faculty); maintains user records in the Person
Registry (containing perhaps 100+ attributes for each user) while remembering ALL of a
person's relationships with the campus; handles onboarding and offboarding for different
Affiliation types into a variety of downstream systems (some/many of which are not in Net+).
You mention IAM (which is a superset, and includes IDM). You do mention some of the
components of IDM (you have a block labeled "automated Provisioning/DeProvisioning and
Rules Enforcement). But, the document doesn't convey any sense of this *really big engine*
that manages all of this information about every person that the campus cares about.
NET+: That was a sin of omission on our part – unintentional . The provisioningdeprovisioning function was mentioned (as an element of workflow) and that’s
different (a bigger version of) what the workflow engine would otherwise provide. It
will be up to the architects and designers to define what, indeed, this needs to
address, in what order.
REVIEWER: Your document mentions Authorization, for example. However, it’s my sense that
the real authorization decision is often made inside the IDM system when it assigns
entitlement attributes (or group memberships) to a person. For instance, a growing number
of campuses are using "Service Eligibility Groups" within Grouper to determine (broad stroke)
eligibility for each of a hundred different services. However, 99% of the membership of those
groups is determined by Rules within the IDM system, based on data coming in from the
Business Systems.
Page
-
- 26
NET+: That function was the intended purpose for including Grouper as a foundation
component. Perhaps I didn’t make that clear enough but can you give it a once-over
(again) to see if I completely spaced that off?
REVIEWER: And, as I mentioned [] was the question that got a lot of chatter during last
week's webinar. When we saw the chatter we developed a seat of the pants survey question - see answers below.
So, I'm not sure whether no mention of IDM was intentional or accidental ? More comments
to come, after my next pass. However, I'd be interested in your thoughts on the above
comments.
——————
What are the problems you face in developing/deploying a meaningful person
registry?






Cost 22.2% (4)
Integration 44.4% (8)
Integration with ERP systems 55.5% (10)
Integration with target systems 22.2% (4)
Policy issues 44.4% (8)
“Where to start” issues 38.8% (7)
NET+: As mentioned above, that was a sin of omission on our part – unintentional.
We really DO want to produce something that is “Turn-Key” – This is the purpose for
aggregating functionality first into a sandbox. It constitutes ONE place from which
the technical community can model what they need for their own institutions. HOW
this is crafted is TBD. However, the efforts done by Keith Hazelton, Jim Jokl and Nate
Klingenstein have taken this a major step forward.
REVIEWER: So what is the near-term straw-man that we can consider as a starting
possibility?
Page
-
- 27
NET+: We envision a family of products tailored for two different deployment models:
(A) Internally installed and managed to address the point from the previous reviewer
comment “Where to start” from a technology perspective. Admittedly this does not
address the organizational issues directly and it’s something that will, ultimately need
to be considered by the community: What role should Internet2 and/or InCommon
play in helping to address the organizational issues?
(B) Deployed as a cloud service. This will enable components to be selectively
adopted and deployed as needed.
Page
-
- 28
APPENDIX A: PARTICIPANTS TO-DATE
The following institutional participants highlighted (yellow) have been a part of the
discussions regarding TIER in some form to-date (Governance, Technical Goals,
Requirements Identification, Security, Operations, Candidate Solution, etc.). Those who are
highlighted (turquoise) have been identified as the next wave of reviewers. They will be
asked to vet the proposed solution against the high-level goals document (to be produced by
the TIER charter committee) so the architects may best devise the proposed solution.
First
Name
Alan
Last Name
Title
Organization
Name
Columbia
University
e-Mail Address
Phone
Crosswell
Associate VP &
Chief Technologist
alan@columbia.edu
(212)
854-3754
Ann
West
Asbed
Bedrossian
Assistant Director,
InCommon
Federation, Trust
Services
Director, Enterprise
Systems
Internet2 /
Michigan
Technological
University
University of
Southern
California
University of
Washington
awest@internet2.edu
(906)
487-1726
asbed@usc.edu
(213)
740-2878
Bill
Yock
Executive Director,,
Enterprise
Information
Services
byock@uw.edu
(206)
685-7535
Boyd
Wilson
Executive Director,
Computing,
Systems, and
Operations
Clemson
University
b@clemson.edu
(864)
363-4643
Bruce
Vincent
Chief IT Architect
bvincent@stanford.edu
Chris
Holmes
Dennis
Cromwell
(650)
724-6625
(254)
710-3821
(812)
856-5594
Eric
Denna
University of
Maryland
edenna@umd.edu
Jill
Gemmill
Assistant General
Counsel
Associate Vice
President,
Enterprise
Infrastructure
Vice President for
Information
Technology
Chief Technology
Officer, Middleware
Stanford
University
Baylor
University
Indiana
University
Clemson
University
gemmill@clemson.edu
(864)
656-3343
Jim
Jokl
AVP and CIO
jaj@virginia.edu
Jim
Phelps
Senior IT Architect
(434)
924-0616
(608)
265-2928
Jim
Bottum
Joel
Cooper
Vice Profost and
CIO
Chief Information
Technology Officer
University of
Virginia
University of
Wisconsin Madison
Clemson
University
Swarthmore
College
John
Krienke
Internet2
jcwk@internet2.edu
Keith
Hazelton
University of
Wisconsin Madison
hazelton@wisc.edu
Director Trust
Services
Senior IT Architect
Page
-
- 29
christopher_holmes@baylor.edu
dcromwel@iu.edu
phelps@doit.wisc.edu
jb@clemson.edu
jcooper2@swarthmore.edu
(864)
656-8100
(610)
328-7679
(734)
352-7095
(608)
263-6911
Kelli
Trosvig
Vice President &
CIO
Sr. Director,
Middleware and
Security
Vice Provost,
Information
Technology & CIO
Associate Vice
President & Chief
Information
Technology
University of
Washington
Internet2
kelli@uw.edu
Ken
Klingenstein
Kevin
Morooney
Penn State
University
kxm@psu.edu
(814)8653540
Klara
Jelinkova
University of
Chicago
klaraj@uchicago.edu
(773)
702-2828
Mark
McCahill
Systems Architect
mark.mccahill@duke.edu
Mark
Poepping
Head IT Architect /
Senior Director
(919)
684-6638
(412)
268-6722
Melissa
Woo
mwoo@uoregon.edu
(541)
346-1762
Michael
Gettes
Chief Information
Officer / Vice
Provost
Asst. Director,
Identity Services
Duke
University
Carnegie
Mellon
University
University of
Oregon
gettes@cmu.edu
(412)
268-9864
Mike
Chapple
Senior Director for
Enterprise Support
Services
Carnegie
Mellon
University
Notre Dame
University
mchapple@nd.edu
(574)
631-5863
Nate
Klingenstein
Internet2
ndk@internet2.edu
Paul
Howell
Internet2
phowell@internet2.edu
(202)
365-1296
(734)
352-4212
Rob
Adams
Senior Technical
Analyst
Chief
Cyberinfrastructure
Security Officer
Chief Information
Security Officer
University of
Florida
rob@ufl.edu
(919)
943-2295
Ron
Kraemer
Waggener
Notre Dame
University
Internet2
rkraemer@nd.edu
Shel
(574)
631-9700
(510)
858-0880
Steven
Carmody
Vice President and
CIO
Senior Vice
President, NET+
Services
IT Architect
steve_carmody@brown.edu
Steven
Sather
Brown
University
Princeton
University
Tom
Barton
University of
Chicago
tbarton@uchicago.edu
(773)
834-1700
Tom
Scavo
Internet2
trscavo@internet2.edu
(734)
352-7002
Tracy
Futhey
futhey@duke.edu
Warren
Curry
Duke
University
University of
Florida
(919)
684-5300
(352)
871-1424
Associate CIO &
Director, Support
Services
Senior Director, IT
Architecture,
Integration
Operations
Manager,
InCommon
Vice President &
CIO
Associate Director,
Enterprise Systems
Page
-
- 30
kjk@internet2.edu
poepping@cmu.edu
swaggener@internet2.edu
sather@princeton.edu
whcurry@ufl.edu
(206)
616-8701
(303)
570-6098
(401)
863-7580
(609)
258-6479
APPENDIX B: IDENTITY MANAGEMENT IN HIGHER EDUCATION: A
VIEW OF THE LANDSCAPE - JUNE 17, 2013










1. Executive Summary
2. Identity in Higher Education
3. The Process We Used
4. What We Learned
5. Observations and Recommendations
6. Appendix - A Functional Model of the Identity Landscape
7. Appendix - Implications for CIOs
8. Appendix - The Project Survey
9. Appendix - Top 10 IT Issues from EDUCAUSE
10. Acknowledgments
1. EXECUTIVE SUMMARY
In February of 2013, the InCommon Technical Advisory Committee was charged with developing "...a
document that presents the landscape of identity-related projects of particular relevance to the Research and
Education (R&E) community, including information about their state, the relationships among them, and
gaps among those relationships and between the capabilities they provide and what is needed by this
community." During the Spring 2013 Internet2 Meeting there was a face-to-face meeting with the
InCommon Steering Committee. At that time the charge was broadened; the Steering Committee requested
that the document also serve to engender discussion within that group on substantial identity management
issues related to Higher Education.
This is that document. It presents a functional view of the identity and access management landscape,
highlighting projects of particular relevance to the R&E community, as well as alternative "lenses" onto the
landscape to highlight implications for CIOs and their constituencies. It also provides several observations
and recommendations for discussion in the Steering Committee.
Institutes of higher education and research are complex, highly dynamic, non-hierarchical organizations
where people often have multiple simultaneous roles and relationships. Off-the-shelf identity and access
management solutions do not generally meet the needs of higher education and research. In a very real
sense, higher education is leading the creation of identity management solutions because it has to.
We are now at a "Henry Ford" moment in the creation of these services, moving from custom built
solutions to "assembly line," off the shelf solutions and an entire ecosystem that will scale well beyond the
early adopters. We have identified the following issues as particularly important to our next steps:
1. Many universities are struggling to implement effective identity management
programs. They need help with:
o Organizational structure
o Value and risk assessment
o Business process, and
o Technology support.
2. There are multiple opportunities for InCommon and Net+ to extend the reach of
identity and access management. Examples of these opportunities include:
o Champion interface standards to facilitate deployment of new services,
o Support global interfederation efforts to extend our federation efforts beyond
national borders,
Page
-
- 31
Foster the creation of usable federated applications to facilitate acceptance
by end-users,
o Leverage identities that people bring with them to higher education for
efficiency and to improve user experience, and
o Enhance privacy and security of identity information.
3. The CIFER project is in a unique position to coordinate the broad range of identity
management related projects to assemble a comprehensive but modular set of
identity and access management solutions that are suitable for use by universities in
a cost-effective manner. Active engagement with the project will be required to meet
this goal.
4. InCommon must continue to evolve its charter and its service profile to meet these
challenges, particularly for the next round of new members, which will be smaller
institutions with more limited resources than the early adopters.
o
This paper explores these issues, providing specific recommendations for InCommon and Net+. Priorities
for these recommendations will need to be determined, and selected recommendations will require further
effort and resources to define and execute specific actions. This is only the start of an ongoing strategic
planning process for InCommon, and this paper is intended to be a living document, revised in the future to
support that ongoing process.
2. IDENTITY IN HIGHER EDUCATION
Online services are growing rapidly. Universities are creating their own local services, but are also
adopting cloud services into their IT portfolio, provided both commercially and by other universities. The
size of that portfolio for a typical university could easily number in the hundreds of services. A small
sampling includes:







Massive Open Online Courses (MOOCs)
Inter-institutional research collaboration
Large and specialized resources in support of research (compute clusters,
telescopes, LHC data, ETC.)
Library systems
Grant administration systems
ERP systems for human resources, financials, and student enrollment, ETC.
Systems for operational efficiency in multiple administrative areas, such as parking,
benefits, prescription management, ETC.
All of these require robust identity and access management. Over half of EDUCAUSE's Top Ten IT Issues
for 2013 require identity and access management:






1 - Leveraging the wireless and device explosion on campus
3 - Developing an institution-wide cloud strategy to help the institution select the right
sourcing and solution strategies
5 - Facilitating a better understanding of information security and finding appropriate
balance between infrastructure openness and security
6 - Determining the role of online learning and developing a sustainable strategy for
that role
7 - Supporting the trends toward IT consumerization and bring-your-own device
8 - Transforming the institution's business with information technology
Page
-
- 32
A well-integrated, robust identity management infrastructure is crucial to the success of progress on these
issues. Universities require ERP-class identity management systems in order manage identities from
multiple sources; perform identity proofing and registration; authenticate users during online sessions;
maintain accurate and timely identity information; administer affiliations, groups, roles, and permissions;
provision users into applications; and support audit and certification activities. (For more information about
identity management systems, see the "Identity Management Functional Model" section of the InCommon
Identity Assurance Assessment Framework.)
Not only must each university operate an enterprise identity management system for its community
members, but organizations and service providers must simplify the integration of their identity and access
management systems and federate their services internationally to enable the rich ecosystem of Internetaccessible services that has only begun to grow. Failure of these IDM systems means the unavailability of
hundreds of services.
2.1. WHY MUST HIGHER EDUCATION ADDRESS THIS ISSUE?
Institutes of higher education and research are complex, highly dynamic, non-hierarchical organizations
where people often have multiple simultaneous roles and relationships. The organizations are distributed,
have varied funding models, and have a high degree of inter-institutional collaboration. Commercial IDM
software currently addresses the typical company use cases rather than the campus ones. For example,




A typical company, even a very large one, can populate its identity management
system from a single source, its human resources system. Universities have a
multitude of overlapping identity sources that must be matched and merged to
identify duplicates and enhance information that is available from only a subset of
the sources. The matching and merging algorithms must also accommodate the
varying business processes and identity proofing requirements of the different
sources. Examples of a university's identity sources include:
o Human Resources
o Student System/Registrar
o Alumni organizations
o Admissions
o Library
o Sports teams
o Student organizations
o Donors
o Parents
o Health care professionals and clinical faculty
o Continuing Education Programs (non-credit and certificate)
o Temporary guests (sponsored and unsponsored)
A typical company assigns roles and responsibilities in a hierarchical and controlled
manner. The vast majority of people have a single position and role. Universities, in
part due to the multiplicity of identity sources, are non-hierarchical, highly dynamic,
and delegation is highly distributed. Common situations include a person who is in
multiple Roles (e.g., both faculty and staff (and parent), or staff and student).
A typical company has a well-defined set of business partners. Universities create
partnerships on a daily basis, at all levels of the organization, without signed legal
documents or administrative review. These partnerships may be long- or short-lived,
but they can rarely afford significant delays to begin their work once the partnership
has been formed.
A typical company can manage credential assurance in a homogeneous way,
whereas universities have diverse needs for assurance and multi-factor among their
Page
-
- 33

diverse constituencies. Universities must also often address the "not physically
present" situation.
A typical company has employees, and perhaps a few sponsored identities.
Universities track identity for a vast range of relationships of varying "strength". There
are core community members (e.g., faculty, students, staff). But, there are also
"students" taking non-credit online courses who may be on a different continent. An
IDM system needs to know what a person's relationship is and assign permissions
appropriately; it also needs to impose appropriate requirements (e.g., for account
activation and multifactor authentication).
Commercial identity and access management solutions have, naturally, conformed to the needs of the
marketplace, leaving higher education with off-the-shelf tools that do not fully meet their needs. The most
successful enterprise identity management systems in higher education are often home grown, and most
using off-the-shelf software require significant local customization. This is particularly acute at smaller
institutions and those with tight budgets, small staffs, and narrower staff skill sets. Other challenges
include:



Multilateral federation, required for multilateral collaboration, is nearly nonexistent
outside of higher education and research. Commercial federating software typically
supports only bilateral Federation.
IT shops are often unprepared for the delivery of identity management as a business
service, as opposed to technology.
Organizational change may be required to achieve alignment with information
security, source system administrations, departmental service providers, ETC .
Projects aligned with higher education such as Shibboleth, Grouper, InCommon, and Kuali are improving
this situation, but there is still much to do.
Ian Glazer, Research Vice President and Agenda Manager at Gartner, recently addressed these issues for
the identity management industry as a whole in his thought-provoking video presentation, Killing IAM in
Order to Save It. He observes that:



Enterprise identity's world is fairly static. It does not match the richness of the
contemporary web.
IAM is "apart" from, not "a part" of, business services.
Our descriptive language for identity management information, typically
hierarchically-constructed LDAP directories and CSV files, is not rich enough to
describe the more graph-structured nature of the web.
He says that IAM must "die and be reborn." It must become:



Fit for purpose, based on standards optimized for adoption, then functionality.
A part of business processes, rather than apart.
Ready for the dynamic world.
Higher education has been building this reborn successor for years. Mr. Glazer's comments provide
confirmation that we are moving in the right direction.
A decade ago Higher Education was able to define and promulgate common standards and practices, as
well as deploy common software to support those standards. The rising use of cloud-based commercial
services serving both commercial and campus customers, however, means we must collaborate increasingly
with commercial providers in the future. Higher education is no longer in complete control of its destiny.
Page
-
- 34
Mr. Glazer's comments provide confirmation that we are moving in the right direction, and reason to
believe that our commercial collaborations will be fruitful.
Henry Ford and Identity Management for the 21st Century
When Henry Ford entered the automobile industry, custom cars of exceptional quality were being produced
by highly-skilled craftsmen in small numbers. The people who drove cars were very enthusiastic about
them, understood their inner workings intimately, had high tolerance for unpaved roads, knew proper
etiquette when meeting other drivers, and carried their fuel with them. Now, people drive cars because they
have to, have mechanics to fix their cars when they break (and AAA to tow their cars to their mechanics),
complain about bumpy roads, must demonstrate knowledge of driving and the laws governing it, and there
are gas stations everywhere.
We are at that Henry Ford moment in the maturity of identity and access management. We need not only
software, but also support services, common policy, certification services, and well-paved paths to
success. In order to reach thousands of institutions and tens of thousands of services, we must move
beyond the current custom model for identity management systems.
3. THE PROCESS WE USED
In support of Internet2's effort to develop an identity strategy, a group was charged to develop a document
that presents the landscape of identity-related projects of particular relevance to the Research and
Education (R&E) community, including information about their state, the relationships among them, and
gaps among those relationships and between the capabilities they provide and what is needed by this
community. This Identity Landscape document is intended to provide information as input to strategic
decision making by those providing leadership to the identified projects and to promote increased
coordination among them. It is written with those audiences in mind, though we also expect it to be shared
widely with the R&E public.
In order to collect the information in this document, we have employed two approaches:


First, we created a short questionnaire and sent it to the leadership of over 40 open
source, non-commercial projects of particular importance to identity and access
management for higher education and research. The responses provided us with
broad information about these projects' goals, structure, funding, and challenges.
The questionnaire and the responses we have received are contained in the
appendices of this document.
Second, we conducted a structured discussion with thought leaders in the field of
identity and access management, both inside and outside of higher education. This
has provided us with a valuable perspective, external to the authoring committee, on
present and future trends and challenges we should pay attention to. In particular,
this discussion highlighted the challenges that many non-R1 campuses will face in
deploying and supporting a modern identity and access management infrastructure.
4. WHAT WE LEARNED
This section summarizes the information that has been gathered from the project survey, as well as through
discussions with identity thought leaders. Also included are "Likely Trends and Concerns" that were raised
by the members of the identity landscape project team.
Page
-
- 35
4.1. PROJECT SURVEY RESULTS
In general, our survey has revealed a rich set of interrelated activities, all serving to address important
issues facing identity management in higher education. There is good knowledge among the leadership of
these activities of interfaces and touch points with other activities and, for the most part, there are resources
available to achieve goals, although often not as quickly as desired. Governance, funding, and
sustainability models vary and are, at times, challenges for the projects. Also, differences in those models
hamper inter-project collaboration at times.
The following subsections discuss various aspects of the questionnaire.
1. Governance. Governance models fall into the following basic categories:
o Open Source Meritocracy. Priorities are set, to a large degree, by the interest
and availability of developers, in the classic manner of an open source
project. There is typically group review of decisions by lead developers, as
well as an expectation that developer interest and availability are driven by
concrete use cases. Eight of the respondents have some variant of this
model.
o Managing Sponsors. Priorities are set by the sponsors, typically to support a
specific purpose. Ten of the respondents have some variant of this model.
o Independent Formal Organization. An independent organization exists to
govern the activity. Four of the respondents have some variant of this model.
2. Sustainability. Sustainability models fall into the following basic categories. There is
often a mix of strategies for a single project; only the primary strategy is tallied below.
Fee-based sustainability models tend to be associated with the more mature
activities with well-understood scope and value that is easily identifiable to their
direct beneficiaries. Identity management's current state of the art, however, often
requires work that has not yet proved its value to beneficiaries. When this is the
case, we tend to see grant-funded and volunteer-based strategies.
o Value Delivered to Volunteers. The project delivers high value to its
participants. Participation is voluntary, but the value brings
volunteers. There is often a contribution of the collaboration infrastructure
from a sponsoring organization. Eleven of the respondents are supported in
this manner.
o Participant Fees. A fee is levied on project participants. Two of the
respondents are supported in this manner.
o User Fees. Users of the service/product are charged a fee. Three of the
respondents are supported in this manner.
o Sponsored. The project is funded by a grant from a sponsoring organization,
which may be time-limited or ongoing. Six of the respondents are supported
in this manner.
3. Common Issues. The common issues faced by these projects tend not to be those
the projects were created to address, instead the following are common threads.
o Misalignment of governance and sustainability models. Differences in
governance and sustainability models can hamper inter-project
collaboration. This has been mentioned in relation to CIFER, Grouper, and
Internet2.
o Obtaining stakeholder input. This is often an issue when there is no formal
governance structure. This can often result in a project that loses support
over time, as potential volunteers and stakeholders do not see value.
Page
-
- 36
o
o
Long-term sustainability. This is, of course, a concern of any project, but it
particularly true to those supported by time-limited grants. Sometimes the
time limit matches the need for the activity, but sometimes some other
organization will need to pick up a project if it is to continue.
Available expertise. Many aspects of identity management are complex and
not yet understood broadly; there are currently very few true experts. Multiple
projects mentioned the difficulty of finding participants with expertise in this
field.
4.2. IDENTITY THOUGHT LEADER DISCUSSION RESULTS
The following issues were identified in discussion with identity thought leaders and the authoring
committee for this report.
1. Organizational Preparedness. Many institutions have difficulty launching and
maintaining an effective identity management program. There may be issues of
funding, expertise, and alignment among business units within the organization.
What should InCommon be doing to inform campus CIOs of the federation's strategic
directions, as well as to help those CIOs be prepared to leverage those strategies?
How do campus CIOs gain access to consulting services that understand Higher Ed's
needs, rather than fitting Higher Ed into products that do not fit its needs ?
2. BYO Identity. Most people now enter institutions of higher education with existing
credentials, some high assurance but most low (E.G., from Facebook or
Google). What role should these credentials play in our landscape? How can these
identities be linked with information maintained by the institution?
3. Assurance for Social Identities. This is an issue both for BYO Identity, as well as the
social identity gateways that are starting to be deployed. What level of assurance
should we associate with such identities? Are there ways to raise our trust in lowassurance credentials?
4. Assurance Requirements for Online Courses. Universities are increasingly providing
course credit to students they never see. What are appropriate assurance levels for
participation in such courses?
5. Vendor Compliance with Standards. Identity management is often not considered in
RFPs and service contract negotiations; it is more often addressed as an integration
issue during implementation. Because it is relatively new, federation is often
precluded by this approach. How can we make federation a selling point for more
vendors?
6. Alignment with Evolving Standards. OAuth2 and OpenID Connect represent standards
that have broad industry attention, and overlapping capabilities with the standards
used by InCommon. They also have very large players like Google behind them. What
are the appropriate strategies for alignment with these and future protocols?
4.3. LIKELY TRENDS AND CONCERNS
The following issues were raised in internal discussions of the identity landscape project team.
1. Integration of NetPlus providers and campus IDM systems continues to be a
challenge. Most NetPlus providers have technical solutions targeted at the consumer
market, and are not prepared for institutional programs in a federated environment.
Page
-
- 37
2. Crossing Institutional Boundaries. Research, instruction, and even administration are
decreasingly contained within institutional boundaries. How can we deploy
institutional services that support delegated management of distributed
authorization? How can we deploy a common, standardized approach for
provisioning, authentication, and authorization for cloud based applications?
3. Managing Different Types of People. How do we support growing sets of people who
have only loose relationships with the campus? How do we provide scalable identity
vetting and proofing for students taking online courses for credit? How do we provide
services that span K-12 and applications that span those periods of life (E.G.,
portfolio)?
4. Extending the Reach of Federation. What should we be doing to increase
participation in the federation, both by institutions and service providers? The first
200 InCommon members were relatively easy, as they have the resources to
innovate and require relatively little support; how do we include the next 2000
members?
5. Evolving Awareness of Privacy. What can be done to preserve privacy while
maintaining usability and scalability? With help from FaceBook, users have become
increasingly aware of how many commercial service providers collect and then share
both PII and usage patterns.
6. This Stuff Can Be Hard on End-Users. How can we hide the complexity from end-users
without sacrificing security? Delegation of authority to manage groups and
permissions is part of the model that will be used to achieve scalability. However,
User Interfaces for those tasks are still primitive, and the concepts are foreign to
many users.
7. Identity Assurance. What do campuses need to do to prepare to assert higher levels
of assurance for their community members? Upgrading business processes and
deploying multi-factor authentication are common issues.
8. Tools in Support of Audit, Attestation, and Other Reporting. These tools exist
commercially, but are often not implemented in research and education.
9. Difficulties configuring commercial products (e.g. Active Directory) for FICAM
standards. FICAM's "real security" approach has sometimes set the bar so high that
campuses have to reconfigure their AD environment and remove less secure
functionality that is relied on.
5. OBSERVATIONS AND RECOMMENDATIONS
5.1. ORGANIZATIONAL PREPAREDNESS
Many institutions are struggling with various aspects of identity management.
1. As a business service, as opposed to technology, identity and access management is
often difficult to place within the technology support organization (or within the
campus organization). From the campus perspective, Identity Management will
probably have a broader definition than just digital credentials. It also may require
partnerships with other organizational units that have not existed in the past.
Examples of service roadmaps, organizational structures, and funding strategies,
particularly targeting a management audience, are needed.
2. Owning and operating the technology that supports identity and access management
is not cheap, particularly for smaller institutions.
Page
-
- 38
3. There is little awareness of the issues surrounding identity assurance, or its value
and risks for a campus.
4. Service providers, such as online course providers, are often unaware of risks
associated with incorrect identification of their users, independent of whether the
services are internal to an institution or are federated.
5. There is a growing linkage between identity and access management and aspects of
security management. Organizations should ensure that there is sufficient and
appropriate communication.
Recommendations
1. InCommon should provide campus CIOs with a roadmap showing federation-wide
strategic directions on a regular basis, including sequencing and a timeline. This
roadmap should include the value for member institutions, as well as the
expectations placed on those institutions.
2. InCommon should provide campus CIOs with documentation, case studies, templates
and other tools to help CIOs create local roadmaps for identity and access
management. This should include information about the business value derived from
implementing the steps in the roadmap.
3. InCommon should work closely with the CIFER project to ensure that a high-quality,
comprehensive and modular set of tools is available for easy, cost effective adoption
by institutions.
4. InCommon should foster the adoption of common institutional policies and practices
for identity management that are supported by pre-configured, readily-deployed
CIFER distributions. In general, InCommon should be developing strategies that bring
"Henry Ford IDM functionality" to the US Higher Education community.
5. InCommon should explore the viability of "Identity as a Service" offerings, either from
InCommon or other third parties, leveraging a "CIFER Certification" for customers that
adopt common institutional policies and practices for identity management. (As
Henry Ford said, "Any customer can have a car painted any colour that he wants so
long as it is black.")
6. InCommon should provide campus CIOs with documentation showing the issues,
value, and risks of identity assurance.
7. InCommon should provide service providers with an easily understood risk
assessment tool to help them select appropriate assurance profiles.
5.2. EXTENDING THE REACH OF IDENTITY MANAGEMENT AND FEDERATION
The concepts of identity management and federation continue to expand and adapt to support new ways of
providing services to our community. We need to identify and support opportunities for increasing the
reach of our efforts to other communities, as well as new applications. The following are examples of
where this is an issue:
1. Cloud services, especially, lack standard interfaces and practices for provisioning and
deprovisioning, and for managing access. Campuses will only be able to use the
growing portfolio of Net+ providers if those providers share a common set of
interfaces for provisioning and authentication. Otherwise, campuses will not have the
resources required to implement custom interfaces for each provider.
2. Commercial IDM products do not meet the identity, role management, and
provisioning needs of campuses; using them on a campus often requires significant
customization.
Page
-
- 39
3. Campuses require powerful group management capabilities that can define both AD
HOC groups and groups based on affiliation and other identity attributes, while
providing the ability to manually "fine tune" group membership to conform to AD HOC
requirements. It must be possible to delegate administration of groups in a very
distributed fashion, and it must be possible to extract group memberships from the
system for provisioning into applications, both locally and in the cloud.
4. Interfederation (including edugain and eduroam) provide the ability for US campus
community members to operate effectively in a global environment
5. Bring Your Own (BYO) Identity and/or Credential. Today everyone being issued a
digital identity by a campus already has an identity issued by one of the "social
providers" (or, soon, by COMMIT). The NSTIC Initiative is promoting an Identity Model
that includes both Identity Providers and Attribute Providers. Campuses are
beginning to leverage social identities with applicants, parents, and online students
in non-credit courses. NSTIC and OASIS also have efforts underway to deploy
business processes and technology to elevate the Level of Assurance of social
identities to a level that would be acceptable for business transactions at banks. It is
likely that over time campuses will stop issuing credentials and instead rely on
elevated social identities. Campuses will then become Attribute Providers,
associating attributes such as Affiliation=Student to a social identity.
6. Applications and services often do not federate well, or have poor usability because
of poor UI support for Federation.
7. By 2011 half of all devices shipped were mobile, and the PC was in serious decline in
terms of market share. Applications on mobile devices, however, generally do not
support the federated authentication protocols currently supported by campuses.
8. InCommon has not developed many of the support services that are often provided
by other national federations that were funded to address the needs of all
universities and colleges. InCommon was created by R1 universities. Because the R1
universities have the resources to innovate, as well as a relatively low need for
support, In order to address all US Higher Education, and other communities like K12, a broader range of services will be needed. Participation by the full range of
institutes of higher education and research in the US will require many steps,
including the following:
Recommendations
1. InCommon and Net+ need to be champions for standard interfaces, particularly for
provisioning, deprovisioning, authentication and authorization. This will likely
engender the development of standards, design patterns, and tools for use by
software service providers.
2. InCommon should foster the creation of education and tools to assist application
developers in building usable federated services. This will likely need to include
usability studies of federated applications to determine good design patterns.
3. InCommon should continue to support CIFER coordination of open source efforts,
such as Shibboleth, Grouper, and Kuali KIM, that enable and extend identity
management's applicability in higher education and research.
4. InCommon should facilitate discussion between campuses and vendors of
commercial identity management systems to share campus requirements with those
vendors.
5. InCommon should continue to support efforts in support of interfederation (including
edugain and eduroam) in order to enable global collaboration and access to services.
Page
-
- 40
6. InCommon should facilitate pilots using standards that are becoming increasingly
prevalent among commercial Internet services and some campus-based services.
7. InCommon should continue to track and support efforts to assess and, where
appropriate, leverage identities and credentials that are administered by entities that
are external to InCommon, particularly social identity providers.
8. InCommon should track and, where appropriate, foster the deployment of solutions
for mobile devices that support federation.
9. InCommon should be an active participant in the NSTIC initiative, which holds
promise to create a national identity ecosystem that higher education will be able to
leverage. The projects related to privacy are of particular importance.
5.3. OVERLAPS (OR THE LACK THEREOF) AND ELIMINATING THE GAPS
As has been mentioned earlier, the leadership of research and education's open source identity management
activities have good mutual knowledge of the other activities that touch on theirs. Information is shared
readily, so there is not a lot of overlap. This is different from the commercial space, where competition
fosters extensive and intentional overlap among multiple vendors' product suites. When there is overlap in
the open source space, the normal "open market" process identifies the leaders, and redundant efforts are
retired; forking of projects is unusual in this space. For example, there was a time when many institutions
were building home-grown web single sign-on systems; now CAS and Shibboleth are the clear leaders.
The following projects warrant further discussion:


CAS, Shibboleth, and SimpleSAMLphp. While all are single sign-on systems, they
address different situations. CAS protects applications used within an enterprise and
is typically managed by application administrators. Shibboleth addresses both
federated and enterprise applications but is typically managed by systems or
platform administrators. SimpleSAMLphp integrates directly into application code,
and can be used without any system administrator involvement. Bringing some of
CAS's "developer friendliness" to Shibboleth would be helpful. Both CAS and
Shibboleth have large installed bases; it would be difficult to replace one with the
other. It is common and simple for CAS and Shibboleth to be used together.
Grouper and Kuali Rice KIM. Both Grouper and KIM manage groups and
permissions. What distinguishes KIM from Grouper is that it is optimized primarily for
the specific set of Kuali applications (although can often be used outside of that
application sets), whereas Grouper is agnostic about the applications it
manages. Organizations that use Kuali applications need KIM, and organizations
with a more heterogeneous technical environment need Grouper.
A glance at the list of projects under nearly every category in Appendix - Introduction to the Identity
Landscape will show apparently overlapping projects. In actuality, they often reflect the multifaceted
nature of each category. While one could envision a single, all-encompassing solution for each category,
that is not achievable in practice. Multiple cooperating activities are often the best way to address these
complex issues.
The CIFER project provides an opportunity to establish common functional standards for interfaces among
the components of identity and access management systems, enabling alternative components to be used as
appropriate for the environment. It also serves to fill gaps; software to implement person repositories and to
provision services are specific needs that CIFER is addressing.
Page
-
- 41
The various IAM software, like most open source software, requires local technical expertise and
operational effort to deploy, which may put it out of reach for many of the smaller institutions. There is an
opportunity here for third-party support.
Recommendations
1. InCommon and CIFER should monitor their support of projects regularly to leverage
other activities in order to make the most effective use of resources.
2. As mentioned in the Organizational Preparedness section, InCommon should foster
common CIFER configurations of IAM software and explore the viability of third-party
"Identity as a Service" offerings.
5.4. GOVERNANCE AND FINANCIAL SUSTAINABILITY
Different governance and financial sustainability models seem to work better or worse for different types of
activities.


"Heavier" models for governance and sustainability tend to work best for activities
that address well-known operational issues with well-understood scopes and costs.
Kuali and InCommon, for example address such well-known issues, and they are
governed by independent formal organizations or managing sponsors and are funded
by participant and user fees.
Projects that push the envelope generally require "lighter" models. Projects, like
Grouper, with an emphasis on innovation do not typically develop well-understood
scopes or costs until later in their lifetimes. They typically work best with governance
models like open source meritocracy, and are sustained through sponsorship and/or
value delivered to volunteers.
As identity and access management matures, projects like CIFER can help move IAM software from one
governance model to another especially as it transitions from innovation periods into operational
periods. This will likely cause strain in the ecosystem, as governance and financial sustainability (and
cultural) models can collide. Such strains, however, are not new to the open source world, so there is hope.
Linux distributors like Red Hat and Ubuntu have had great success in this over the years.
5.4.1. GOVERNANCE AND FINANCIAL SUSTAINABILITY FOR INCOMMON
InCommon falls in the category of an activity that addresses well-known operational issues. However,
InCommon's charter is evolving over time, and may expand to include both service and development
aspects. In addition, the membership profile with respect to required support services is changing. Finally,
InCommon itself continues to be an agent of change, supporting innovation and development efforts.
InCommon must continue to adapt its service portfolio to these changing circumstances, using an
appropriate governance model for various activities.
Recommendations
1. InCommon should adopt an effective portfolio management strategy that balances
the needs of its increasingly diverse membership while continuing its mission of
innovation.
2. This document is the start of a strategic planning process. An appropriate strategy for
maintaining this document's currency should be part of that process.
Page
-
- 42
3. InCommon must ensure that the funding model evolves in concert with its evolving
service portfolio.
6. APPENDIX - A FUNCTIONAL MODEL OF THE IDENTITY LANDSCAPE
6.1. THE GLOBAL PERSPECTIVE
Identity management for research and education is a complex web of players and interactions. Campuses
are the stewards of identity information about the people in their communities. They manage identity for
their community members and people with various relationships, do identity vetting (perform a
Registration Authority role), issue credentials, and manage Roles, attributes, permissions, and provisioning.
Identity Federations, often organized around national boundaries, are collections of campus identity
providers and service providers that consume that identity information to deliver their services; Federations
rely on a common policy and technical framework. Interfederation provides the policy and technical
framework allowing operation across Federation boundaries. There are also many service providers that are
not federation members.
This appendix describes the chief elements of identity management for higher education and research,
along with current activities (by projects and organizations) that are related to each. Since this is such a
complex field, the following appendix, Implications for CIOs, provides alternative views of the identity
landscape to highlight the implications for CIOs and their constituencies.
Note that a comprehensive market survey was not within the scope of this project. This is a rapidly
developing market segment, and there are many more activities in the world that could be listed
here. Cloud service providers are growing particularly rapidly. We have tried to be selective, primarily
listing open source activities with direct impact on higher education and research.
6.1.1. FEDERATIONS
Page
-
- 43
Federations exist to enhance trust among their member institutions and service providers. Each federation
provides a legal, contractual, and technical infrastructure that enables the controlled exchange of the
institutions’ identity information within the federation to support inter-institutional collaboration and access
to services and resources within the federation.
R&E federations are coalitions of institutions with common interests, and nearly all utilize interoperable
technologies based on the Security Assertion Markup Language (SAML) suite of standards.Because of the
legal and contractual aspects of a federation’s infrastructure, however, federations tend to be comprised of
institutions that share a common legal framework; their members generally exist within national borders.
We are starting to see inter-federation infrastructure being built as bilateral agreements are forged among
federations, and we can expect this to accelerate as successful models emerge.


Identity Provider Operator (IdPO). An IdPO is a federation member institution that
operates an Identity Provider (IdP), the technology component that transmits identity
information to Service Providers. An IdPO is responsible for the accuracy, security,
and privacy of its community members’ identity information. This is done through the
operation of business processes and technology (an Identity Management System IDMS) for:
o verifying the identity of community members,
o maintaining accurate and timely information about community members,
o registering community members’ authentication credentials,
o maintaining the groups and roles to which community members belong,
o authenticating community members during online sessions, and
o releasing information about community members to Service Providers
according to established privacy policy.
Service Provider Operator (SPO). An SPO is an organization that operates a Service
Provider (SP), the technology component that delivers online resources. Service
Providers rely on identity information from IdPs to do this. SPOs may also be IdP
Operators, or they may be independent.
For more information, see the InCommon Identity Assurance Assessment Framework.
6.2. PUTTING IT TOGETHER - FEDERATIONS
Federations can be viewed as a collection of members, IdP Operators and SP Operators, that collaborate to
provide services to the IdP Operators’ community members.
Page
-
- 44
Examples of federations include:





InCommon (US)
eduroam
SWITCH (Switzerland)
UCTrust (California)
UT System (Texas)
Activities relevant to federations overall are listed below. Projects relevant to specific services of
federations are listed under each service description.



CommIT
InCert
The Quilt / InCommon collaboration
Federations provide the following services to enhance trust and interoperability among their member
institutions:

Attribute Exchange Technology Framework. Federations define a framework for the
exchange of identity attributes among its members. In most cases, this framework is
based on the Security Assertion Markup Language (SAML), although there are other
frameworks, such as Globus, which is popular in the research computing grid
community, and OAuth is growing in popularity in the commercial sector. The
framework will also define a common vocabulary for attributes, such as eduPerson.
Relevant activities include:
o ADFS
o ScalePriv NSTIC Grant
o Shibboleth
Page
-
- 45
SimpleSAMLphp
uApprove
OpenID Connect
Certification. Certain of the Interoperability and Trust Standards may require
certification of members’ organizational maturity, policies, practices, etc. The
federation will provide this certification, or define how it may be obtained. Relevant
activities include:
o FICAM
o InCommon Assurance
o OIX
o Kantara
Interoperability and Trust Standards. The federation defines the standards its
members must meet. Some of these standards may be required for all members,
such as basic technical interoperability standards, while some may be required only
under certain circumstances, for example, to assert high-assurance identity
information (assurance profiles), or to receive attributes from IdP Operators without
specific negotiation with each institution (service categories). Relevant activities
include:
o FICAM
o InCommon Assurance
o saml2int
o Kantara
o ScalePriv NSTIC Grant
Member Agreements. Member agreements provide a contractual basis for the
verification and enforcement of compliance with standards. Since these agreements
are between members and the federation, the need for large numbers of bilateral
agreements between pairs of members is often avoided. Relevant activities include:
o InCommon
Metadata. Federations distribute metadata with machine-readable information about
its members. This information includes such things as technical service endpoints,
public keys, certifications, links to information for end-users, etc. Relevant activities
include:
o Federation Manager
o Metadata Query Protocol (MDX)
o PEER/REEP
o
o
o




6.3. PUTTING IT TOGETHER - INTERFEDERATION
Interfederation on a global scale is a rapidly developing area of the identity management landscape.
Interfederation can also refer to inoperation between different vertical sectors (eg Higher Ed and
BioPharma) aor with other communities (eg social identity providers). As such, it is difficult to project
what interfederation will look like in the future, but the increasingly global nature of research and education
demands attention to these issues. REFEDS, a group that explores approaches to the mutual needs of
research and education identity federations worldwide, is a key player in this space.
Page
-
- 46
Interfederation relies on the following:





Metadata Exchange. These are technical mechanisms for exchanging information
about the cooperating federations' members.
Inter-Federation Agreements. These are agreements, often bilateral, among the
cooperating federations that govern the use of metadata, mapping of assurance and
service categories, responsibilities, ETC.
Assurance Mapping. These are the mechanisms, technical or otherwise, for mapping
identity assurance profiles among federations.
Service Category Mapping. These are the mechanisms, technical or otherwise, for
mapping service categories among federations.
Protocol Translation. These are gateways and other mechanisms that translate the
protocols used by different federations.
The following activities are particularly relevant to interfederation for research and education:














CILogon
Virtual Organizations (such as LIGO)
InCommon TAC Interfederation Subcommittee
InCommon Quilt Pilot Project
Research & Scholarship Category
Metadata Aggregator
Metadata Query Protocol (MDX)
Social2SAML Gateway
IdP Proxy (i.e., SAML to SAML Gateway)
NSTIC IDESG
ORCID
PEER/REEP
REFEDS
VIVO
Page
-
- 47
6.4. PUTTING IT TOGETHER - IDP OPERATORS
IdP Operators are the stewards of identity information about their community members within a federation.
This information is provided to services providers operated by the institution or by other federation
members. At a very high level, the flow of information through an institution’s identity management
service can be described as follows:
1. Information is collected from a variety of identity sources (e.g., student information
system, payroll, friends of the library) on an ongoing basis. It is matched against
existing data to remove duplicates and merged into a repository.
2. The information in the repository is enhanced over time by information from the
Identity Sources, as well as business processes specific to identity management,
including identity proofing and the assignment of community members to groups and
roles.
3. After appropriate filtering, information about specific users is shared with Service
providers through the use of authentication and attribute access services.
The following provides short descriptions of the building blocks of an IdP Operator’s identity management
service:

Attribute Access. This is a broad range of interfaces used by Service Providers to
obtain information about their users. These methods may be invoked during a
session, or they may be out of band. Those invoked during a session include
Shibboleth, CAS, LDAP, and Active Directory. Out of band methods include
provisioning frameworks like SCIM. Relevant activities include:
Page
-
- 48
ADFS
CAS
COmanage
ConnID
IRMA
Kuali Identity Manager
OAuth
OpenICF
OpenLDAP
PubCookie
SCIM
Shibboleth/LTI Interoperability
SimpleSAMLphp
Syncope
Authentication. These are services that can be used to verify the identity of a user.
They are sometimes part of Attribute Access services, and sometimes are
standalone. Examples include Kerberos, Shibboleth, CAS, PubCookie, LDAP, and
Active Directory. Relevant activities include:
o CAS
o IRMA
o Kerberos
o PubCookie
o ScalePriv NSTIC Grant (Multi-Factor Authentication)
Governance and Audit. This is the institution’s management oversight and review
structure for identity management. It provides a framework for verification and
enforcement of compliance with institutional policy. Relevant activities include:
o FICAM
o InCommon Assurance
o Kantara
Group and Role Administration. These are the technical and business services that
administer the association of groups and roles with community members. These
associations are then used to determine appropriate permission assignments within
services. Grouper is the prime example here, because of its strong support for the
requirements found in R&E. Many commercial identity management suites also
contain group and role management modules. Relevant activities include:
o Grouper
o Kuali Identity Manager
Managed Attribute Sharing. These tools give individual users a role in the process of
deciding which attribute information should be shared with each Service Provider.
o UMA
o uApprove
o uProve
o abc4trust
Identity Match. This service merges information from Identity Sources into the
Repository, resolving situations where the same person appears in multiple sources.
Typically, there are no strongly-identifying match keys like SSN that are used by all
sources, so the Identity Match is usually implemented as an automated heuristic that
refers questionable transactions to identity management staff for resolution. The
heuristics are, more often than not, implemented by home-grown software that is
closely tailored to the eccentricities of the institutions. Relevant activities include:
o Identity Match
o
o
o
o
o
o
o
o
o
o
o
o
o
o





Page
-
- 49




Identity Vetting. These are processes, such as examining a photo ID card or verifying
an address, that increase the institution’s confidence in the identity of community
members. Most Identity Sources perform identity vetting, but an identity
management service may provide proofing as well to ensure consistent compliance
with standards, as well as to gain higher confidence for specific individuals than is
provided by their Identity Source. Relevant activities include:
o NIST 800-63
o FICAM
o InCommon Assurance
o Kantara
Identity Source. These are the systems of record that the institution uses to maintain
information about students, faculty, staff, etc. Identity Sources also include more ad
hoc membership lists used by campus organizations. While these Identity Sources
are typically operated by other organizational units within the institution, they may
also be operated by the identity management service.
Policy. These are the policies that govern identity management. These policies
address issues such as stewardship, privacy, technical interoperation, organizational
responsibilities, definition of campus roles and affiliations with their associated
benefits and services, etc.
o NIST 800-63
o FICAM
o InCommon Assurance
o Kantara
Repository. The repository is the collection of information managed by the identity
management service. It may be implemented as a single, tightly-integrated database,
or (more commonly) it may be the union of databases maintained by the set of tools
used in the identity management system.
o Kuali Identity Manager
o CPR - Central Person Registry
o OpenRegistry
o Syncope
7. APPENDIX - IMPLICATIONS FOR CIOS
A robust and effective identity and access management strategy carries many implications for university
Chief Information Officers. CIOs must marshal their resources appropriately in order to align the efforts
with their institutions' strategic priorities. Further, they must represent the needs of the institutions
community members and service providers. They must also be prepared to partner with external service
providers.
Identity and access management is a many-faceted field with many interrelated components and activities.
Page
-
- 50
It is our hope that this Identity Landscape has served to provide overall context for all of this. In order to
provide more insight into how this relates to the point of view of CIOs, however, we present a few more
lenses onto the landscape.
7.1. THE CIO AS INSTITUTIONAL ENABLER PERSPECTIVE
As an enabler for institutional priorities, the CIO must map those priorities to technology-based services
and resources. The diagram above illustrates this some of the priorities listed in the introduction.

Many priorities (such as Collaborative Research, MOOCs, Library Systems,
Specialized Resources, and Cloud Computing) involve the provision of services and
Page
-
- 51


resources to select members of the community; this makes Group and Role
management important. Federation and Interfederation are also important for
inclusion of as broad a set of services and resources as possible. Finally, Assurance
is required by any critical or sensitive service that is placed at risk by unauthorized
users.
Bring Your Own Device (BYOD) generally brings its own identity infrastructure along
with the device, particularly for mobile devices. Interfederation, particularly Social
Gateways, are important for the integration of these identities.
Operational Efficiency is achieved through Group and Role management that enables
individuals through delegation of authority. Assurance is required by any critical or
sensitive service that is placed at risk by unauthorized users.
7.2. THE CIO AS TECHNOLOGY PROVIDER PERSPECTIVE
An institution's CIO is typically charged with management and coordination of all aspects of identity and
access management, as outlined in Putting It Together - IdP Operators. As a technology provider the CIO
will see the following:






Registrar and Human Resources, among other identity sources, as critical partners.
Service Providers within the CIO's direct purview.
Computer Use Policy, Privacy Policy, and other applicable institutional policies.
Software Development and integration of IAM components.
Operations of IAM components and their underlying infrastructure.
Office of Identity and Access Management. This is the part(s) of the organization
responsible for the business processes of identity and access management. This
may be an identified organizational unit or assigned to one or more other
organizational units.
7.3. THE END-USER PERSPECTIVE
Page
-
- 52
End-users want to access Service Providers. They want to know that the Service Providers are reputable,
and they want their privacy protected. They understand the importance of following the rules and working
with administrative offices at their institution, like the Registrar, Human Resources, and the Office of
Identity and Access Management. Users don't care how all the pieces fit together, as long as they do fit.





Administrative Offices (Registrar, Human Resources, Office of Identity and Access
Management). These are offices within the institution that administer business
processes related to identity.
Computer Use Policy. These are the institution's policies governing the end-user's use
of the institution's resources.
Privacy Policy. This is the institution's privacy policy. It governs the administration,
release, and use of the end-user's identity information.
Service Categories. Also known as Certification Marks, Service Categories are
assigned to Service Providers to indicate various aspects of a Service Provider's
purpose and operational practices. They are assigned by a trusted authority, such as
a federation, and provide end-users with an indication of a Service Provider's
reputation and trustworthiness. The CIFER Project envisions a role in providing
Certification Marks for Service Providers in ensuring services conform to IAM
software standards and best practices.
Service Provider. This is a service that an end-user may elect to use.
7.4. THE SERVICE PROVIDER OPERATOR PERSPECTIVE
Page
-
- 53
Service Provider Operators want to enable access to their services by end-users, both individually and as
members of institutions' communities. They may form relationships with individuals, institutions, or
federations in order to accomplish this. They require varying degrees of assurance in the true identities of
their end-users.



Assurance. This is the combination of policy, practice, technology, and agreements
that determines the Service Provider Operator's confidence in the identity of an enduser.
Federation. A federation represents multiple member institutions. Service Provider
Operators can typically use the same technical interfaces for IAM services for all IdP
Operators within a federation, as well as other federations with interfederation
agreements in place.
IdP Operator. An IdP Operator represents multiple end-users. When a federation is
not involved, Service Provider Operators are typically required to provide different
interfaces for different institutions.
Depending on circumstances, a Federation may enter into service agreements with Service Provider
Operators on behalf of all members, or service agreements may be formed with institutions or individuals.
8. APPENDIX - THE PROJECT SURVEY
8.1. QUESTIONNAIRE



Project Name. The name of the project.
Contacts. The people who provided this information.
Overview / Mission. A brief overview of the project's reason for being, what the
products are, ETC.
Page
-
- 54








Goals / Roadmap. Specific goals the project has for the future. If available, also a
time frame for achieving those goals.
Approach to Work. How priorities are set, the process for releasing deliverables,
collaborative work style, expectations of members, ETC.
Strategies for Sustainability. Strategies for funding, inclusion of new members, ETC.
Relationships with Other Projects. Areas where there is observed interdependence or
similarity with other projects.
Observed Gaps. Elements of the identity landscape that do not seem to exist, but are
needed to achieve the project's goals.
Challenges. Potential roadblocks to achieving the project's goals.
More Information. URLs where further information about the project is available.
Notes. Miscellaneous notes that do not fit in the other categories.
8.2. THE PROJECTS
Survey responses are available in Known Identity Projects, a compendium of all major identity
management related activities that were discussed.
9. APPENDIX - TOP 10 IT ISSUES FROM EDUCAUSE
The follow are taken from EDUCAUSE's Top-Ten IT Issues, 2013: Welcome to the Connected Age.
1. Leveraging the wireless and device explosion on campus
2. Improving student outcomes through an approach that leverages technology
3. Developing an institution-wide cloud strategy to help the institution select the right
sourcing and solution strategies
4. Developing a staffing and organizational model to accommodate the changing IT
environment and facilitate openness and agility
5. Facilitating a better understanding of information security and finding appropriate
balance between infrastructure openness and security
6. Funding information technology strategically
7. Determining the role of online learning and developing a sustainable strategy for that
role
8. Supporting the trends toward IT consumerization and bring-your-own device
9. Transforming the institution's business with information technology
10. Using analytics to support critical institutional outcomes
10. ACKNOWLEDGMENTS
We thank the following people for their contributions to this document.








Peter Alterman
Tom Barton *
Steven Carmody *
Rob Carter
Paul Caskey *
Nathan Dors
Michael Gettes *
Gary Grafe *
Page
-
- 55













Keith Hazelton *
Roland Hedberg *
Jim Jokl *
Ken Klingenstein *
John Krienke *
Scotty Logan
Nicholas Roy *
Tom Scavo *
Mark Scheible *
Renee Shuey *
David Walker, editor *
Ann West *
Bill Yock
* Member of the Identity Landscape Subgroup of the InCommon Technical Advisory Committee
Page
-
- 56
APPENDIX C: SELECTED EXCERPTS FROM USE CASE LIBRARY (V-1, V-2)
Number Functional
Title
V-1
caBIG
Federated PI
Access
Technical Title
User Story
Categorization
Federated Access to
caGRID Data
Resources by a
Principal Investigator
Federation or VO Providing
Attribute Information
Supplemental to a Subject's
Primary Identity
V-2
Federated PIs within
caBIG Sharing
Dr. Simpson is an epidemiologist conducting
research into pancreatic cancer at Duke Medical
School. He is named principal investigator in a grant
from the NCI under which genetic analysis of tens of
thousands of tissue samples from malignant
pancreatic tumors will be correlated with levels of
benzene and related metabolites in the samples
using caGrid resources distributed across the nation
to investigate the relative contributions of benzene
exposure and genetic predisposition to the eventual
development of pancreatic cancer. During the
research effort, Dr. Simpson wishes to retrieve data
collected at a participating hospital in Oregon. Since
the Oregonian hospital is participating through caBIG
in the research study, its applicable tissue sample
information is already exposed through various
caGRID applications. Dr. Simpson accesses a caBIG
portal application using his web browser,
authenticates via Duke's Shibboleth IDP, and is
recognized as his federated identity,
"drsimpson@duke.edu". When he subsequently uses
the portal to access the Oregonian hospital's tissue
bank database, the Oregonian application is able to
verify through the caBIG federation that
"drsimpson@duke.edu" is the official PI for Dr.
Simpson's pancreatic cancer study, and grants him
access to the tissue data he seeks.
Dr. Lister is an oncologist currently affiliated with the
University of Chicago Medical Center. He specializes
Patient
Referral
Page
-
- 57
Federated Identity Bound to
VO-provided Role Attributes
Between
caBIG
Clinical
Trials
Resource Access to
Refer Patients
Between Clinical
Trials Based on TrialSpecific Authorization
Policies
in the study and treatment of thoracic neoplasms
including cancers of the lung and mesothelioma. He
is currently the PI for a nationwide study
investigating the efficacy of a new combined drug
protocol in prolonging survival among stage 4
mesothelioma patients. His study relies upon caBIG
resources distributed throughout the country for
access to clinical results and to identify candidates
for the study. Dr. Wong is an oncologist at the
University Hospital of Arkansas, and is the PI for a
nationwide study of the efficacy of a new radiological
protocol at treating stage 2 and stage 3 thoracic and
peritoneal malignant mesothelioma. At a caBIG
colloquium in St. Louis, Dr. Wong attends a
presentation by Dr. Lister in which he shows early
results indicating that the combined drug protocol
he is studying can significantly limit the progress of
late-stage mesothelioma in patients whose disease
has proved refractory to radiotherapy. After the
presentation, Dr. Wong discusses the possibility of
referring some of the patients in his epidemiology
study whose malignancies have shown no clinically
significant response to the trial protocol and have
progressed beyond the limits of his own study to Dr.
Lister for possible inclusion in his research study.
They agree that some of Dr. Wong's patients would
be appropriate candidates for Dr. Lister's sudy.
Six weeks later, Dr. Wong reviews the case of a
participant in his study whose disease has
progressed to stage 4 despite treatment with the
test protocol, and decides to refer the patient to Dr.
Lister's study. After discussing options with the
patient, he logs into the caBIG clinical participant
registry using his UHA credentials. As PI of his
research study, he is able to immediately retrieve his
patient's records, but he finds that he is not
Page
-
- 58
Scoped to Unique VODefined Contexts and
Interpreted Through ContextSpecific Policies; VO
Participants Associated with
Multiple Context-Dependent
Roles by Relying Parties
authorized to refer patients to Dr. Lister's study
(although, as a PI in a caBIG-supported trial, he is
able to access Dr. Lister's study information through
caBIG workflow system and retrieve Dr. Lister's
contact information from a directory of caBIG PIs).
He contacts Dr. Lister by phone, and reminds him of
their discussion in St. Louis. While on the call, Dr.
Lister logs into a custom web application designed
by his local IT staff and indicates that he would like
mawongmd@uah.arkansas.edu to be authorized as
a "referring physician" in his nationwide study. The
application updates trial-specific authorization
information at UCMC to indicate that Dr. Wong is
now a referring physician in the Lister study. When
Dr. Wong again attempts to refer his patient to Dr.
Lister's study, he is successful.
Page
-
- 59
Page
-
- 60