A Model for an Internet Identity Layer

April 3, 2008

The much discussed notion of an identity meta-system is of paramount importance to addressing the issues of de-perimeterization that are facing enterprises. I have personally found the definition of this identity meta-system a little fuzzy, beyond the fact that I know it has to support multiple protocols and technologies.


Given some of my background includes coding networking protocols and doing firewall architecture I actually prefer to think of the identity meta-system as an identity layer. This layer sits between the application and the network. An interoperable, secure identity layer is vital for addressing the security and privacy requirements that can be leveraged cost effectively and securely by all organizations.


I have used the analogy of comparing this new identity layer to the old OSI layered model of network architecture. The OSI model broke the network layer into multiple sub-layers. This allowed for a consistent discussion and comparison around different networking protocols that over time included SNA, DECNET, X.25, IPX/SPX, TCP/IP etc etc. It ended up being taught in Networking 101. The fact that over a 20 year period all networks morphed to support TCP/IP is irrelevant in light of the value this model provided in allowing for consistency.


This identity layer should consist of three sub-layers ? a claims sub-layer, a security token sub-layer and an identity transport sub-layer.. Each of these sub-layers are already generally included in the different standard and proprietary identity protocols that exists today. The problem I have found is that everyone tends to talk about these sub-layers only in the context and the language of the identity protocols they are endorsing.


Identity Layer


In summary,


? The Claims Sub-Layer is responsible for conveying user information such as authentication, attributes, roles, group, authorization decisions, reputation, etc. I like Microsoft?s use of the term claim as a catch-all name for all of this identity information. It allows for an expansion of what may be considered to be identity information that needs to be shared between applications at this layer. In addition this sub-layer is responsible for mapping claims between different schema formats and name spaces.


? The Security Token Sub-Layer is responsible for conveying the security tokens that contain the claims. This can involve multiple token types such as SAML tokens, Kerberos tickets, OpenID responses as well as proprietary token types such as SiteMinder SMSession tokens. In addition this sub-layer is responsible for mapping tokens between different token formats.



? The Identity Transport Sub-Layer leverages the network to moves tokens between applications. This sub-layer includes the different SAML Web SSO Bindings, OpenID Request/Responses, WS-Security/WS-Trust for web services, and even the WS-Trust profile for InfoCards. In addition this sub-layer is responsible for routing between different identity transports when necessary.


In addition, we have found that applications developers are spending far too much time concerning themselves with the lower levels of the identity layer. App developers need to be able to leverage a standard identity API interface that interacts with the claims sub-layer. The developer should receive all the information it needs via this API directly from the claims sub-layer. This information obviously manifests as claims and as such means that application, by default, must become claims aware. Today, this likely just means user attributes or a role value, but in the future this may include actual authorization decisions. Leveraging a standard API that allows an application to plug-and?play with the identity layer offers some future proofing as the identity protocols underneath change.


Lastly is the concept of identity routing which I think is extremely important if we are to avoid every application being forced to understand the whole identity mesh. The identity router is responsible for mapping between different formats at each of the sub-layers. This could mean attribute mapping at the claims sub-layer, mapping from SAML Tokens to SMSession tokens at the Security Token sub-layer or routing between WS-Federation and SAML at the Identity Transport sub-layer. An identity router consolidates where this has to happen. Again using a networking analogy, each application/system leverages an Identity Router which becomes the Identity Layer equivalent of a ?Default Route?. Obviously this is what I view as the role of our PingFederate product, but over time there is no reason why this Identity Router can?t be implemented as a service in the cloud.


Identity Rayer


So in summary, with apps, users and the data center becoming virtualized eneterprises must be able to support a decentralized identity infrastructure. To achieve this we think a secure, interoperable Identity Layer is paramount and that applications should be able to just plug & play with this identity layer. While the convergence of all these identity protocols on a single standard may be the ?holy grail?, the identity layer can allow for these identity protocols to at least be implemented independently from the applications. We at Ping Identity are focused on providing the infrastructure and services to make this Identity Layer a reality.