Description

I have not been able to get a hold of Bill T and Andy Petro to confirm the technology that is being suggested in this option, so I am going work with the common SAML interface that available in the JASIG CAS service.  That SAML interface has serious limitations that make it only practical to attribute delivery within the native CAS system.  Without a SAML based authentication mechanism it isn't clear to me how a Gateway would be able to effectively transport other SAML messages to provide a valuable service.  Any gateway service that is possible against this interface would certainly have significantly higher complexity than the other CAS option that is being considered.

If Bill or Andy have a moment to drop me an email on a more specific deployment that they are aware of, I would be interested in documenting it here.

Fact Finder

Example Deployments

Support for the Recommended Technical Basics for IdPs, including the ability to consume metadata

Support for Attribute Release

Support for Entity Attributes/categories (e.g., R&S)

Support for Multiple Authentication Contexts for Multi-Factor Authentication and Assurance

Support for ECP (Enhanced Client or Proxy)

Support for User Consent

Expertise Required

Resources Required

Upkeep and Feeding Required

Applicable Environments

Pros / Benefits

Cons / Risks

  • No labels

3 Comments

  1. trscavo@internet2.edu

    As noted, CAS/SAML has serious limitations, but apparently there is enough functionality for CAS to play the role of IdP to SAML-enabled Google Apps. If CAS/SAML can successfully interoperate with Google Apps, then it can successfully interoperate with a SAML-to-SAML gateway (sometimes called an IdP Proxy) where the SP side of the gateway emulates Google Apps and the IdP side is a reasonably full-featured SAML IdP. Presumably, metadata for the latter could be registered in the InCommon Federation.

    Given the fact that simpleSAMLphp has strong IdP Proxy support out-of-the-box, simpleSAMLphp would be a likely enabling technology but certainly not the only technology that could be used here.

    1. Brandon Saunders

      Thomas,

      I will tinker with it, but I am fairly certain that the CAS configuration in Google Apps is native CAS and would only leverage the SAML interface for attribute resolution.  So feeding native CAS to Google to function as an SAML IdP to upstream services would be alternative implementation to the other CAS option that is being discussed.  My interpretation of this option was a more pure SAML-to-SAML communication path.  Maybe I missed the point?

      Brandon

      1. trscavo@internet2.edu

        One thing you might want to do is discuss this use case with the friendly folks at Cirrus Identity. I'm pretty sure they understand the options better than I do.