Identity Services Foundation

Definitions, Models and Usage Patterns

Revision 0.3 Febuary 2006

This document copyright Novell, Inc. 2005, 2006

    1. Identity Services Foundation
    2. Overview
    3. Definitions
      1. Identity
      2. Principal
      3. Crafted Identity
      4. Role
      5. Policy
      6. Compliance
    4. Model
      1. Identity
        1. Construction
        2. Comparison
        3. Query
        4. Authenticate
      2. Principal
        1. Construction
        2. Add Identity, and Delegated By
        3. Identity Set Operations
        4. Relationships Between Identities
        5. Role Membership
        6. General Query
      3. Policy Calculation Service
        1. Construction
        2. Calculate Effective Policy
        3. Make Policy Decision
    5. Levels of Application Integration with ISF
      1. Identification and Basic Authentication
      2. Advanced Authentication
      3. Multiple Identities, Roles, and Delegation
      4. Policy Calculation
    6. Usage Patterns
      1. Consistent References to Identity
      2. Transient Authentication
      3. Multiple Identities per Principal
      4. Directed Principal
      5. Delegation
      6. Relative Roles
      7. Informational Attributes
    7. Questions and Unresolved Issues
    8. Revision History and Contributors

Overview

The Identity Services Foundation (ISF) is a set of software components that cooperate to provide a consistent experience of identity driven computing across multiple applications and platforms. ISF provides components that enable consistent use of identity and roles, as well as policy enforcement and compliance verification services.

The scope of ISF encompasses numerous application and policy domains and some aspects, such as Crafted Identities, are particularly designed to enable the interchange of identity information across such boundaries. This document focuses on the ISF models and patterns that are useful within a particular application or process.

This document will describe the overall conceptual model for ISF and then show how that model can be applied to common usage patterns that are difficult to address in current platforms. Other documents will describe how the model can be applied to specific environments such as J2EE and .Net.

Definitions

Identity

An identity is anything that is either the requester or target of an action constrained by authorization policy. Much too much has already been written that attempts to define digital identity. We will start with a dictionary definition since we are defining it for humans. A trip to Merriam Webster (m-w.com) finds this definition: "the distinguishing character or personality of an individual". It is followed by a link to "individuality" and this definition: "total character peculiar to and distinguishing an individual from others". In the digital context such as a directory service, an identity can be viewed as a set of attributes that pertain to a unique carbon, silicon, or logical entity such as a user, group, role, device, process, executable code, etc. But just as in real life, attributes can change over time and cause the identity to expire. Also, any particular set of attributes may not be sufficient or necessary to establish uniqueness for some purpose and time. It is also very important for successful identity driven computing that additional informational attributes can be included and retrieved that are not used to distinguish one identity from another. An identity must be unique, identifiable, and discrete from other identities. For example, a role such as Employee is a unique identity that may be shared by many users, but it is still a unique identity in that policy that is applied to the role affects all users equally, i.e. it only applies to the role. Therefore, we will define an identity as a set of attributes, some set of which can distinguish the identity from others for a particular purpose and time. Still, in the overall computing environment this definition is too broad -- it can be applied to too many things. So what is the basis for determining when a digital identity should actually be instantiated? We assert that the purpose for identity in computing environments is to support enforcement of policy. A policy can be thought of as a link that specifies interactions between identities, e.g. a printer and a user. More complex interactions such as workflow, collaboration, and auditing can be built from such simple policy links combined with logical identities such as roles. With this in mind ISF will primarily consider identities that need to be instantiated to support policy -- either as a protected resource or as an identity acting on a resource. In short: an identity is anything that is either the requester or target of an action constrained by authorization policy. This is a more specific form of the statement: an identity is semantic construct for the enforcement of policy. Note that an identity can be specified (identified) by a set of attributes, but this is not the same as authentication. An authenticated identity is authorized to act on behalf of the identity. An identity is authenticated in addition to identification via some process which often involves the presentation of credentials such as a password.

Principal

In this document a Principal refers to a set of identities, including roles, that may request permission to perform actions on some other identity such as a resource. This concept is related to those of Principal, Subject, and Crafted Identity in other documents and environments. A Principal essentially aggregates the authority of multiple identities involved in a set of potential actions on a resource. The enforcement of policy involved in that aggregation is a core value of ISF. A Principal can also be queried in a simple fashion to determine if it represents a particular role. It can be queried in a more complex fashion to enumerate identities and determine relationships between them such as delegation, static roles and dynamic roles related to an authenticated identity.

Crafted Identity

A Crafted Identity is a document that contains information about identities, roles, authority, and attestations concerning the validity of the information. Its purpose is to enable this information to be shared across application or policy domains. Thus one or more Crafted Identities from an external source could be used in the construction of a Principal within a particular process.

Role

A role is a functional position within a system -- computer or human. Another trip to m-w.com finds this definition of role: "a function or part performed especially in a particular operation or process <played a major role in the negotiations>." In ISF the driving conceptual basis for roles is the NIST RBAC work, though it is not limited to it. Much of the value of ISF involves the integration and aggregation of roles into a Principal. This can be thought of as assembling a Principals authority for a potential set of actions. Note that such authority is distinct from policies such as permissions that are evaluated relative to an action and a target identity. Assembling a Principal is a key point where system policies can be injected into existing systems with minimal impact. Policies that may be involved in the aggregation of roles include: static roles -- an identity associated with the role even if no Principal is active. dynamic roles -- an identity can assume the role within a Principal if certain conditions are present, such as time of day. static exclusion of roles -- an identity cannot assume a particular static role if it is already in another static role. dynamic exclusion of roles -- an identity cannot assume a particular role if another role is active within the same Principal. authenticated roles -- to assume a particular role and identity may need to provide additional credentials. optional roles -- an identity or other process may request optional roles to be added to a Principal based on existing roles within the Principal. relative roles -- whether an identity may assume a role depends on the identities involved in the set of potential actions. These are sometimes called dynamic roles, application specific roles or custom roles. This is particularly addressed as the ternary relation between Role, Operation, and Object here: http://csrc.nist.gov/rbac/jansen-ir-rbac.pdf In ISF a Role is an identity. It can be authenticated and included in a Principal like other identities. Sometimes a role may be automatically added to a Principal, sometimes it must be explicitly added. The particular derivation of a role can be determined by querying its relation to other roles in the Principal.

Policy

The Merriam Webster Online definition of "policy" is almost entirely applicable to ISF: 1 a : prudence or wisdom in the management of affairs b : management or procedure based primarily on material interest 2 a : a definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions b : a high-level overall plan embracing the general goals and acceptable procedures especially of a governmental body The overall purpose of identity driven computing can be seen as control and enforcement of policy. Identity and Role are mechanisms that allow systems to attach policy, and compliance involves validating that policy is enforced.

In ISF, policy can be divided into authorization (or declarative) policy and workflow (or procedural) policy. In this paper we will focus on authorization policy, i.e. policy which determines whether an identitys request to perform an action should be granted or denied. Policy as used in this document encompasses both identity-based security policy and rule-based security policy as defined in the IETFs RFC 2828.

Policy can be divided into three functional areas: expression, management and storage, and calculation. This document is primarily concerned with a model for a policy calculation service.

Compliance

Compliance is the validation of policy enforcement both before and after deployment. While the validation of policy enforcement is currently of great value due to the escalating need to determine regulatory compliance, it goes beyond that to validate other policies, such as corporate policies, as well. This happens in primarily in two ways. First is the ability to validate that potential actions are within effective policy constraints. It is the ability to query effective policy before and during deployment. In other words, an administrator should be able to test the system by asking what would happen if a particular identity or role attempted an action. The resulting policy calculation should be able to specify whether the action would be allowed or denied and what policy determined that outcome. The second mechanism is the ability to verify that attempted actions have been granted or denied within effective policy constraints. This is primarily via the auditing of events, especially policy decisions, in a deployed system. This is similar in mechanism to logging, but differs in how the stream of events is protected and from whom. ISF focuses on proper handling and publishing of audit events, but does not specify how they are aggregated, secured, or analyzed. Note that the majority of events that need to be audited involve authentication and policy decisions on attempted actions. Since ISF provides those services to applications, the majority of auditable events are unobtrusively handled on behalf of the application.

Model

Identity

Construction

An identity may be specified by a set of attributes. The original X.500 concept of a distinguished name (DN) was merely a collection of such attributes. But it was not practical to find such an identity anywhere in the world, so the DN attributes needed to be ordered to provide for a step by step resolution. There was still no way to provide and explicit scope or starting point. LDAP adapted the X.500 notion into a URI, including a host name, which gives a (usually single and brittle) starting entry point to look for an entry with the specified attributes. Other systems use a service discovery mechanism that is configured to provide the starting point for finding identities, such as SLP. Some systems now integrate such services into DNS and DNS itself has become more capable of handling distributed services with SRV records. Since DNS is the ubiquitous naming scheme of the planet, there should be a way of specifying an identity as a URI.

ISF should provide for system configuration of identity location so that individual applications do not need to do it. Applications should be able to request an identity without specifying its source. But it is also often necessary to override system configuration to specify a specific identity source - ISF should accommodate this need as well.

Comparison

Two Identity objects must be able to be compared to determine if they refer to the same Identity. For example a policy may contain a permission for a particular identity to perform an action on a target. To enforce the policy it must be able to be determined that the identity in the policy is the same as the requester.

Query

An essential characteristic of ISF Identities is the ability to query and retrieve standardized information about an identity. Simply knowing the existence of an identity and being able to authenticate it are insufficient for many applications. It is common for applications to require other, informational attributes about an identity. For example, a commerce application may require the shipping address and phone number of a customer. These types of queries are not commonly supported in authentication services. They are commonly expected of directory services, but the names, meaning and mechanisms for defining such attributes are not uniform - complicating application usage.

These types of attributes may be contained in a Crafted Identity and are not used by policy to authorize the creation of the identity. The attributes may be included in the Principal or retrieved from a designated URI. The application accesses such attributes via this Query interface.

ISF will support existing and emerging standards for attribute definitions and extensibility and only attempt influence standards when clearly necessary. The intention is to provide clearly defined attributes, including appropriate application usage, and enforce policy when an application accesses those attributes.

Authenticate

The process of authentication of an identity can be very involved and employ mechanisms, protocols and algorithms. Of course, the starting point is usually a simple interface such as that provided by PAM (Pluggable Authentication Module) in Linux, but this should not be thought of as a simple method that accepts a password. It may involve multiple exchanges and interactions with the user.

Authentication establishes that a Principal has been authorized to act on behalf of the Identity for some period of time. Applications do not need to be aware of the expiration time if they use the Principal to request ISF policy decisions - the policy calculation service will account for the expiration of the authentication.

Principal

Construction

A Principal can be empty, i.e. contain no Identities, so no information is needed for initial construction.

Add Identity, and Delegated By

Both of these methods add an Identity to a Principal, but vary in how the relationships between the Identities are constructed and what policies are applied.

When an Identity is added to a Principal a number of things happen. If the Principal contains Identities, policy calculations may ensue to determine if the Identity may coexist with them. Also, if the Principal is added, other identities (e.g. roles) may be automatically added.

Identity Set Operations

Unlike identities there is no comparison operation for principals. It is unclear what a simple comparison would mean. But there is a need to perform set operations on Principals. For example, in .NET all permissions have set operations like: IsSubsetOf, Intersect and Union. This makes it easy to test if a Principal fulfills all the required roles/identities required by an application, and can be done as an atomic operation.

Relationships Between Identities

A distinction of ISF is its ability to handle multiple types of relationships between Identities within a Principal. A Principal does not just have a primary identity and dependent roles. This will be seen by the usage pattern of delegation. When a service identity acts on behalf of user identity and interacts with a resource, both the identity of the service and the user need to be known and handled appropriately. Neither identity is primary, but the relationship between them must be clear.

Role Membership

A simple interface such as IsInRole should be provided. A variation of this method should also be provided that accepts a target Identity to determine relative role membership. Using set operations would be useful for applications that need to check for membership in multiple roles. Iteration through multiple calls to IsInRole would be inconclusive due to possible time-related changes. Using a IsSubsetOf could do several checks in an atomic fashion.

General Query

This would be similar to the Query interface to an Identity, but should be convenient for finding information about multiple Identities within the Principal. It should also be able to list which identities are within a Principal that match some criteria.

Policy Calculation Service

Construction

The policy calculation service may require information about auditing event output configuration when it is instantiated.

This would allow the service to filter events which is great performance wise but it means that the audit services may not get everything it would normally require (i.e. setting the event output may not be possible/visible to audit service administrators). Another way (or option) would be a asynchronous fire-and-forget of events to an audit service (using queueing to ensure events cant be lost).

Calculate Effective Policy

This method would be used to validate policy effectiveness relative to arbitrary identities and roles. The method would take the requesting Principal to ensure that it has sufficient permissions to check policy, e.g. an administrator, and then it would specify Principal on whose behalf the policy is to be calculated, the action and/or policy expression to be calculated, and, optionally, an Identity that would be the target of the action (for relative role determination).

The output of this method would include not just the output of the policy decision, but also information about the factors that determined the decision, e.g. which role caused an explicit grant or deny of the permission.

This call would audit the attempt by the Principal to calculate the effective policy.

Make Policy Decision

This method just calculates a policy decision on behalf of the calling Principal given a policy expression and, optionally, a target Identity.

The decision would be audited as an attempt by the Principal to perform the action on the target Identity.

Levels of Application Integration with ISF

Identification and Basic Authentication

An application may very easily use ISF services for identification and basic authentication. In most environments this should be able to be accomplished without modifying the application. Such use of ISF still provides value to the application because it uses identities that are common with other applications that may use more of ISF capabilities.

An example of this would be existing applications in Linux that integrate with the Pluggable Authentication Module (PAM) and Name Service Switch (NSS) interfaces. A user may change his corporate password via a portal, then log into his Linux box using the new password (which authenticates via PAM to an ISF enabled module), and then accesses an external site and is authenticated by Liberty mechanisms via his browser all using the same name and authentication credentials.

Advanced Authentication

Authentication of an Identity using more than simple name and password is woefully uncommon. ISF will provide other authentication methods, and will likely require changes in an application to make use of them. This is not an unexpected requirement for applications, but is a more significant change than that required for basic authentication.

For example, it is a necessary change for applications that already have mechanisms to retrieve a user name and password and can only handle a single password verification step. Such applications will need to change to support a variety of authentication types such as hardware tokens or multi-factor forms anyway. By changing once to the ISF advanced authentication services, many authentication forms will be supported.

Multiple Identities, Roles, and Delegation

Use of various forms of Identity aggregation into a Principal is a highly valuable portion of ISF in that it provides a common source of authority controlled by policy from a central source, with minimal intrusion into an application. Many environments already have the notion of roles associated with an identity, or at least a single group identifier and ability to query for group membership. ISF can inject limited but consistent roles into these applications, as well as basic identity. Much of the valuable and complex identity and role aggregation mechanisms are hidden from the application behind simple queries such as IsInRole.

Policy Calculation

For an application to get the full value of ISF, it also needs to use the policy calculation service. The application must be able to express its policies in a form consumed by the policy calculation service, and then call that service whenever a decision is needed. Policy management and storage may be application specific.

The benefit of this service is to provide common policy expression as well as identity and role usage when applied to policy across multiple applications.

It also can reduce the need of the application to publish audit events in that the policy calculation service can report decision results. For example, simple authorization decisions can be audited by the calculation service, and such decisions are a significant portion of auditable events in many applications. It does not eliminate the need to an application to publish other auditable events.

Usage Patterns

Consistent References to Identity

Applications need to refer to Identities from a variety of sources and be able to compare references. ISF provides the ability to do so without specific application knowledge or implementation of identification keys such as GUIDs or Distinguished Names.

Transient Authentication

Just as it is necessary for some applications to refer to Identities without authenticating them, it is also important that they can quickly check the authentication credentials of an Identity without incurring overhead such as connection or session establishment.

It is common for applications that use LDAP to authenticate users to implement their own connection pool to the LDAP server so that they can avoid the overhead of connection establishment. But when they do so they must also explicitly read and compare the users credentials on these privileged connections rather than use the LDAP Bind request, and server policy and compliance capabilities are bypassed. A similar situation exists for web applications accessing credentials in relational databases.

ISF improves this pattern by hiding the management of references and authentication connections behind the interface to Identity. The instantiation and authentication of an Identity happens at a point where it is simple and straightforward for the application, but connection caching, if necessary, can be done by ISF components.

Multiple Identities per Principal

An ISF concept that goes beyond traditional RBAC is the ability to apply policy to multiple Identities within a Principal. It is similar to previous discussions of identity and role, but it involves multiple primary identities.

If we allow multiple identities, e.g. a user, a backup service, and a machine to all be included in the Principal then we can use the same role aggregation policies and logic in a new way. For example, user Joe logs into machine Hal and invokes backup service Archive, but Hal is an unsecured machine outside of the firewall. Policy could specify that Hal and Joe are dynamically excluded from being part of the same Principal. This is almost identical to dynamic exclusion of roles, but by allowing it to include multiple identities involved in the service request, we can enable additional and powerful control, particularly in securing access.

Some applications may not be able to easily cope with this. Multiple identities can lead to strange situations where using different identities at some point may result in different/invalid condition later (leading to user confusion). But this is already an issue in many cases, particularly involving delegation. This is an area in which ISF will need to proceed carefully and provide a clear evolutionary path, probably including an interface to a consistent "primary" identity.

Directed Principal

This pattern occurs when a service needs to do something on behalf of a set of identities, but the total number of potential role and identity combinations is too great to be practical, and may not be able to be computed without some concept of the intended purpose. This purpose can be described as a set of potential actions and resources, which is conceptual similar to a Role defined in terms of an application or set of applications. For example, novell-email-user or amazon-book-purchaser.

Since ISF treats all roles as identities, this pattern is straightforward to handle. A Principal can be instantiated to include the application role even before other identities are added. Other Identities within the Principal are then constrained by the policies which include the application role.

Delegation

For many services a user needs to delegate a time-bounded subset of his rights to that service. The service then makes requests on his behalf to another service. For example, a user wants to delegate his authority to read a section of the file system to a backup service from 2 to 3 a.m. When the file system receives the request to read the file it should be able to audit both the service identity and the user on whose behalf the file is being read. It should constrain the read permissions to those appropriate to each of the two identities involved. It should also be noted that such delegation chains can involve many levels of identities, not just two.

ISF supports this pattern by allowing an application to query such identity relationships within a Principal, and allowing such relationships to be specified as Identities are added to the Principal.

Relative Roles

A relative role is indicated when a Principal can only assume a role if the target of an action involves a particular set of Identities. For example, a doctor may only assume the doctor-of-record role if the target Identity refers to one of her patients.

ISF implements this pattern directly by including an optional target Identity parameter to the IsInRole method of a Principal, and to the policy calculation service.

Informational Attributes

Applications sometimes need controlled access to information about an Identity. For example, an application needs phone number and shipping address for a specific Identity, but should only get them if the Identity has allowed them to be used for this purpose. This is a major area of enhancement for ISF in that it eliminates the need for separate access to another source of information about an Identity, such as a directory service. ISF provides a controlled and standards-based set of information to applications directly from the Identity interface.

Questions and Unresolved Issues

  • Role Mapping: It seems like a valuable pattern to provide role mapping within a Principal, or from external role source such as Crafted Identity to Principal. How should this be addressed here?
  • Potential Action Enumeration: What am I allowed to do (administrator or user) for a set of identities and a particular resource. Should ISF attempt to enumerate all possible actions (which involves enumeration of all possible roles)?
  • What should be the copyright notice and distribution policy of this document?
  • How to handle document collaboration - twiki vs. OOo Writer annotations? - Resolved moved to Wiki
  • Need a glossary of policy types.
  • Determine how workflow policy fits in this document
  • Where would it make sense to tackle the creation and use of pseudonyms that can be used for informational or policy purposes without identifying a specific user?
  • Outgoing Authentication: This document so far only views an Identity as something used by an application to control access to resources within its control. There is no concept (yet) of using a users credentials to authenticate to an external service.
  • Informational attributes and Identity query sections should be greatly expanded with input from standards such as those endorsed by the Liberty Alliance.
  • Carlos suggested including the policy cache service as per the CASA work. This would introduce policy storage/management into this document - which has been avoided so far - but seems to make sense since it is such a common need for ISF applications.
  • Steve wants more diagrams.
  • Sébastien wants more examples, especially for the application integration and usage patterns.

Revision History and Contributors

Version 0.1, by Dale Olds, first draft

Version 0.2, by Dale Olds, incorporated substantial input from Steve Carter, Carlos Montero-Luque, and Sébastien Pouliot. I have attempted to address any concerns raised as well, but have not always been able to do so due to my inability to understand them, disagreement with them, or confusion on how to address them within this document. If you feel your input was not sufficiently covered, please let me know.

Version 0.3, by Duane Buss minor edits, moved to wiki.