has been upgraded to Confluence 6.12.2. If you have any questions and/or concerns, please contact us at
Skip to end of metadata
Go to start of metadata

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


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

Shibboleth IdP (local)

Integrated with the local IdMS and operated locally, the baseline for comparison






Yes, with the MCB add-on.


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).




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.

Once it is deployed, it is extremely stable. Months can go by without having to touch it.

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

SimpleSAMLphp IdP

An open source IdP written in PHP, integrated with the local IdMS and operated locally

Ben Poliakoff

]Institutions listed using SimpleSAMLphp as an IdP:
- Technischen Universität Wien
- University of the Basque Country
- University of Málaga
- University of Zagreb

Yes, except for SAML V1.1 attribute queries.






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)



Insourced IdP with Vendor Support

An IdP run on a locally-supported platform with vendor support for the IdP itself, assume to be Shibboleth here.

David Walker





Yes, with the MCB add-on.


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.


Outsourced Shibboleth IdP

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, 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.


? (Not sure if it releases only to SPs with the R&S entity tag. - DHW)

Configured per SP.


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.



Multiple authentication methods can be specified in one configuration.



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)














Identity as-a-Service

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)














  • No labels


  1. 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.

    1. Brian, what protocols does Azure AD speak? In particular, can it function as an OpenID Connect Provider?

  2. (Azure AD Authentication Protocols) is your friend. (smile)

    OAuth 2.0

    Open ID Connect 1.0


    WS-Federation 1.2

  3. 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.