SAML and Standard Profiles

While SAML is relatively well-defined compared to many protocols, there still remains tremendous leeway for the developer of software or the implementer of a SAML-based SSO system to get creative.  Establishing connections between IdP’s and SP’s that live outside different SSO “ecosystems” has become challenging because of the wide variety of ways SAML has been interpreted.

Signet team members have both contributed specifications to the SSTC, the body under which SAML is governed, and chaired the committee.  Beyond that, we have far more extensive practical experience wiring SAML implementations together or applications to SAML.  This allows us to quickly spot interoperability issues or suggest shims that will make connection possible between different universes that both have SAML stickers on the box.

Our talent and history with SAML allows us to quickly and accurately diagnose interoperability issues.  Contact us if you’ve got a challenging integration and we’ll get the wiring done together.

If you prefer to do it yourself, we also offer some general suggestions that will guide you towards a more manageable deployment.

 

Basic SAML Guidance

A federated identity transaction starts either when the user is redirected to a home IdP after attempting to access an application or by transiting some style of portal through IdP-initiated SSO. The user authenticates as appropriate, after which authoritative user data is pulled and asserted about them. This information is packaged in a signed, encrypted SAML assertion.

Assertions are generally short-lived tokens generated dynamically each time a user wants to create a session at a service provider. Each assertion conveys zero or more attributes about the user and how authentication occurred. The two widely used profiles are the Web Browser SSO profile and the ECP profile.

Each IdP and each SP are identified by a unique string known as an entityID, which technically must be a URI. URLs are typically used in practice, as namespaces are already allocated and URLs can be resolved. Regardless, most software implementations treat the entityID as a plain string.

Authentication and Discovery

Correctly identifying users requires getting them to the right IdP. There is incredible diversity in ways to do that to accommodate different user experiences and interface integrations. Discovery is worth any provider’s understanding.

Discovery is necessary only under the presumption that the user, as most do, went directly to the resource they want. If you have the luxury of channeling your users through some style of portal, then the choice of IdP is implicit, and you can send an unsolicited login attempt straight at the service. SAML accommodates both modes of interaction well.

Multi-Factor Authentication (MFA)

MFA rapidly became an obvious online security requirement as the true extent of phishing and account hijacking emerged. Reassociation of an account with the correct individual can be a difficult process and there may have been significant consequences from the breach.

In specification, an SP is responsible for requesting authentication of sufficient quality to meet its needs. In practice, IdP’s often find themselves enforcing authentication requirements by themselves.

The implementation process for MFA is relatively technically straightforward, although it depends on the application you’re integrating with and the business requirements that you need to meet. It’s much more challenging to craft a successful outreach campaign to users and associate them with second factors. Common priorities for MFA are ssh/RDP, VPN’s, and systems that contain highly sensitive data.

Attributes and Authorization

An identity provider has no real way of advertising the attributes that it is able to support or willing to release in any given transaction. It also can’t identify associated services, such as privilege management systems. As a result, the IdP must be the primary interface through which data flows to ensure a consistent user identity.

As a service provider, please bear in mind that attribute requests are just that: requests. Every IdP is the ultimate arbiter of which attributes it will release to each SP. You should architect your application to require as few attributes as possible and support as many attributes as practical.

Account Provisioning

While it’s not really a formal function of the IdP, provisioning can be done using Shibboleth, and it’s a core access management responsibility that every organization must support in many flavors.

Applications get a better deal. It’s ideal if your application can provide full service to federated users without persisting any local user representation. If your application can do so, then you don’t need any provisioning and you can move to the next section.

Establishing Trust

The exchange of metadata establishes trust in SAML, and federated identity hinges on the trust relationships between providers. Each IdP must know the SP with which it transacts and vice-versa. This is accomplished through publication of metadata that describes the provider itself: thus, an SP would load the metadata of all the IdP’s with which it interacts.

The actual metadata exchange must happen out of band and this exchange is the act when trust is established. It can be accomplished through bilateral exchange, federations that serve specific communities, or broader federations at large.

SAML provides great leeway to the deployer within the Web SSO Deployment Profile to encrypt or sign particular elements. There are definite reasons to prefer encryption of some messages but not others, as well as signature of different parts of the SAML response.

These general recommendations apply to virtually all applications and implementations of SAML, but you will often be encountering implementations that have limited cryptographic capabilities and you may need to downgrade to meet their needs. Sign with SHA-256 whenever possible.

Subjects and NameID’s

Some software treats the Subject field of a SAML assertion as a special attribute, elevated beyond the others to primary identifier status. Others use it for session maintenance. You will often need to customize the NameID generation for a relying party, and sometimes do so without inflicting collateral change on other services.

Other software treats the Subject as simply another attribute, and the selection of a primary identifier, if necessary, is made from the entire pool of attributes available, including the NameID. This is preferred because of all the nuances surrounding identifiers. As an application, it’s best to be as liberal as possible in the NameID’s you are willing to accept, and don’t specify requirements that you don’t actually have. In many cases, a transientId with appropriate attributes will suffice.

Personal and Administrative Logout

The best thing about SSO is that there are so many login sessions to choose from. When a user accesses a federated resource, they frequently acquire sessions at the IdP, the SP, the application, and possibly more.

Logout must be split into two functional categories: administrative logout, where systems administrators need to disable a user’s access pronto, and personal logout, where it’s not clear what that logout link means to a user in a federated world.

While today’s federated identity solutions handle logout poorly, it’s becoming an operational requirement and a simple implementation can suffice today. Learn the many ways you can attempt to clear all the sessions, some of them, or inform users that logout is their responsibility.

Non-Browser Access

Be understanding of session management and caching, as applications will often persist sessions long past the point where a user can no longer login. Enforcement of MFA for non-browser access to crucial old services such as email is another fascinating use case.

It’s difficult to make specific recommendations due to the great variety of protocols, APIs, and applications in the world. As long as your interfaces are only intended to be used by clients that you develop, then you can pick the most appropriate integration for your application. We make our best suggestions.

Debugging Failed Transactions

Implementations of SAML software follow the specifications to varying degrees and parts are open to interpretation anyway. Even once parties collaborate and identify what the problem is, it’s not always agreed what the resolution should be. While the issue could be on their end, the fix could still well end up on yours.

We’ve provided a few helpful hints that can get you started debugging basic SAML interoperability issues. Signet is eager to assist when you can’t spot a problem or solve it on your own.