...
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 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 CAS Gateway. The group decided that this does not offer advantages over the “CAS (local) with Outsourced IdP” strategy.
- 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
Applicability of the Strategies to Campus IT Environments
The following sections discuss the applicability of these strategies in multiple campus environments.
In-House Strategies
Operating an IdP inhouse provides the greatest control and flexibility to a campus. That, however, comes at the price of infrastructure and of recruiting and retaining staff with the necessary skills. The following are recommendations for different types of campus environments.
Java Capable Campuses (with a Linux affinity)
Shibboleth is the gold standard for SAML implementations, both IdP and SP. It supports all of our criteria, with the addition of plugins, and is highly conformable to many computing environments. Shibboleth does, however, require specialized knowledge of Java application containers (e.g., Tomcat or Jetty) and XML that may not be among the core competencies of many IT organizations in higher education. Multiple WebSSO systems, such as CAS, can be integrated with Shibboleth. While such containers can be run on top of any operating system platform, the Shibboleth community is largely Linuxcentric, so it is helpful to be able to “speak Linux.” For IT organizations with that expertise, Shibboleth provides the greatest flexibility for adapting to changing requirements in the future.
Active Directory Centric Campuses
For campuses with identity management based on Microsoft’s Active Directory, ADFS is a potential alternative to Shibboleth, particularly when Java is not a core competency. It satisfies today’s basic requirements for federation, assuming the deployment of open source scripts. ADFS does not, however, have support for coming requirements like configurable multifactor authentication, ECP, and user consent. For this reason, a local implementation strategy to use ADFS should be considered transitional, perhaps with outsourcing as a longterm strategy.
LAMP-capable Campuses
SimpleSAMLphp is a potential alternative for campuses with a LAMP (Linux, Apache, MySQL, and PHP) infrastructure. SimpleSAMLphp supports most of our criteria, with the exception of entity categories, configurable multifactor authentication, and old versions of the SAML protocol. While an institution using SimpleSAMLphp should continue to monitor for longterm strategies with increased capability (perhaps as
Identity Provider Strategies for Common Campus Environments Page 6
...