Identity Landscape

From OpenLiberty.org Wiki
(Redirected from RelatedProjects)
Jump to: navigation, search

Contents

Introduction

There has been a lot of discussion about the shape of the identity landscape for a while now. On this page we are trying to create a map of existing technologies, try to find a unifying mechanism to characterize these technologies and systems, and discuss social, regulatory and business aspects of them. In addition, we list known open source projects and commercial products that are relevant in the identity landscape.

This paper is licensed under the Creative Commons Attribution License 2.5. Please see the section on licensing at the end for details.

Goals and Scope

The goal of this paper is providing an overview and a "map" to the emerging identity landscape. In order to achieve this, we develop a system to classify and evaluate existing identity systems and emerging technology. Based on these findings, we discuss policy, business, and regulatory ramifications of a decision for or against a particular identity system or technology.

In the second part of the paper, we identify current solutions and present their benefits. The intend is here to give stakeholders of particular solutions to provide a space to present their solution, as well as give other parties to comment on the relationship of that solution to others. This section will also cover organizations and community efforts focusing on identity, as well as technologies such as specifications and open protocols.

Throughout the paper we will often not discuss the particular subject in all detail. Instead, an introduction will be given, as well as links to more information.

Audience

Technology professionals interested in getting a better understanding of the current trends in the identity community are the primary audience for this paper. This includes IT professionals and decision maker in enterprises, students and researchers, and open source developers. Policy decision makers in regulatory bodies will also find this paper quite useful.

Terms used in this Paper

The field of identity technology is not really new, yet there are a lot of different terms being used thoughout the various projects and technologies. In this short section we will define some terms and explain how they are used in this paper.

Authentication (AuthN) 
Authentication is the process of confirming a particular digital identity - a party that claims to be itself provides some sort of proof. The type of proofs are quite different. Typical examples include pre-shared secrets (e.g. username/password), access to cryptographic private keys (e.g. certificates), access to special tokens (e.g. one-time password cards), or ownership of internet resources (e.g. by putting data at a specific web location).
Authorization (AuthZ) 
Authorization is the process of evaluating identity attributes (such as e.g. email address or manager role) and making an access decision based on the value of such attributes. In most cases authorization requires initial authentication, so that the identity attribute information can be trusted.
Deployment (of an Identity System)
This term is used to identify a particular deployment of an identity system.
Identifier
Digital Identity 
A Digital Identity can be thought of as a "bag of attributes". These attributes can be very different between identity systems and may or may not be guaranteed (i.e. cryptographically signed) by someone. A user may have more than one identity, such as e.g. a corporate user account, an internet email login, a credit card account, or as a mobile phone subscriber. A Digital Identity can be created on the fly when a particular identity transaction is desired, or persisted in a data store to provide a referenceable representation
Identity Provider (IdP)
Typically a service on a network that has a user database and offers to verify authentication to Relying Parties. Quite often IdPs can also provide additional identity information (attributes) about their users which in turn can be used in authorization decisions. Different identity systems sometimes have another of different names for the IdP, such as e.g. Secure Token Service (STS).
Identity System
A set of technologies that enable the management of digital identities. This includes specifications, protocols, schemas, sometimes code, and best practices. Note that "Identity system" in this paper does not refer to a deployment, or even a particular implementation.
Relying Party (RP) 
A service or web site that trusts an Identity Provider to authenticate a user on its behalf. Again, different identity systems may have different or additional names for RPs such as e.g. Consumer (of an IdP).
User Agent 
The software that acts on behalf of a user. For internet transactions this is quite commonly a web browser, which is often referred to as a "dumb" client. A "smart" client is most often some software specifically tailored to a particular application. Quite often a smart client provides more or better functionality than a browser client.

It should be noted that these definitions are not necessarily shared by all stakeholders in the identity community. Sometime different terms are used for the same idea, and sometime the same term is used with differing semantics. While this is unfortunate, it is somewhat unavoidable in a relatively new field like digital identities. For a lexicon of some terms, as used by the Identity Gang, see their lexicon. Another excellent source for definitions is the Liberty ID-WSF 2.0 Authentication, SSO, and Identity Mapping specification, Section 3. "Terminology".

Identity and Technology

In this section we are trying to develop a model that can be used to characterize identity systems and technologies. The basic approach is to define a number of basic qualitative parameters and an (extensible) list of features that can be used to describe the capabilities of a given system.

This approach is not universal and there are many other ways to do this. For example, Kim Cameron formulated the "Seven Laws of Identity" that deal with user-centric aspects of identity.

Parameters of Identity

Identity is a very multi-faceted problem. Trying to squeeze the different aspects of digital identity alone in a small number of principles will invariably result in errors of omission and oversimplification. However, in order to be able to classify and address the issues with digital identity, it is useful to abstract from the complex problems associated with identity and introduce a few simple parameters that can help in classifying the various applications domains and aspects of identity systems.

Different identity systems have different characteristics, some of which have profound impact on how the system works, while others are of minor importance. For the purpose of this article we propose a set of first order parameters that determine some of the principal aspects of identity:

  1. Number of Attributes
  2. Scope (Application Scope and Centralization)
  3. User Control

A fourth parameter that seems quite useful, particularly in the classification of existing systems is the extensibility of an existing system.

Fundamental Parameters of Identity

When evaluating a given identity system it is critically important to distinguish between the capabilities of a given technologies and how they are deployed. For example, one given identity technology might be capable of storing an arbitrary number of freely defined user attributes. However, a simple deployment could restrict the number of attributes to a very small number. As such, for the deployed system, the parameter "Number of Attributes" would be quite small. During the lifetime of such a deployment this could easily change by populating or defining more attributes.

Fundamental Parameters

The idea behind defining abstract qualitative parameters is reduce some of the complexities within identity systems to a preferably small aspects that can be evaluated in a straightforward way. The selection of these parameters in this paper is somewhat arbitrary and not necessarily ideal.

Scope

Identity systems differ significantly in scope: there are application specific systems, that are only work with that application, and others that are designed with a very far reaching, sometime global scope in mind. Obviously, a local system is typically by far less complex than a global, federated system, that aims at providing a unified approach to identity across a large variety of applications are locations.

Content

While some systems deal only with a small number of attributes (like e.g. an email address or a username handle) many systems that are intended to be used with a wide scope in mind will hold many more attributes. In complex systems, these attributes are not necessarily stored at a central location like a directory or a database. In fact, many systems will depend on a variety of authoritative/trusted and non-authoritative/non-trusted data sources. This can also include storage locations that are with the user of the system.

User Control

The extent to which a user can exercise control over his data is very important in the context of privacy and also regulative requirements. While users of distributed applications like e.g. online retailers might want a very high level of user control in order to limit the risks of identity theft or misuse, highly regulated industries such as healthcare will have to use identity systems to create a non-reputable audit trail.

Extensibility

All identity systems that are supposed to be used for more than a single application must be designed with some extensibility in mind in order to allow the enablement of interoperability.

Features

Features within identity systems really define the capabilities of a given system.

Attribute Schema Extensibility

Systems with this feature do not have a fixed attribute schema, but instead allow arbitrary attributes to be included. Many systems that do allow this put no limit on the number of attributes that can be defined.

Limited Attribute Schema Extensibility

Some systems provide a limited number of "User Defined" attributes in their schema that can be used for storing additional information. In all such cases the type for these extension attributes is fixed and cannot be changed.

Single Sign In

Typically for identity system (and - in fact - a motivator for many of them) is the capability to require only a single login. All further resource access to systems participating in the deployment of the identity system will be authenticated and - as policy permits - authorized.

Single Sign Out

This feature is the inverse of the Single Sign In feature: it allows a user to sign out of an entire deployment.


Derived Parameters

Security

Security itself is typically realized through cryptographic mechanisms. Such mechanisms can change over time, since their strength and capabilities depends on available resources and algorithms. The security of an identity system – in particular a system that is designed to last for a long time – will depend on its extensibility and ability to accommodate new security technologies.

A more general view is that here security is an assessment of various trusts: to crypto science that underlying mathemtics are invincible, to crypto software that it is correct and not tampered with, to hardware that it is reliable, to certificate authorities and registration officers that certificates are properly managed.

Consistency

Scope / Centralization

Privacy

The level of privacy that a system allows for is directly related to the capability of the user to control the flow of identity attributes and the number of attributes. For example, a simple system that requires the user to share the first letter of his birthplace in order to get access to resources will offer a higher level of privacy than a system that requires the user to disclose name, address, telephone number and birth date to a limited number of individuals.

Interoperability
Platforms
Protocols
Policy
Level of Assurance

Many deployments are deeply concerned about codifying and expressing the degree to which identity and attributes can be "believed" by the relying party, based on the credential management, processes, and policies of the asserting party.

NIST 800-63

This is a government publication that attempts to synthesize many aspects of identity systems into a simple linear scale. http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

Identity Domains

Based on their different aspects, identity systems are useful or typically used in certain types of applications. E.g. in Web 2.0 applications (like blogs, wikis, etc.) identity systems have typically only a very limited number of attributes (often only an email address), but a very high degree of user control. On the other hand, federation systems like e.g. the Liberty Alliance have a large variety of user control and contained attribute information, but usage only makes sense on a fairly global scale.

Identity Domains

There are a number of typical identity domains that are quite common:

Application Centric Identity

Applications have (and probably always will) maintain their own identity system or authentication database. To a certain extent, even operating system user databases can be considered application specific identity systems – their usefulness obviously depends on how the contained identity information can be used elsewhere. Isolated Identity When the extensibility is low or non-existent in a given application centric identity system, it is effectively isolated from all other applications.

Enterprise Identity

As soon as computers obtained the ability to network – i.e. essentially with the advent of IBM’s S/360 class mainframes – enterprises and large organizations started to create their own identity systems. At first, the number of attributes was quite limited. But with directory technology starting to become a reality in the early 1980s, organizations extended the amount of information immensely. Today, enterprise identity systems are typically large and complex federations of different attribute sources that contain a huge number of attributes on employees, business partners, customers, and inventory. Managing such extensive federation systems often requires a lot of effort and resources, particularly since stricter guidelines on identity auditing are being mandated by regulatory bodies. Problems

  • different regulations regarding accounting, auditing and privacy across the world
  • proper backup and disaster recovery
  • integration of users other identities, e.g. in private life etc.

User Centric Identity

User centric identity systems (such as e.g. Windows CardSpace) are aiming at enabling the user to take a larger control of their digital identities. As such, user control has to be very high, by definition. User centric identity system can have a broad variety of scope and the contained information. The Web 2.0 centric OpenID system has typically a fairly small number of attributes, but is used best across simple, “low profile” web applications.

Social Networks

User centric identity systems have the potential to allow the accurate modeling of social networks of users in real time. To enable this, the system must allow the user to edit their own identity information – specifically all information on how he relates to other users in the system. This can be achieved e.g. by maintaining lists of links and related meta data about these links.

Network Identity

All previous identity systems play a crucial role in their respective domains. But without a high degree of extensibility, there are doomed to stay fairly isolated from each other. Network identity systems are explicitly designed to be able to bridge the gap between existing and emerging identity systems.

Distributed and Federated Identity

Relation to Other Characterizations

Identity Gaps and Exposures

?How do todays identity artifacts expose individuals to privacy breaches, etc.

The Seven Laws of Identity

  • User Control and Consent
  • Minimal Disclosure for a Constraint User
  • Justifiable Parties
  • Directed Identity
  • Pluralism of Operators and Technologies
  • Human Integration
  • Consistent Experience across Contexts

Social Aspects of Identity

Real Identities vs. Digital Identities

Privacy

Social Networks and Reputation Systems

Business Problems

Regulatory Requirements

Existing Identity Systems

Protocols

Liberty Alliance

WS-* Protocols

SAML

OpenID

Convergence Efforts

Liberty and WS-*

Microsoft's Windows CardSpace is already using SAML 1.1 tokens, a central asset of the Liberty identity infrastructure. While it remains unclear if Microsoft will be upgrading to SAML 2.0, there is hope in the industry that a revision of the core WS-* federation and identity protocols will incorporate new advancements in SAML.

Already, CardSpace is proving to be an authentication method that integrates easily with existing federated identity systems. For example, Martin Gee of ICSynergy announced in January 2007 the development of a CardSpace AuthModule for with Sun’s OpenSSO.

The hope that an even deeper integration of Liberty and CardSpace can be achieved was also expressed by Kim Cameron of Microsoft in a 2007 interview:

"[InfoCard] is not positioned against Liberty. I am an admirer of Liberty. Liberty has done a lot of great things around policy, leadership on federation. This is something that a Liberty-enabled site can use for interacting with their customers.
"Now, in terms of WS standards and Liberty, currently Liberty runs on the SAML (Security Assertion Markup Language) protocol [sic], and WS standards are slightly different, although they share components. We're also working to try and align those things. But those things don't impact InfoCard."
Opportunity for convergence

The Liberty Alliance started an effort to facilitate further convergence of existing identity systems. The public forum for these efforts can be found on the Liberty web site.

Liberty and SAML

Liberty uses SAML (any version) as the identity token format. In fact, most IdM systems have converged on SAML as the token format so there is a lot of conceptual similarity between different IdM frameworks once you get one level above the protocol flows. For Liberty ID Web Services Framework (ID-WSF) the SAML token format is a central building block.

While earlier specifications from Liberty, such as ID-FF 1.2 (Identity Federation Framework), addressed Single Sign-On (SSO) use cases using SAML as the token format, the efforts to develop SSO protocol have converged and Liberty now endorses SAML 2.0 as a SSO layer that is interoperable with Liberty ID Web Services Framework (ID-WSF).

Liberty and OpenID

Protocol designers have been working on making the Liberty system and the emerging OpenID technologies more compatible and "integratable" since Oct 2006. The questions that need to be addressed include:

How to move from incompatibility (divergence)

  • to equivalence (mappings),
  • to compatibility (protocol gateways), and finally
  • to convergence (unified solution)?

There are multiple efforts already under way, including:

  • an OpenID-SAML Profile based on iSSO and Lightweight SSO specs, covering simultaneous attribute exchange
  • Bootstrapping from OpenID authentication into ID-WSF
  • SAML Authentication Context descriptors for OpenID "assertion quality"

Furthermore, there are more efforts being considered:

  • OpenID-based identity services, such as the People Service, and unified

open source implementations that make this exploration easier

OpenID and WS-*

During the RSA conference in February 2007 Microsoft announced a new strategy regarding OpenID. Some of the projects and efforts Microsoft is considering are:

  • Support in products for OpenID
  • Collaboration on use of CardSpace with OpenID

Implementations

Open Source Projects

Here is a listing of the projects we know of and what they each say about themselves.

zxid.org
  • ZXID aims at full stack implementation of all federated identity management and identity web services protocols. It already supports SP and ID-WSF WSC roles, with other roles such as WSP and IdP to follow. See freshmeat.net/projects/zxid for announcements.
  • ZXID is light weight, has a small foot print, and is implemented in C. It is suitable for both high performance and embedded applications. Scripting languages are supported using SWIG, including Perl/mod_perl, PHP/mod_php, and Java (as JNI) on Tomcat. Platforms include all Linux/Unix systems as well as preliminary Windows support. The "full stack" nature of ZXID means it's self contained and has minimal external library dependencies.
  • Targeted Federated Identity Standards
    • SAML 2.0 (SP role 98% done)
    • SAML 1.1 (Assertion Consumer role 60% done)
    • Liberty ID-FF 1.2 (SP role 62% done)
    • WS-Federation 1.0 Basic Profile (Assertion Consumer role 40% done)
  • Targeted ID Web Services Standards
    • Liberty ID-WSF 2.0 (WSC role 95% done)
    • Liberty ID-WSF 1.1 (40% done)
    • General Web Services Security in SOAP messages (10%)
Lasso
  • Lasso (Liberty Alliance Single Sign On) is a free software C library aiming to implement the Liberty Alliance standards; it defines processes for federated identities, single sign-on and related protocols. Lasso is built on top of libxml2 , XMLSec and OpenSSL and is licensed under the GNU General Public License (with an OpenSSL exception).
  • Lasso first focused on implementing the Liberty Alliance ID-FF 1.2 protocols. It now supports a good part of ID-WSF and SAML 2.0 support has also been completed.
  • SWIG is used to provide high-level bindings for other languages. Currently tested and distributed bindings are Python, Perl, Java and PHP as well as preliminary .NET assemblies (for C# and the .NET runtime environment).
Authentic

Authentic is a Liberty-compliant identity provider aiming to address a broad range of needs, from simple to complex setups. Its Liberty compliance relies on Lasso, a free (GNU GPL) implementation of the Liberty Alliance specifications. It is a quixote application and is commonly runned inside Apache web server.

Source ID
  • Federated identity infrastructure enables cross-boundary single sign-on, dynamic user provisioning and identity attribute sharing. By providing for identity portability, identity federation affords end-users with increased simplicity and control over the movement of personal identity information while simultaneously enabling companies to extend their security perimeter to trusted partners. New identity federation standards provide companies with the foundation for securing their outsourced business processes, hosted applications and web services while simultaneously addressing a host of Sourceidoverview other security, management and integration challenges.
  • Coverage - SAML 1.1, Liberty ID-FF 1.1, Liberty ID-FF 1.2, WS-Federation
Sun OpenSSO
  • The Open Web SSO project (OpenSSO) provides core identity services to simplify the implementation of transparent single sign-on (SSO) as a security component in a network infrastructure. OpenSSO provides the foundation for integrating diverse web applications that might typically operate against a disparate set of identity repositories and are hosted on a variety of platforms such as web and application servers. This project is based on the code base of Sun JavaTM System Access Manager, a core identity infrastructure product offered by Sun Microsystems.
  • OpenSSO Extensions is an incubator for modules that build on the access control, single sign-on and federation technology in OpenSSO, but are not part of the core project. For example, currently there are developers working on an OpenID identity provider and a PHP client sdk.
  • OpenSSO is in use at the SSOCircle identity provider. Anyone can create an account at SSOCircle, upload service provider metadata and test their SAML 2.0 or OpenID service provider/relying party.
Higgins
  • According to its charter: "[Higgins] is developing an extensible, platform-independent, identity protocol-independent, software framework to support existing and new applications that give users more convenience, privacy and control over their identity information." Although Higgins components can be used for creating IdP and SP (RPs) the main focus is on creating what the Higgins folks call an "Identity Agent" that runs locally or remotely and is accessed by a browser extension that must be installed. The Higgins framework plans support for CardSpace, OpenID and SAML/Liberty protocols and plans to overlay all of these with a consistent, graphical "card-based" user experience. Higgins is currently hosted at the Eclipse foundation and is one of the core projects of OSIS.
Heraldry Project
  • This is a proposal to create a project within the Apache Software Foundation to develop technologies around the emerging user-centric identity space. The project would utilize Yadis for URL/XRI-based service discovery and OpenID [2] for web based single-sign-on and the basis of exchanging profile data. Yadis is currently being standardized within OASIS as part of the XRI effort, within a TC committed to creating royalty-free work, and OpenID has emerged as a de-facto specification. The two initial components of the project, downloadable perspective, would be an Identity Provider application and libraries in various languages that implement Yadis and OpenID. The initial goal would be to both provide an out-of-the-box application as well as the required libraries for other developers to integrate Yadis and OpenID into their existing applications.
Bandit Project
  • Bandit is a set of loosely-coupled components that provide consistent identity services for Authentication, Authorization, and Auditing. The Bandit project creates a community that organizes and standardizes identity-related technologies in an open way, promoting both interoperability and collaboration.
  • Bandit implements open standard protocols and specifications such that identity services can be constructed, accessed, and integrated from multiple identity sources. Bandit components support many authentication methods and provide user-centric credential management. On this base of a common identity model, Bandit is building additional services needed for Role Based Access Control (RBAC) and for the emission of records to verify compliance with higher level policies.
Shibboleth
  • The Shibboleth software provides a complete implementation of the OASIS SAML v1.1 specification, providing a federated Single-SignOn and attribute exchange framework built on top of OpenSAML. Shibboleth also provides extended privacy functionality allowing the browser user and their home site to control the Attribute information being released to each Service Provider. Using Shibboleth-enabled access simplifies management of identity and access permissions for both Identity and Service Providers. Shibboleth is developed in an open and participatory environment, is freely available, and is released under the Apache Software License.
OpenSAML
  • OpenSAML 1.1 is an Apache-licensed open source toolkit for implementing solutions using the SAML 1.1 and 1.0 specifications. It is a production quality release available for Java (1.4 ) and C applications, and is built on various Apache-supported XML projects like Xerces and XML-Security.
  • OpenSAML 2.0 is in development, and will include support for the SAML 2.0 standard, as well as legacy support for SAML 1.1 and 1.0. The redesigned library includes a superset of the functionality in earlier versions, but will NOT be API-compatible with them. It will remain Apache-licensed.
Conor Cahill ID-WSF tools
Lightbulb
  • Project Lightbulb brings federated identity to LAMP and MARS developers. Tools for interpreted languages such as PHP, Ruby and Python integrate with Sun's open source Java federation software.
PAPI
  • PAPI is a SSO system able to provide federated access that has been under development by RedIRIS since 2001.
  • The system consists of two independent elements: the authentication server (AS): the IdP, and the point of access (PoA) the SP.
  • A PAPI AS is able to incorporate practically any kind of credentials: experiences range from plain username/password pairs to X.509 certs and Kerberos tickets, including complex environments with different credential sources.
  • PAPI supports two different kinds of PoAs: the GPoA (outer SP), providing interactions with the rest of the federation elements, and "plain" PoAs (inner SP), that provide actual access to the resources.
  • Currently, PAPI ASes, GPoAs and PoAs communicate using a proprietary, pre-SAML protocol, though there are implementations for ASes and GPoAs able to use the Shibboleth SAML profile.
  • PAPI PoA-GPoA structure allow for a simple (and pervasive) deployment of federated access control systems in heteregeneous environments. There are PoA implementations for Java (both javax.servlet.filter and JAAS), Perl and PHP, plus an attribute-aware HTTP/HTTPS proxy that can be used as last-resort solution for including legacy applications.
Map Graphic (in progress)

This is a dynamic mindmap of the open source projects we track and report on here. It is in development. If you use Safari, we apologize for the bug. For others, you should be able to interact with the Map right from within your browser.



This Map is built using Open Source Software called FreeMind. You can download a copy of FreeMind and edit this mindmap source file locally. If you make any changes locally please contribute your changes back to this page. If you just want a picture of the Map you can grab the Latest Version (PNG file).

Commercial Products

Windows CardSpace
NetMesh InfoGrid

Supports OpenID, LID, Yadis etc. Dual-licensed (open-source and commercial). See netmesh.org.

Organizations

Liberty Alliance

Identity Commons

  • The purpose of Identity Commons is to support, facilitate, and promote the creation of an open identity layer for the Internet, one that maximizes control, convenience, and privacy for the individual while encouraging the development of healthy, interoperable communities. (from http://wiki.idcommons.net/moin.cgi/PurposeAndPrinciples)

OSIS

  • OSIS brings together many identity-related open-source projects, and synchronizes and harmonizes the construction of an interoperable identity layer for the internet from open-source parts. Its first deliverable is interoperability with Microsoft's Windows CardSpace, although OSIS also encompasses alternate technologies such as OpenID and also Liberty.

Conclusions

Acknowledgments, License and Copyright

Since this paper is written in a community effort, the opinions in this paper do not necessarily reflect those of the Liberty Alliance or any of its members.

Contributors

Contributors to the Related Projects page (now included in this paper):

Authors whose material has been used:

  • Eve Maler (Sun Microsystems, Inc.)
  • Brett McDowell (Liberty Alliance)

License

Content that violates any copyright will be deleted. You agree to license your contributions under the Creative Commons Public License Attribution 2.5. When quoting, reproducing or re-using the entire documents or parts thereof, attribution shall include the name of the paper and an link to the location of the paper (where possible).

CC-BY88x31.png

Copyright Notice

This content is copyright Liberty Alliance.

OpenAz