Jump to:
This article offers implementation tips and advises to software makers who wish to produce software solution that integrate well with federated single sign-on (SSO) identity providers in the InCommon Federation.
Research and education (R&E) identity federations worldwide, including InCommon in the United States, use SAML as its federated single sign-on protocol. Creating InCommon-ready software starts with supporting SAML. However, unless your software's primary purpose is to implement the SAML protocol stack, we strongly suggest adopting one of the existing InCommon-ready SAML implementations rather than building your own. These software reduce and/or eliminate the effort required to create and maintain customer code to handle the nuances of SAML protocol suite and to support the various federation integration profiles.
See: Available SAML Implementations.
Whether you build your own SAML software or not, an InCommon-ready software needs to allow its deployer to configure the software to properly interact with identity providers in the InCommon Federation using federation-endorsed integration profiles and practices. In particular, an InCommon-ready software should cover the following areas:
Whenever possible, adopt a SAML 2.0 implementation that has proper support for requirements outlined in the Kantara SAML V2.0 Implementation Profile for Federation Interoperability. If you are writing your own SAML implementation, see Build Your Own SAML Software.
A major benefit of participating in the InCommon Federation is that InCommon offers a trusted and scalable way for identity providers and service providers exchange service metadata and cryptographic keys. By consuming SAML metadata from the InCommon Metadata Service, service operator can automatically detect changes from any participating identity providers and dynamically update configurations. An InCommon-ready software should be able to consume an identity provider's metadata from the InCommon Metadata Service.
See:
<basically, make sure your software or the SAML module you choose can be configured to map/consume federation attributes>
<provide SP-specific considerations when working with user identifier, including multi-lateral federation concerns (there might be multiple IdPs involved.>
These are a few examples of available SAML implementations:
If you decide to write your own SAML implementation, to ensure your implementation will work well in the InCommon Federation, make sure your software conforms with the Common Requirements and Service Provider Requirements of the Kantara SAML V2.0 Implementation Profile for Federation Interoperability. Published by the Kantara Initiative, the SAML V2.0 Implementation Profile encompasses a set of software conformance requirements intended to facilitate interoperability within full mesh (multilateral) identity federations, such as those found in the research and education sector, including the InCommon Federation.
Further, check out Kantara SAML V2.0 Deployment Profile for Federation Interoperability. Where as the Implementation Profile is written for software makers, the Deployment Profile helps service operators deploy InCommon-Ready services. Your software should allow a service operator using your software to fully conform with the requirements in the Deployment Profile.
Kantara SAML V2.0 Implementation Profile for Federation Interoperability (fedinterop) →
Kantara SAML V2.0 Deployment Profile for Federation Interoperability (saml2int) →
OASIS Security Assertion Markup Language (SAML) V2.0 →
Get Help
Can't find what you are looking for?