Alternative IdP Strategies and Assessment Criteria
The following table outlines potential alternative IdP strategies to be considered by the work group, as well as potential assessment criteria.
IdP Strategy | Description | Fact Finder | Example Deployments (case studies) | Support for Recommended Technical Basics for IdPs (inc. ability to consume metadata) | Support for Attribute Release | Support for Entity Categories (R&S) | Support for Multiple AuthN Contexts for MFA and Assurance | Support for ECP | Support for User Consent | Expertise Required | Resources Required (amount of human resources) | Upkeep and Feeding Required | Applicable Environments | Pros / Benefits | Cons / Risks |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Integrated with the local IdMS and operated locally, the baseline for comparison | David/Janemarie |
| Yes | Yes | Yes | Yes, with the MCB add-on. | Yes | Yes, with uApprove or Privacy Lens add-on. | Expertise in the operation of Java-based services and XML, as well as general knowledge of federation. | Hardware resources are dependent on load, but are generally low. | Security patches and advisories for the underlying resources as well as keeping current on the IdP software itself | Shibboleth is highly adaptable to arbitrary environments. | Shibboleth is the mainstream SAML implementation. | Shibboleth requires specialized expertise to operate. | |
Microsoft's SAML implementation for Active Directory, operated locally | Scott Koranda / Alex Chalmers | There are a number of organizations in InCommon and other higher ed federations using ADFS. Ball State is a concrete example of InCommon member using ADFS. | Partial, assuming use of pysfemma software. | Yes, assuming AD LDAP is the attribute store. | No (not without third-party scripts such as pysfemma). | No | No | No | PowerShell and Python scripting, vocabulary knowledge translating InCommon to ADFS speak | Standard Windows admin, fair amount of time starting from scratch without mentor. Finding information to make it work. | Minimal. | Organizations that already are Windows/AD shops. | For shop that is Windows based, ADFS is natural approach to federation | Small inst. with limited resources but requires third-party tools, scripting, new vocabulary | |
An open source IdP written in PHP, integrated with the local IdMS and operated locally | Ben Poliakoff | [https://simplesamlphp.org/users | Yes, except for SAML V1.1 attribute queries. | Yes | No | No | Yes | Yes | PHP, knowledge of directory service underneath (AD, LDAP) since it's middleware; |
|
| non-Java-centric (little experience/no interest in hosting apps); PHP-centric (PHP hosting expertise and /or investment in architecture; interest in extending functionality by writing extensions and/or patches) |
|
| |
An IdP run on a locally-supported platform with vendor support for the IdP itself, assume to be Shibboleth here. | David Walker |
| Yes | Yes | Yes | Yes, with the MCB add-on. | Yes | Yes, with uApprove or Privacy Lens add-on. | Expertise in the operation of the hardware and operating system are required | Hardware resources are dependent on load, but are generally low. | The hardware and operating must be maintained. | Shibboleth is highly adaptable to arbitrary environments. | Can facilitate quick deployment of the IdP with operations for the long term. |
| |
Shibboleth, integrated with the local IdMS and operated by a third party | Mark Beadles | Fischer Identity; OARnet has schools doing this. Mark will check on them. | Yes | Yes | Yes | Yes, assuming configured by operator. | Yes, assuming configured by operator. | Yes, assuming configured by operator. |
|
|
| Nearly any since it is outsourced. |
|
| |
Outsourced Vendor IdP | A non-Shibboleth SAML IdP, integrated with the local IdMS and operated by a third party, such as Ping Identity | Dedra Chamberlin | Dedra has permission to release use case. | Yes, except for ECP endpoints in metadata. | Yes | ? (Not sure if it releases only to SPs with the R&S entity tag. - DHW) | Configured per SP. | No | On roadmap |
|
|
|
|
|
|
Hub and Spoke (or Trusted Third Party) IdP (Response assumes SimpleSAMLphp) | Likely used by systems such as community colleges, K-12, network providers, etc. 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. | Mark Scheible | Some European Federations - WAYF, FEIDE, SURFnet | Yes, except for SAML V1.1 attribute queries. | Yes | No | Multiple authentication methods can be specified in one configuration. | Yes | Yes | Limited expertise required for Campuses (Hub Operator needs SimpleSAMLphp and IdP Proxy experience) | Minor resources at Campus | Only upkeep of IDMS on campus (Source data and Directory) | State Systems (university or community college), K-12 statewide or regions. | Majority of work is done by the Hub Operator, so Spoke Campuses need few resources to participate. Some services such as User Consent can be centralized (at the Hub) | Likely some limitations on configurations for attribute release to SPs - may need common standards across all Spoke organizations |
Assessment completed after the final report | |||||||||||||||
Azure AD | |||||||||||||||
Assessment not completed | |||||||||||||||
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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CAS Gateway | A SAML-to-SAML gateway, often operated by a third party, for participants that use CAS for local authentication |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Google Apps Gateway | An OIDC-to-SAML gateway, often operated by a third party, for institutions that make use of Google Apps for Education | Shaun Abshere will investigate with respect to Cirrus Identity (vendor) |
|
|
|
|
|
|
|
|
|
|
|
|
|
An IDaaS option such as Google, Okta, or Stormpath where the institution uses identity data uploaded to the IDaaS which then functions as an outsourced IdMS. | David Walker (to explain why we decided it's out of scope) |
|
|
|
|
|
|
|
|
|
|
|
|
|
4 Comments
barkills@washington.edu
Azure AD is also an IdP that I'd want in your list, especially since it's likely to have a greater market share/use than ADFS in a very short period of time. It provides more protocol support than the most recent release of ADFS, has user consent features (unlike ADFS out of the box), and in concert with the recently previewed Conditional Access capability can provide MFA on a per SP basis (which isn't quite full support for multiple AuthN contexts).
I'd also note that ADFS can support MFA on a per SP basis (or on a variety of other conditions) via the Client Access Policies capability. This isn't reflected in the data above. That probably also isn't full support for multiple AuthN contexts, but it also shouldn't be only "no".
There's also Microsoft's ACS (Access Control Service) product that has been around for several years now, but it's actively being rolled into Azure AD, so probably best to leave it out.
Neither ADFS nor Azure AD provide assurance data, but I believe that is on their roadmap.
trscavo@internet2.edu
Brian, what protocols does Azure AD speak? In particular, can it function as an OpenID Connect Provider?
barkills@washington.edu
https://msdn.microsoft.com/en-us/library/azure/dn151124.aspx (Azure AD Authentication Protocols) is your friend.
OAuth 2.0
Open ID Connect 1.0
SAML
WS-Federation 1.2
David Walker
Brian, it's too late to add Azure AD to the final report (which was submitted to TAC and Steering in December), but I agree it would be good to add it to the wiki. Would you be willing to do that? I've created a space for in the table on this page, as well as a blank page for it from the template we've been using. The idea is to complete the template on the page, and then put a very brief summary into the table.