The Key Philosophy
Identity management and access control do not exist in a void. They aren’t interesting in and of themselves. If you work from the ideas that come with software or a service out of the box, then the software has defined the box your organization has to operate within.
Look in the mirror instead. Identity becomes enabling when you start with your people and the tools they need. The rest is configurable.
Identity data is among the most complex and sensitive information for any enterprise. It’s also turbulent, handling invidual changes, organizational changes, affiliates and VIP’s, personal changes such as new legal names, and even societal changes. Knitting together the underlying data is the most challenging part of building a functional SSO infrastructure, and a unified representation of your people is the cornerstone of any identity solution.
Services need to carefully match inbound identity assertions with any internally managed identity data. The tandem use of a human-legible identifier and a distinct, opaque identifier for that specific user is often employed to detect reassignment of the legible identifiers. Make sure enterprises can accurately identify their users by offering limitations on users’ customization of their displayed names or other fields. Be prepared to handle immediate session termination requests.
Enabling an application for SSO is an applied art that requires addressing a handful of specific challenges. Identification of users and access control decisions are often core parts of application functionality buried deep within implementations. The essential question is how much of this functionality to replace or integrate, and the means by which to do so.
Many creative approaches exist, but the most common by far are rewiring applications that were architected well and have identity functions well confined or simply building shims or gateways that serve as intermediaries in a federated transaction. The user will land here prior to the real session creation point, and some sort of translation occur to render the identity data in a form more palatable to the application. Another redirect then uses this interpreted data to actually build the session.
Be mindful when enabling applications for federated identity. It’s very easy to accidentally introduce significant vulnerabilities if you’re not cautious.
When you interact with cloud applications or identity sources outside your domain, federated identity becomes a necessity. The protocol definitions themselves are of little help because they’re so general and full of should’s. You can expect entirely different behavior out of SAML or OAuth providers, even if it’s the same software package. We prefer to use flexible implementations when possible so that the policy and objectives of the organization drive the process rather than the software’s limitations.
There are many SSO systems that have been widely adopted, and they’re mostly differentiated by target audience. Some focus on quick integration of internal services, others give the deployer maximum leeway in design and development, and still others rely on social identity providers. Choosing the right software packages for your environment is challenging with the plethora of offerings in the marketplace.