...
The Group’s Approach
The Working Group began its work by identifying a number of alternatives that can be effectively deployed today. These alternatives are:
IdP Strategy | Description |
InHouse Strategies | |
Shibboleth IdP | Integrated with the local IdMS and operated locally, the baseline for comparison |
SimpleSAMLphp IdP | An open source IdP written in PHP, integrated with the local IdMS and operated locally |
ADFS IdP | Microsoft's SAML implementation for Active Directory, operated locally |
Outsourced Strategies | |
Outsourced Shibboleth IdP | Shibboleth, integrated with the local IdMS and operated by a third party |
Outsourced Vendor IdP | A nonShibboleth SAML IdP, integrated with the local IdMS and operated by a third party, such as Ping Identity |
CAS (local) with Outsourced IdP | A SAML IdP, either Shibboleth or vendor, integrated with the local IdMS and operated by a third party, that uses a local CAS deployment for authentication |
Google Apps Gateway | An OIDCtoSAML gateway, often operated by a third party, for institutions that make use of Google Apps for Education |
Insourced IdP with Vendor Support | An IdP run on a locallysupported platform, but with vendor support for the IdP itself. |
Hub and Spoke (or Trusted Third Party) IdP | Likely used by systems such as community colleges, K12, network providers, where individual constituents don't want to run their own IdP. The IdP is located at the Hub and users enter local credentials for authentication. Attributes are passed on from the home institution to the Service Provider. |
We also considered the following strategies, but did not do full assessments for the reasons given below.
● Identity as a Service. This is potentially a good strategy for an institution wishing to outsource its entire IAM system, but our group’s charge is restricted to IdP only.
● CAS Gateway. The group decided that this does not offer advantages over the “CAS (local) with Outsourced IdP” strategy.
Identity Provider Strategies for Common Campus Environments Page 4
● 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.
Identity Provider Strategies for Common Campus Environments
...
enhancements to SimpleSAMLphp), it is certainly a viable solution for institutions with currently simple needs for federation.
Outsourced Strategies
Outsourced IdP services for campuses that do not fit the environments mentioned above are becoming available in the marketplace from multiple vendors. They are based on various technologies, including Shibboleth, SimpleSAMLphp, and proprietary software. We expect the capabilities provided by those vendors to evolve rapidly. The following is a snapshot of some of those services.
Outsourced Shibboleth
There is currently a limited number of vendors that offer Shibboleth as a cloud service, most notably Fischer Identity and Gluu. There are schools within OARnet that are using Fischer Identity’s offering.
Campus Environments Based on Google Apps for Education or CAS
Cirrus Identity offers a SimpleSAMLphpbased IdP that can be configured to support campus IAMSs based on Google Apps or CAS; OAuth2, OIDC, and SAML are also supported. Cirrus Identity’s offering supports our criteria, except for entity categories, ECP, and full configurability of multifactor authentication; user consent is planned. This offering is certainly a viable option for campuses without a need to support ECP.
Insourced IdP with Vendor Support
In this strategy, the IdP runs on a locallysupported platform with vendor support for the IdP itself. The hardware and operating system must still be maintained by the institution, but this strategy can facilitate quick deployment of the IdP and its required Java environment with options for the long term. The platform can be oncampus servers or utilize cloud infrastructure such as AWS or Azure. A number of vendors provide such support services; the Shibboleth Consortium maintains a list at http://shibboleth.net/community/consultants.html.
State Systems
State systems and other higher education consortia may choose to use the Hub and Spoke strategy, an insource/outsource hybrid sharing a single IdP instance operated for the entire consortium, supporting multiple scopes to represent the distinct members of the consortium. Additionally, a Shibboleth “multiscoped” IdP may be a simpler alternative. Selection of the specific technology platform in this environment would be based on the same criteria as described above.Identity Provider Strategies for Common Campus Environments
Selecting a Strategy
Choosing an IdP strategy for an institution will be based on many factors, most very unique to the institution. The following decision tree is intended help navigate the options:
Prerequisites for the IdP Strategy
Independent of how IdP service is deployed for a campus, there are a number of other issues that campus must address.
Manage the IdP Service Offering
Even when operation of the IdP is outsourced, it is still necessary to manage the service offering and the vendor providing that service.
Identity Provider Strategies for Common Campus Environments
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 fullyfunctional, 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.
Community solutions with InCommon coordination.
2.1. Discuss ways to outsource an institution’s IdP to other InCommon members hosting the IdP.
2.
Identity Provider Strategies for Common Campus Environments Page 9
...
● The National Association of College and University Business Officers (NACUBO)
● Regional R&E network providers and The Quilt
● EDUCAUSE
● InCommon affiliated vendors (to tell their higher ed clients about
InCommon, as well as federating their own services. They would first need to see the value of federation)
Appendix A: Alternate IdP Strategy Assessments
The following are assessments of the various IdP strategies considered by the work group. These assessments are also available from the Alternative IdP Working Group wiki space at Alternative IdP Strategies and Assessment Criteria.
Shibboleth IdP (local)
Description
The Shibboleth Identity Provider software integrated with the local IdMS and operated locally is presented as a baseline for comparison of all proposed alternative solutions which are not set up, run, and maintained locally by a campus .
Fact Finders
Janemarie Duh (Lafayette College) David Walker (Internet2)
Example Deployments
Shibboleth is the primary IdP software used in R&E federations.
Support for the Recommended Technical Basics for IdPs, including the ability to consume metadata
The Shibboleth IdP can be configured to support all recommended technical basics.
Support for Attribute Release
Shibboleth can be configured to release any attributes supported by the IdMS. Attribute filter policies are set on the IdP to release attribute values and done so in a privacypreserving way.
Support for Entity Attributes/categories (e.g., R&S)
The IdP software supports the release of entity attribute bundles in fixed or dynamic subsets to all SPs or R&S SPs.The benefit of supporting attribute bundles is the decreased administrative overhead. An attribute is configured for the entity category.
Identity Provider Strategies for Common Campus Environments Page 11
...
Upkeep and Feeding Required
Once deployed, configured, and integrated with InCommon via pysfemma or the like, ADFS has a reputation for being stable and solid. It is known to scale well.
Applicable Environments
ADFS is used when the existing IdMS is Microsoft Active Directory (AD).
Pros / Benefits
Using ADFS is a natural approach for Microsoft Windows shops and the basic deployment and configuration will be straightforward for experienced Windows administrators. Once deployed ADFS is known to be stable and scale well. High availability (HA) configurations use standard Microsoft Windows server techniques and approaches for HA.
Cons / Risks
Integration with large identity federation environments like InCommon requires additional scripts and supporting infrastructure like pysfemma and a considerable learning curve to acquire the necessary knowledge to "bridge the gaps" between the InCommon environment and the peertopeer model or approach that is the norm for ADFS federation.
SimpleSAMLphp IdP
Description
SimpleSAMLphp is a lightweight IDP and SP implemented in (drumroll) PHP. Its development is sponsored/hosted by Uninett, a "state owned company responsible for Norway's National Research and Education Network."
Fact Finder
Ben Poliakoff (Reed College)
Example Deployments
https://simplesamlphp.org/users
Judging from the users enumerated on the above site, most production instances of this software are in European Universities, Federations, and companies serving those entities.
Support for the Recommended Technical Basics for IdPs, including the ability to consume metadata
SimpleSAMLphp supports a subset of the features of the Shibboleth IdP:
● Automated consumption of SAML metadata
● Scope in metadata
● x509 certificates in metadata
Identity Provider Strategies for Common Campus Environments
Page 16
● SAML V2.0 Web Browser SSO
● Authentication requests via the SAML V2.0 HTTPRedirect binding, the SAML V2.0
HTTPPost binding, and (optionally) the legacy Shibboleth 1.x AuthnRequest protocol
● ECP with a third party patch (not well integrated or tested)
● Does *not* support SAML V1.1 attribute queries
● Endpoint protection protected with SSL/TLS optionally
● Also supports establishing an IdP Proxy.
Support for Attribute Release
The software does support sophisticated attribute filtering, release (including consent, using the bundled consent module).
Support for Entity Attributes/categories (e.g., R&S)
Not currently supported, this is an open issue:
https://github.com/simplesamlphp/simplesamlphp/issues/49
Support for Multiple Authentication Contexts for MultiFactor Authentication and Assurance
The IdP software is quite flexible and extensible, supporting multiple authentication methods (LDAP, Radius, various databases, OpenID, Yubikey, etc) and multiple factors.
I'm not certain about "Assurance".Support for ECP (Enhanced Client or Proxy)
ECP is supported with a third party patch, not widely implemented.
Support for User Consent
Supported with a bundled extension, https://simplesamlphp.org/docs/stable/consent:consent Expertise Required
Experience with the deployment of PHP applications is required, including the maintenance and management of associated web server software (Apache, Nginx, etc)
Resources Required
The service itself is quite lightweight, serving as middleware, requiring a web server that can serve PHP. There is, of course, an implicit requirement for a local IdMS. The software is most commonly integrated with LDAP directories.
Upkeep and Feeding Required
As with any of the locally hosted IdPs, the software itself needs to be kept up to date. Additionally the underlying web server must be well cared for.
Identity Provider Strategies for Common Campus Environments Page 17
...
Cons / Risks
The IdPinstaller is available in a 'global' configuration and configurations for Canada (CAF) and Sweden (SWAMID), but none are available for inCommon.
While not difficult, no 'lead' or champion in the US space has voiced interest to craft the inCommon 'build' and CAF would be interested in identifying an interested person or group. Guidance on configuration can be provided if some wishes to self identify as interested.
There are two discrete areas for configuration Shibboleth and eduroam and tailoring the configuration is not difficult but inCommon specifics are needed for such an action.
Identity Provider Strategies for Common Campus Environments Page 30
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