Agenda

After so many years of conflict, the war in between authentication protocols finally ended. While there is no clear winner, the only three survivors (SAML2, OpenID & InfoCard) have established an informal "armistice", where each claims to be more complementary than competitors. The industry, as well as customers, can easily sustain three protocols. Today any significant software implementation bridges the remaining protocols seamlessly. While this scenario may not be perfect, it seems "good enough" to do the job.

Nevertheless, we should not forget that seamless authentication is not our end goal, it is only the entry door toward the next generation of identity enabled architecture. As a result, the authentication protocol "armistice" is only an open gate that allows us to move forward. While authentication is a "MUST HAVE" technical feature, it does not provide any added value to applications and to endusers. To enable applications to make identity aware decisions (ex: grant access, personalized contend, custom value for transactions, …) is to also make authentication is useless. What we need is personal attributes hidden behind a given user's identity. While authentication is the entry door that allows attributes to be searched, it does not provide the true solution that we seek.

In a distributed environment, like the Internet, users attributes are spread out in many different locations (ex: banks, governments, telcos, socialnetworks, …). Furthermore, for a given user, those locations may change (not everyone has the same bank !). To make the scenario even more complex, different locations may hold different values for the same attributes (ex: your postal address).

The goal of attribute centric architecture is to enable applications to discover attributes for a given user. This allows applications to make the right decision, at the right time, for the right user. While the technology needed to build this attribute centric vision in a distributed environment is more or less available, it still imposes significant changes in existing IT architectures. First, the security model should move from a “channel model” toward a "message model". Additionally, applications should expect to dynamically discover the source of an attribute and stop making the assumption they must have a local copy. Last, but not least, applications should have a mechanism to rate the authenticity of the received attributes to an assurance level that is compatible with the requested operation. Applications must do all of this, obviously, without forgetting the systemic identity constrains attached to a modern distributed environment (privacy, userconsent, security, scalability, interoperability, …).

OpenID has gained significant popularity as an Internet identity system. Nonetheless, its adoption has been limited by usability and security issues. It has been widely speculated in the community that one of the ways that we can make OpenID more usable and safer is with the introduction of an active client to assist the user with his logon experience. In this session, we will describe the results of a community collaboration to develop an experimental multi-protocol version of Windows CardSpace that enables end-users to bring their OpenIDs to web sites. The session will also provide an update on the work being carried in the OpenID Community on the next version of the protocol.

The traditional concept of an in-house data center behind a static corporate firewall is history once and for all. The enterprise is now in full embrace of dynamic applications provided and scaled by dedicated cloud service providers. To innovate faster, regain control, and compete in a new world that is shifting from a "need to know" to "need to share" paradigm requires a new focus on security and authorization in a dynamic perimeter. This dynamic perimeter spans hybrid models that seamlessly mix local applications and cloud services. This is irrelevant to the end user – they need SSO and AuthZ based on their need to share regardless of where the app is delivered. Administrators shouldn’t be forced to duplicate ids in the cloud – they want to maintain authoritative ids and policies from centralized decision points. And service providers do not have the expertise or desire to manage security. Service Gateways when combined with ABAC Attribute-based Access Control engines deliver a ready on-premise or cloud outsourced service to regain control of security within the virtualized data center.

One of the many advantages of claims-based architectures is that they abstract away the details of their components, including where things are hosted. As long as services and identity providers are network-addressable, they can live on-premises and in the cloud and easily move between the two environment without changing the emerging properties of the system. The immediate advantage is that existing identity providers, typically on-premises, are readily available for the new applications in the cloud; on the long term, claims-based identity is a key enabler for incorporating the choice of deploying to the cloud in your current arsenal of IT tools. With claims-based identity, the cloud requires no special arrangements: things can fluidly move from distributed to centralized, following your own requirements and management style.