Federated Identity: Broad or Strong?
Broad deployments of federated identity have arrived in the form of social login. But in 2013 we find federation on the horns of a dilemma; can it be both broad and strong?
Federated identity, especially in the form OAuth 2.0 resource access across multiple sites, is reaching broader populations of users, identity providers (IDPs) and relying parties (RPs) than ever. But assurance remains too low for many business applications. As described in “Piling on OAuth” standardization trends are pushing in multiple directions; proposals to add JSON Object Signing and Encryption (JOSE) may help assurance while other enhancements will not. For example, dynamic client registration will enable IDPs and RPs to establish relationships faster. But adding more speed and convenience for onboarding applications atop OAuth 2.0’s already-shaky foundation is not promising for the protection of the personally identifying information (PII).
Trying to balance equations of federated identity breadth and assurance raises yet more questions – let’s take these in turn.
- What alternatives to OAuth exist and when is it practical to avoid it?
- How much can OAuth 2.0 itself be tightened up to provide reasonable assurance?
- Can assurance issues be resolved at another layer through compensating controls?
- How much risk are businesses willing to accept?
OAuth 2.0 Alternatives
It’s easy to forget that like OAuth, Security Assertion Markup Language (SAML) and X.509 have a significant installed base. As I described in Back to the Future (of Federation), SAML remains the gold standard for browser-based single sign on in the enterprise environment and is supported by enterprise identity products and cloud service providers (CSPs) such as Amazon, Google, Microsoft and Salesforce. It has fewer insecure flows than OAuth and implementations tend to be more mature and built to higher standards.
Similarly, X.509 based federations such as the U.S. government’s Personal Identity Verification (PIV) card operate at higher assurance levels. When hybridized with SAML through “protocol transition” or “step down translators” smartcard users can leverage their high assurance authentication for single sign on to lower assurance systems, sites and applications. Enterprises and CSPs should continue using SAML and X.509 for their core use cases.
All this being said, OAuth 2.0 is still required to provide resource access users’ many sites. As a RESTful protocol, OpenID Connect sets a lower bar for implementation than SAML and adds interesting new features, such as self-issued claims and aggregated claims, that may be valuable for additional use cases. Newer standards are coming, such as User Managed Access (UMA), which will address authorization use cases.
Improving OAuth 2.0 Assurance
This is a critical point because other identity specifications such as OpenID Connect and User Managed Access (UMA) have been piling on, or building on, the OAuth 2.0 framework. As noted earlier, a number of standards efforts are working to improve the framework itself: these include JSON Object Signing and Encryption (JOSE), OAuth MAC Token Profile, OpenID Connect and UMA.
However, if an IDP or RP is deploying OAuth 2.0 today, it must work with what’s already here. In the following posts I already covered:
- OAuth 2.0 Assurance Issues identifies the insecure flows in the framework, such as TLS optionality and implicit tokens. It then proposes a three-pronged approach to securing the framework we have: profiling, testing and operations.
- Mitigating OAuth Security Issues with Good Profiling addresses the profiling prong, walking through OpenID Connect examples.
- OAuth 2.0 and RESTful Protocol Security Testing Challenges addresses the testing prong, describing some research on testsing methodologies, and it presents a call to action to the industry.
Compensating Controls
Compensating controls for insecure OAuth 2.0 flows can include:
- Use the OAuth framework’s existing native security features (optional TLS, pre-registration of redirect URLs, shortened timers on tokens) and new ones in the future such as Javascript Web Tokens (JWTs))
- Improve underlying device security, requiring two factor authentication or addressing weaknesses in account recovery processes
- Configure or code application business rules (access controls) and anomaly detection checks
- Impose rate limits, transaction size limits and sensitivity limits on the use of insecure flows
Risk Management
We don’t yet have a thorough study of business application tolerance for OAuth’s weaknesses. But indications are that when we get beyond social networking and into medical, financial, government and other industries, or even try to operate in jurisdictions that set higher standards for privacy, assurance issues can stop adoption in its tracks. At a minimum, organizations in those verticals will need to spend a lot of time on risk assessment and then on compensating controls just discussed. Having to do all that work up front over and over again isn’t conducive to broad federation.
Conclusion
Analysts typically divide federated identity challenges into two classes: technical issues and trust issues. This post has covered both types of issues, and has identified ongoing work on standards and profiles as well as proposing good practices for profiling, testing and deployment.
It seems to me that whereas the identity standards and development community have been very proactive on technical issues, work on trust issues lags a bit, being confined to forums such as the Open Identity Exchange (OIX) and government-sponsored forums.
In addition to improving the specifications themselves standards groups, CSPs and product vendors need to start working on the basics to address medium to high levels of assurance (LOAs). Those basics include functional testing and certification and vulnerability testing and disclosure – all things that are more or less non-existent in “the cloud.”
As an industry, we need to focus more on trust frameworks. Trusts need to be there, for federated identity to ever become both broad and strong.