| Formatting of this version of the final report is in progress as of July 2015. In the meantime, please refer to the PDF version linked from this page |
|---|
Identity Provider Strategies for Common Campus Environments
Janemarie Duh, Chair
David Walker
This report came out of the Alternative Identity Providers Working Group
Report Finalized: December, 2014
Table of Contents
Table of Contents
Executive Summary
Following is a summary of the work of the InCommon Technical Advisory Committee's Alternative Identity Providers Working Group . It describes alternative strategies for deploying an Identity Provider (IdP) in a variety of campus IT environments with the goal of providing solutions for institutions that do not have the expertise and resources to operate a Shibboleth IdP locally, the strategy most deployed within the InCommon Federation as of this writing.
While a locallyoperated locally operated Shibboleth Identity Provider (IdP) continues to provide the greatest capability and flexibility for an institution’s current and future federation needs, there are alternatives that may be better suited to a specific institution’s:
computing environment (e.g., Java, LAMP, Active Directory)
available resources and expertise, and strategy with respect to insourcing or outsourcing of IT infrastructure.
This paper describes and assesses several alternative strategies institutions may choose to deploy, depending on local circumstance. For example, an institution with a Java environment will likely choose a Shibboleth-based strategy, whereas a Microsoft-centric environment might choose an ADFSbased strategy. Additional considerations are outlined in the body of the report.
When configuring an inhouse solution, or selecting a specific outsourced solution, careful consideration of the criteria described in this paper, in the light of both current and future needs, is very important. InCommon and other higher education identity federations are evolving rapidly, and what you do not need today may become a necessity without much warning over the next few years.
This paper closes with a set of recommendations to InCommon, TIER, and Internet2 with respect to actions the work group believes are important to facilitate the deployment of IdPs within higher education. In summary, these are:
Create appliances for insourced operation including CANARIE/SWAMID IdP Installer tool with configurations prebuilt for InCommon.
Conduct outreach to those institutions that are not engaged in federation and would not know that alternatives for an IdP exist.
Develop a mentor program for InCommon Members to help campuses get started.
Develop criteria for assessing of IdP service vendors.
Author a cookbook on deploying the IdP strategies, including technical architecture, vendor selection, user support, operation, etc. It would be valuable to work with other federations on this project, as these are common issues internationally.
...
- Google Apps Gateway. This is potentially a good strategy for an institution that has registered all of its community members with Google Apps for Education. The group did not have time, however, to assess this strategy.
Each of these strategies were assessed according to the following criteria:
Criteria | Description |
|---|---|
Technical Capabilities | |
Support for Recommended Technical Basics for IdPs | Support for InCommon’s published recommended practices for IdPs |
Support for Attribute Release | Support for attribute release from the campus IdMS |
Support for Entity Categories (R&S) | Support for release of attribute bundles for specific entity categories like the Research and Scholarship Category |
Support for Multiple AuthN Contexts for MFA and Assurance | Support for orchestration among multiple authentication methods to enable, e.g., multifactor authentication for highrisk services |
Support for ECP | Support for ECP to enable authentication for services that are not webbased |
Support for User Consent | Support for release of attributes only after explicit user consent |
Operational Criteria | |
Expertise Required | Inhouse expertise required |
Resources Required | Resources required, particularly human resources |
Upkeep and Feeding Required | Overall operations effort required |
Applicable Environments | Types of campus computing environments where the strategy is valuable |
Pros / Benefits | Positive aspects of the strategy |
Cons / Risks | Negative aspects of the strategy |
Fact finders were assigned to investigate each of these alternatives. See Appendix A for detailed assessments of each of the alternative strategies. These assessments can also be found in the work group’s wiki space at Alternative IdP Strategies and Assessment Criteria , along with meeting notes and other materials.
...
Operate an IAMS
The campus must operate (or contract for operation of) an identity and access management system that tracks the lifecycle of community members’ affiliation with the campus. This includes maintenance of various information about those community members: name, addresses, affiliations, group memberships, record of identity proofing, entitlements, authentication credentials, etc.
Identity Management Policy
The campus must develop and maintain policy governing identity management functions. This is includes eligibility for campus affiliation, requirements for identity proofing, assurance requirements for services, etc.
Governance
The management structure and funding for identity management must be understood to assure alignment with campus management overall.
Recommendations for Future Work
The group considered several potential activities for future work by InCommon, TIER, and/or community members. These are listed here.
1. Activities for the InCommon administration or TIER.
1.1. Deploy or contract for a fullyfunctionalfully functional, outsourced Shibboleth blessed by InCommon with InCommon participating in the management of the solution.
1.2. Establish a process for certifying IdP support vendors blessed by InCommon.
1.3. Create appliances for insourced operation including the CANARIE/SWAMID IdP installer tool with configurations prebuilt for InCommon. These would likely be distributed as virtual machine images.
1.4. Identify ways to facilitate InCommon members getting consultant help without a lot of administrative overhead. This might be combined with a mentor program.
1.5. Conduct outreach to those institutions that are not engaged in federation and would not know that alternatives for an IdP exist.
2. Community solutions with InCommon coordination.
2.1. Discuss ways to outsource an institution’s IdP to other InCommon members hosting the IdP.
2.2. Develop a mentor program for InCommon Members to help campuses get started.
...
- The Alternative IdP Strategies and Assessment Criteria (wiki page)
...
Appendix B: Alternative Identity Providers Working Group Contributors
Shaun Abshere, WiscNet
David Alexander, IDM Integration
Mark Beadles, OARnet
Steve Carmody, Brown University
Alex Chalmers, Ball State University
Dedra Chamberlin, Cirrus Identity
Emmet Culley, California Community Colleges
Lou Delzompo, California Community Colleges
Janemarie Duh, Lafayette College, Chair
Mike Grady, Unicon
Mark Jones, University of Texas Health Science Center at Houston
Scott Koranda, Spherical Cow Group
Chris Phillips, CANARIE
Ben Poliakoff, Reed College
Tom Scavo, Internet2
Mark Scheible, MCNC
David Walker, Internet2
Dan Zweifel, Washington University in St. Louis