By Paul Madsen
Federation is a model of identity management that distributes the various individual components of an identity operation amongst different actors. The presumption being that the jobs can be distributed according to which actors are best suited or positioned to take them on. For instance, when an enterprise employee accesses services at a SaaS provider, Single sign-on (SSO) has the employee's authentication performed by their company, but the subsequent authorization decision made by the SaaS provider.
Federation's primary underlying mechanisms are 'security tokens.' It is by the creation, delivery, and interpretation of security tokens between the actors involved in a transaction that each is given the necessary information to perform their function. Security tokens serve to insulate each actor from the specific IT & security infrastructure of their partners, customers, and others by standardizing how identity information can be shared across company and policy boundaries. Returning to the enterprise employ SSO example, after authenticating the employee, the enterprise creates a security token attesting to that fact, as well as additional attributes that might determine what actions he/she can perform at a particular SaaS provider (e.g., the person is in Engineering not Sales) and then delivers the security token to the SaaS provider. The SaaS provider, rather than directly authenticating the employee through some stored password, instead relies on the authentication performed by the enterprise, and acts accordingly.
SSO simplifies life for the employee because they do not need to manage a password for each SaaS application their job demands. Furthermore, SSO provides security benefits for the employer, such as being able to easily and quickly terminate access to all those applications should the employee leave the company. SSO arguably offers even greater value when the service being accessed is a mobile web application (i.e., delivered through the browser on an employee’s mobile phone). Data entry remains challenging on mobile devices, even more so when corporate password policy requires entering a mix of case and characters. If an employee is tempted to create (or reuse) an easy password at their desktop, then they will be doubly so on a phone.
The federation standards for browser-based SSO to web applications are well-established (if perhaps a bit duplicative) on the consumer web, with OpenID being the preferred choice. In the enterprise and cloud world, the Security Assertion Markup Language (SAML) is the default, with WS-Federation an option in Microsoft environments. SSO for mobile web applications works the same as for desktop browsers. The protocol messages and security tokens are delivered through the browser between the actors. The only potential difference is that the HTML served up may be optimized for the smaller screen and/or processing capabilities of the phone.
The popularity of the iPhone AppStore and Android Market in the consumer world highlights an increasingly important alternative to browser-based applications, Native applications have the user download and install the application to thier device; the application then interacts with servers to retrieve the data rather than rely on the browser. Both native and web applications have their pros and cons. A seeming trend toward the native model may well be reversed as HTML5 makes possible richer user experiences and device integration for web applications.
The native applications on the phone push and pull data from the server, typically through REST APIs. The IdM challenge for native applications is how the native application can authenticate to these APIs so that the API can make an appropriate access control decision. Security tokens provide a solution, offering similar advantages as they do for web applications. Critically though, the federation protocols relevant for web applications (i.e., SAML, OpenID, WS-Federation) are generally not optimized for the requirements, challenges, and opportunities presented by native applications.
OAuth 2.0 is a federation protocol, currently nearing finalization as an IETF standard, that can be optimized for just such native applications. OAuth emerged from the Consumer Web (an archetypical use case that of one website being able to post to a user’s Twitter stream) but has evolved to meet enterprise and cloud requirements. For mobile native applications, OAuth defines 1) how a native application can obtain a security token from an ‘authorization server’ and 2) how to include that security token on its calls to the relevant REST APIs. Importantly, OAuth supports the concept of the user being able to control the issuance of security tokens to native applications and so indirectly control the authorizations the native applications have for accessing personal data behind APIs.
Before OAuth, the default authentication model for native applications was the so-called ‘password anti-pattern’ in which the native application would ask the user to provide their password for the site hosting the APIs the native application wanted to call. Teaching users to share their passwords with arbitrary (and potentially untrustworthy) applications is less than ideal. OAuth mitigates the practice by having the native application authenticate to the API with a security token and not the password itself.
By abstracting away the particulars of each of their security infrastructures from multiple participants, and obviating the need for placing passwords ‘on the wire’, federation (and the more fundamental security token model) offers many benefits for both web (browser-based) and native (installed) mobile applications. Ultimately, an authentication and authorization framework for mobile applications should address the needs of both application models through support for the relevant federation protocols like SAML and OAuth.
Paul Madsen is a senior technical architect within the office of the CTO at Ping Identity. He has served in various design, chairing, editing, and education roles for a number of federation standards, including OASIS Security Assertion Markup Language (SAML), OASIS Service Provisioning Markup Language (SPML), and Liberty Identity Web Services Framework (ID-WSF). He participates in a number of the Kantara Initiative's activities, as well as various other cloud identity initiatives. He holds an MSc in applied mathematics and a PhD in theoretical physics from Carleton University and the University of Western Ontario, respectively.