SIMPLEST: A standard schema for Identity and Access Management

SIMPLEST stands for Standard Identity Management Protocol Lightweight Extensible Schema Template. (The acronym was just too good to pass up.)

The goal of SIMPLEST is to do for Identity Management something like what SNMP did for devices: define a simple protocol that enables interoperable management of identities. SPMLv1 defined basic CRUD operations for identities. SPMLv2 specified a number of standard capabilities (as well as defining an extensible mechanism to register new capabilities and separating the protocol from the payload). A standard schema is one important piece that has been missing.

Adoption increases the value of interoperability. In order to lower the cost of adoption, we want to minimize the overhead involved in supporting the standard. SIMPLEST therefore minimizes the set of object-classes, attributes and relationships that an implementer is required to support. This, combined with its simple syntax for representing objects and attribute-values, makes this offering lightweight.

No standard schema for identity management can hope to be complete. There are too many different approaches to identity, and too much proprietary value to be obtained through differentiation. For this reason, the SIMPLEST schema is extensible, predefining certain standard object-classes, attributes and relationships for the purpose of interoperability (but allowing implementations to expose additional object-classes, attributes and relationships as necessary).

Minimizing the required parts of the schema and leaving room for additional attributes makes this offering a schema template, rather than a fixed or closed schema.

Basic Identity Management: Person

The first thing that everyone wants to manage (and the only thing that some people care about representing) is Person.

Person

Each instance of Person represents a human being (or a fictional human being) independent of any system or application. The attributes of Person apply generally to all contexts: names, titles, contact information and so forth.

Some attributes of Person may refer to other entities within the same enterprise, such as the Organization to which a person belongs, the Roles that a person performs, or the Groups of which the person is a member. The values of these attributes are generally scalar, so references to such entities are usually by name and carry no additional information. (NOTE: In some cases, formal relationships may underlie such scalar reference attributes. The scalar attributes that refer to other entities may be the "convenience form" of a structured relationship that refers to another object by identifier rather than by name. A structured relationship may have attributes of its own. For example, a formal relationship between a user and a role may have a start-date, an end-date, the date on which the role was assigned to the user, the mechanism that assigned the role to the user--or the administrator who assigned the role if an administrator assigned the role directly.)

The attributes of Person are negotiable, and the vast majority of them are optional. For that matter, the Person object-class itself is optional: a server or provider is free to specify its own object-class to represent persons. For the sake of conformance, we require that you not define an object-class with the same name as this predefined class unless that object-class supports every attribute that is defined as required for Person. Similarly, we require that you not define an attribute for object-class Person with the same name as an attribute that we predefine for Person unless that attribute has the same meaning, syntax, cardinality and other characteristics that we specify for the predefined attribute.

Scalar Attributes of Person

attributeName

Required?

Syntax
(if more specific than string)

Properties
(if not single-valued, read-write)

Description

Notes

ID

REQUIRED*

sv; read-only post-create

Identifier for this Person, unique within target.)

Required by protocol. Compare to PSOID in SPML (or to ID in RESTPML).

objectClass

REQUIRED*

sv; read-only post-create

Identifies the class of this object, in this case "Person".

Required by protocol. Compare to Object-Class (or to class in RESTPML).

loginName

Optional

Name used when authenticating as this person.

password

Optional

Password (shared secret) used to authenticate as this person.

SPMLv2 Password Capability

passwordIsExpired

Optional

boolean

If read as 'true', indicates that the password for this Person is no longer valid. Set to 'true' in order to mark the current password value as invalid. (Set to 'false' in order to mark the current password value as valid.)

SPMLv2 Password Capability.

passwordExpireDate

Optional

timestamp

Date and time that the current password for this Person will expire.

SPMLv2 Password Capability.

passwordToValidate

Optional

sv; write-only

Set this to a value in order to determine whether the specified value would be valid as a password for this Person. Expect an error if the password would not be valid.

SPMLv2 Password Capability.

passwordIsReset

Optional

boolean

If read as 'true', indicates that the current password value was generated (and communicated out-of-band to the Person). Set to 'true' in order to replace the current password with a generated value. (Expect the new password value to be communicated to the Person out-of-band.) The value will remain 'true' until the Person sets a new password, at which time the value will be read as 'false'.

SPMLv2 Password Capability.

isDisabled

Optional

boolean

True if this Person's password is currently expired; otherwise false.

SPMLv2 Suspend Capability.

disableDate

Optional

timestamp

Date and time that all access by this Person is scheduled to be prevented. Set a new value (in UTC format with no timezone) in order to change the date and time at which all access by this Person is scheduled to be prevented. Set to an empty value in order to remove the scheduled disablement.

SPMLv2 Suspend Capability.

enableDate

Optional

timestamp

Date and time that all access by this Person is scheduled to be allowed. Set a new value (in UTC format with no timezone) in order to change the date and time at which all access by this Person is scheduled to be allowed. Set to an empty value in order to remove the scheduled enablement.

SPMLv2 Suspend Capability.

formattedName

Optional

Full name for this person.

Composed (in a locale-specific manner?) of familyName, givenName, middleName, honorificPrefix, honorificSuffix.

familyName

Surname of this person.

(no note)

givenName

First name of this person.

(no note)

middleName

(no note)

honorificPrefix

E.g., "Mr.", "Dr.", "Her Majesty".

(no note)

honorificSuffix

E.g., "Junior", "III", "Esquire".

(no note)

displayName

(no note)

nickName

Informal name of this person (e.g., "Babs" rather than "Barbara").

(no note)

profileURL

Each value is the URL of a profile for this person (e.g., HR, LinkedIn).

If we want to make this multi-valued, consider representing it as a complex attribute.

title

This person's title within the enterprise.

(no note)

userType

This person's affiliation with the enterprise (e.g., "employee", "contractor").

(no note)

preferredLanguage

The locale (language and country code) this person prefers (e.g. "FR_CA").

(no note)

timeZone

The time-zone (UTC offset) this person usually observes.

(no note)

employeeNumber

This person's unique identifier within the enterprise.

(no note)

costCenter

The cost-center within the enterprise to which this person's time is charged.

(no note)

organizationID

(ID)

The ID of the Organization within the enterprise to which this person belongs.

Should match the "ID" of any Organization object specified by 'organizationName'. (If the Relationship Type 'Person-belongsTo-Organization' is also supported, this value should match the 'toID' value of Person-belongsTo-Organization where 'fromID' matches the ID of this Person.)

organizationName

(Name)

The name of the Organization within the enterprise to which this person belongs.

Should match the "Name" of any Organization object specified by 'organizationID'. (If the Relationship Type 'Person-belongsTo-Organization' is also supported, this value should match 'Name' of the Org identified by the 'toID' value of Person-belongsTo-Organization where 'fromID' matches the ID of this Person.)

division

Structure within organization to which this person belongs.

(no note)

department

Structure within division to which this person belongs.

(no note)

managerID

(ID)

Identifier of the manager to whom this person reports.

Should match the "ID" of the Person object that represents the manager.

managerName

(Name)

Name of the manager to whom this person reports.

If 'managerID' is also supported, should match the 'Name' of the Person object identified by 'managerId'.

emailPrimary

Optional

(Email)

The main email-address for this Person.

Compare to Complex Attribute Person-hasEmail. If both are supported, this value should match the value of hasEmail for this Person where isPrimary=true.

emailsSecondary

Optional

(Email)

multi-valued

Additional email-addresses for this Person.

Compare to Complex Attribute Person-hasEmail. If both are supported, each value should match a value of hasEmail for this Person where isPrimary=false.

phoneNumberPrimary

Optional

(Phone)

The main phone number for this Person.

Compare to Complex Attribute Person-hasPhoneNumber. If both are supported, this value should match the value of hasPhoneNumber for this Person where isPrimary=true.

phoneNumbersSecondary

Optional

(Phone)

multi-valued

Additional phone numbers for this Person.

Compare to Complex Attribute Person-hasPhoneNumber. If both are supported, each value should match a value of hasPhoneNumber for this Person where isPrimary=false.

IMAddrPrimary

Optional

(IMAddr)

The main Instant-Messaging-address for this Person.

Compare to Complex Attribute Person-hasIMAddr. If both are supported, this value should match the value of hasIMAddr for this Person where isPrimary=true.

IMAddrsSecondary

Optional

(IMAddr)

multi-valued

Additional Instant-Messaging-addresses for this Person.

Compare to Complex Attribute Person-hasIMAddr. If both are supported, each value should match a value of hasIMAddr for this Pereson where isPrimary=false.

photoPrimary

Optional

binary

The main photo-image for this Person.

Compare to Complex Attribute Person-hasPhoto. If both are supported, this value should match the value of hasPhoto for this Person where isPrimary=true.

photosSecondary

Optional

binary

multi-valued

Additional photo-images for this Person.

Compare to Complex Attribute Person-hasPhoto. If both are supported, each value should match a value of hasPhoto for this Person where isPrimary=false.

addressPrimary

Optional

(address)

The main formatted address for this Person.

Compare to Complex Attribute Person-hasAddress. If both are supported, this value should match the formattedAddress of hasAddress for this Person where isPrimary=true.

addressesSecondary

Optional

(address)

multi-valued

Additional formatted addresses for this Person.

Compare to Complex Attribute Person-hasAddress. If both are supported, each value should match a formattedAddress of hasAddress for this Person where isPrimary=false.

groupPrimary

Optional

(Name)

The name of the main group of which this Person is a member.

Compare to Relationship Person-memberOf-Group. (If both are supported, this value should match the 'Name' of the Group identified by the value of 'toID' within Person-memberOf-Group for this Person where isPrimary='true'.)

groupsSecondary

Optional

(Name)

multi-valued

The names of additional groups of which this Person is a member.

Compare to Relationship Person-memberOf-Group. (If both are supported, each value should match the 'Name' of a Group identified by a value of 'toID' within Person-memberOf-Group for this Person where isPrimary='false'.)

rolePrimary

Optional

(Name)

The name of the main role (if any) that this Person performs (i.e., to which this Person is assigned directly).

Compare to Relationship Person-performs-Role. (If both are supported, this value should match the 'Name' of the Role identified by the value of 'toID' within Person-performs-Role for this Person where isPrimary='true'.)

rolesSecondary

Optional

(Name)

multi-valued

The names of additional roles that this Person performs (i.e., to which this Person is assigned directly).

Compare to Relationship Person-performs-Role. (If both are supported, each value should match the 'Name' of a Group identified by a value of 'toID' within Person-memberOf-Group for this Person where isPrimary='false'.)

isPrivate

Optional

boolean

True if this Person object should be treated as hidden or confidential (i.e., used or shown only for purposes authorized by the Person or Provider).

Applies to every attribute, attribute-value, relationship and relationship-attribute for this Person.

Scalar and Complex Attributes. Note the comparative inelegance of using scalar attributes to represent "complex" values (such as address) that have sub-attributes (such as streetAddress, locality, region, postalCode and country). We can represent each formatted address as a scalar value, but DSML cannot natively represent the individual components of an address. The classic LDAP solution is to use a certain token--e.g. the dollar-sign--to delimit components within an address. Using a delimiter requires the client/requester to understand the structure of the data-value--i.e., to recognize its components positionally. Unfortunately, using a delimiter requires even more pre-arrangement in order to represent metadata on top of the set of values, such as which value--if any--is considered to be the primary value for a multi-valued attribute. Similarly, additional pre-arrangement would be required in order to associate with each value metadata such as an arbitrary "type" (e.g., "home" address, "shipping" address, "vacation" address and so forth). Simple DSML representation of scalar attributes cannot natively structure the extra information within a complex attribute that XML or JSON could.

The following section describes one potential solution. Because each relationship type is (syntactically, if not semantically) another object-class, a type of relationship that is "open-ended" (i.e., from one object but to none) can be used to store complex attributes. If we are willing to define a generic convention for representing the sub-attributes within a reflexive relationship--e.g., to present each reflexive relationship as a JSON object or an XML object--then we may achieve a level of elegance in representing complex attributes.

For now at least, I suggest that we retain the scalar attributes that overlap with complex attributes. A provider who chooses not to support formal relationships should still be able to expose a "standard" attribute that represents a street-address or an email-address.

A similar argument can be made to retain scalar attributes that overlap with formal relationships to other entities. A provider who chooses not to support formal relationships should still be able to expose a "standard" attribute that represents a particular type of connection to another type of object.

Complex Attributes of Person (i.e., Relationships of Person to itself)

Basic Identity Management does not representing any true relationships of Person to entities on other targets. However, we may want to define some "fake" relationships between Person and itself in order to represent complex attributes (such as address). See the note regarding "Scalar and Complex Attributes" at the end of the previous section.

Relationship-Type Name

From-Entity

To-Entity

Description

Notes

Person-hasEmail

Person

none (open-ended)

Email-addresses for a Person.

Complex attribute (compare to emailPrimary and emailsSecondary above).

Person-hasPhoneNumber

Person

none (open-ended)

Phone-numbers for a Person.

Complex attribute (compare to phoneNumberPrimary and phoneNumbersSecondary above).

Person-hasIMAddr

Person

none (open-ended)

Instant-Messaging addresses for a Person.

Complex attribute (compare to IMAddrPrimary and IMAddrsSecondary above).

Person-hasPhoto

Person

none (open-ended)

photographic images for a Person.

Complex attribute (compare to IMAddrPrimary and IMAddrsSecondary above).

Person-hasAddress

Person

none (open-ended)

addresses for a Person.

Complex attribute (compare to addressPrimary and addressesSecondary above).

Person-hasEmail

attributeName

Required?

Syntax

Description

Notes

value

REQUIRED

string

An email-address for a Person.

type

Optional

string

Any label for this value of email-address (e.g., "home", "work").

isPrimary

Optional

boolean

True if this value should be treated as the primary value.

At most one value should be marked as primary (for this relationship on any one Person).

isPrivate

Optional

boolean

True if this value should be treated as hidden or confidential (i.e., used only for purposes authorized by the person or provider).

(no note)

displayValue

Optional

string

Any value to prefer for display rather than the actual value.

Person-hasPhoneNumber

attributeName

Required?

Syntax

Description

Notes

value

REQUIRED

string

A phone-number for a Person.

type

Optional

string

Any label for this value of phone-number (e.g., "home", "work", "mobile").

isPrimary

Optional

boolean

True if this value should be treated as the primary value.

At most one value should be marked as primary (for this relationship on any one Person).

isPrivate

Optional

boolean

True if this value should be treated as hidden or confidential (i.e., used only for purposes authorized by the person or provider).

(no note)

displayValue

Optional

string

Any value to prefer for display rather than the actual value.

Person-hasIMAddr

attributeName

Required?

Syntax

Description

Notes

value

REQUIRED

string

An Instant-Messaging address for a Person.

type

Optional

string

Any label for this value of IMAddr (e.g., "home", "work", "mobile").

isPrimary

Optional

boolean

True if this value should be treated as the primary value.

At most one value should be marked as primary (for this relationship on any one Person).

isPrivate

Optional

boolean

True if this value should be treated as hidden or confidential (i.e., used only for purposes authorized by the person or provider).

(no note)

displayValue

Optional

string

Any value to prefer for display rather than the actual value.

Person-hasPhoto

attributeName

Required?

Syntax

Description

Notes

value

REQUIRED

string

A photographic image for this Person.

type

Optional

string

Any label for this value of photo (e.g., "home", "work", "partying".

isPrimary

Optional

boolean

True if this value should be treated as the primary value.

At most one value should be marked as primary (for this relationship on any one Person).

isPrivate

Optional

boolean

True if this value should be treated as hidden or confidential (i.e., used only for purposes authorized by the person or provider).

(no note)

altText

Optional

string

Any value to use as alternate text rather than than the actual (image) value.

503C

Person-hasAddress

attributeName

Required?

Syntax

Description

Notes

formattedAddress

REQUIRED

string

A formatted address for this Person.

If any components specified, constructed from those components.

streetAddress

Optional

string

The street address component of this address-value.

locality

Optional

string

The locality (city) component of this address-value.

region

Optional

string

The region (state or province) component of this address-value.

postalCode

Optional

string

The postal (zip) code component of this address-value.

type

Optional

string

Any label for this value of address (e.g., "home", "work", "vacation".

isPrimary

Optional

boolean

True if this value should be treated as the primary value.

At most one value should be marked as primary (for this relationship on any one Person).

isPrivate

Optional

boolean

True if this value should be treated as hidden or confidential (i.e., used only for purposes authorized by the person or provider).

(no note)

display

Optional

string

Any value to prefer for display rather than than the actual value.

Does this make any sense for address?

Enterprise Identity Management: Organization, Role and Group

The next entities that people typically want to manage are Organization, Group and Role. These represent the enterprise context of each Person. Each person belongs to an organization, may be a member of any number of groups, and may perform any number of roles within an enterprise.

(@TODO: Insert entity-relationship diagram of Person, Organization, Group and Role.)

Organization

The organizational hierarchy of an enterprise usually represents its management structure. Each organizational unit is usually associated with an executive or a manager. Each organizational unit may also have dedicated administrators. Each Person generally belongs to a specific node within the hierarchy. (While a Person may have any number of "dotted-line relationships" to other organizations, each Person usually reports to one manager for purposes of Human Resources management. Even in enterprises that think of themselves as polyarchies, and which may function as multiple hierarchies, there is usually one organizational structure that is considered primary when it comes to dealing with evaluations, compensation, personal issues and professional advancement.)

Scalar Attributes of Organization

attributeName

Required?

Syntax
(if more specific than string)

Properties
(if not single-valued, read-write)

Description

Notes

ID

REQUIRED*

(ID)

sv; read-only post-create

Identifier for this Organization, unique within target.)

Required by protocol. Compare to PSOID in SPML (or to ID in RESTPML).

objectClass

REQUIRED*

sv; read-only post-create

Identifies the class of this object, in this case "Organization".

Required by protocol. Compare to Object-Class (or to class in RESTPML).

Name

Optional

(Name)

Name of this Organization.

(no note)

Description

Optional

Business-friendly explanation of this Organization--e.g., purpose and scope.

(no note)

orgParentID

Optional

(ID)

Identifies (is the ID of) the organization that contains this organization directly. The topmost organization has itself as parent.

This is a view on relationship Org-hasParent-Org, if that relationship is supported.

orgChildrenIDs

Optional

(ID)

Each value identifies (is the ID of) an organization that this organization contains directly.

This is a view on relationship Org-hasParent-Org, if that relationship is supported.

orgAncestorsIDs

Optional

(ID)

Each value identifies (is the ID of) an organization that contains this organization either directly or indirectly. The topmost organization has only itself as an ancestor.

Derived from relationship Org-hasParent-Org, if that relationship is supported. May scale poorly due to indirect derivation and potentially large number of values.

orgDescendantIDs

Optional

(ID)

Each value identifies (is the ID of) an organization that this organization contains either directly or indirectly.

Derived from relationship Org-hasParent-Org, if that relationship is supported. May scale poorly due to indirect derivation and potentially large number of values.

orgNamePath

Optional

String, delimited internally.

The path from the topmost org to this org: a delimited list of org names.

Summarizes containment in a user-friendly manner. GPC: What delimiter should we use?

orgIDPath

Optional

String, delimited internally.

The path from the topmost org to this org: a delimited list of org IDs.

Summarizes containment in a program-friendly manner. GPC: What delimiter should we use?

displayName?

(no note)

costCenter

The cost-center within the enterprise to which this organization belongs.

(no note)

division

Structure within overall organization to which this organization belongs.

(no note)

department

Structure within division to which this organization belongs.

(no note)

managerID

(ID)

Identifier of the manager who is responsible for this organization.

Should match the "ID" of the Person object that represents the manager.

managerName

(Name)

Name of the manager who is responsible for this organization.

Should match the "Name" of the Person object that represents the manager. (If 'managerID' is also supported, then should match the 'Name' of the Person object identified by 'managerID'.)

membersIDs

(ID)

multi-valued

Each value identifies a Person who belongs to (i.e., reports to) this organization.

This is an inverse view on Person-belongsTo-Organization, if that relationship type is supported. May scale poorly due to a potentially large number of values.

membersNames

(Name)

multi-valued

Each value is the Name of a Person who belongs to (i.e., reports to) this organization.

Should match the "Name" of the Person object that represents each member. See attribute 'membersIDs' in this section.

emailPrimary

Optional

(Email)

The main email-address for this Organization.

Compare to Complex Attribute Organization-hasEmail. If both are supported, this value should match the value of hasEmail for this Organization where isPrimary=true.

emailsSecondary

Optional

(Email)

multi-valued

Additional email-addresses for this Organization.

Compare to Complex Attribute Organization-hasEmail. If both are supported, each value should match a value of hasEmail for this Organization where isPrimary=false.

phoneNumberPrimary

Optional

(Phone)

The main phone number for this Organization.

Compare to Complex Attribute Organization-hasPhoneNumber. If both are supported, this value should match the value of hasPhoneNumber for this Organization where isPrimary=true.

phoneNumbersSecondary

Optional

(Phone)

multi-valued

Additional phone numbers for this Organization.

Compare to Complex Attribute Organization-hasPhoneNumber. If both are supported, each value should match a value of hasPhoneNumber for this Organization where isPrimary=false.

addressPrimary

Optional

(Address)

The main address for this Organization, formatted.

Compare to Complex Attribute Organization-hasAddress. If both are supported, this value should match the formattedAddress of hasAddress for this Organization where isPrimary=true.

addressesSecondary

Optional

(Address)

multi-valued

Additional formatted addresses for this Organization.

Compare to Complex Attribute Organization-hasAddress. If both are supported, each value should match a formattedAddress of hasAddress for this Organization where isPrimary=false.

Complex Attributes of Organization (i.e., Relationships of Organization to itself)

Relationship-Type Name

From-Entity

To-Entity

Description

Notes

Organization-hasEmail

Organization

none (open-ended)

Email-addresses for an Organization.

Complex attribute (compare to emailPrimary and emailsSecondary above).

Organization-hasPhoneNumber

Organization

none (open-ended)

Phone-numbers for an Organization.

Complex attribute (compare to phoneNumberPrimary and phoneNumbersSecondary above).

Organization-hasAddress

Organization

none (open-ended)

Addresses for an Organization.

Complex attribute (compare to addressPrimary and addressesSecondary above).

Organization-hasEmail

attributeName

Required?

Syntax

Description

Notes

value

REQUIRED

string

An email-address for a Person.

(no note)

type

Optional

string

Any label for this value of email-address (e.g., "home", "work").

(no note)

isPrimary

Optional

boolean

True if this value should be treated as the primary value.

At most one value should be marked as primary (for this relationship on any one Organization).

displayValue

Optional

string

Any value to prefer for display rather than the actual value.

(no note)

Organization-hasPhoneNumber

attributeName

Required?

Syntax

Description

Notes

value

REQUIRED

string

A phone-number for a Person.

(no note)

type

Optional

string

Any label for this value of phone-number (e.g., "home", "work", "mobile").

(no note)

isPrimary

Optional

boolean

True if this value should be treated as the primary value.

At most one value should be marked as primary (for this relationship on any one Organization).

displayValue

Optional

string

Any value to prefer for display rather than the actual value.

(no note)

Organization-hasAddress

attributeName

Required?

Syntax

Description

Notes

formattedAddress

REQUIRED

string

A formatted address for this Organization.

If any component is specified, this value is constructed from those components.

streetAddress

Optional

string

The street address component of this address-value.

(no note)

locality

Optional

string

The locality (city) component of this address-value.

(no note)

region

Optional

string

The region (state or province) component of this address-value.

(no note)

postalCode

Optional

string

The postal (zip) code component of this address-value.

(no note)

type

Optional

string

Any label for this value of address (e.g., "home", "work", "vacation".

(no note)

isPrimary

Optional

boolean

True if this value should be treated as the primary value.

At most one value should be marked as primary (for this relationship on any one Organization).

display

Optional

string

Any value to prefer for display rather than than the actual value.

GPC: Does this make any sense for address?

Relationships of Organization to Other Entities (Person, Organization, Group or Role)

Relationship-Type Name

From-Entity

To-Entity

Description

Notes

Person-belongsTo-Organization

Person

Organization

Primary organization to which the Person reports.

Person.managerID matches belongsTo->organization.managerID

Organization-hasParent-Organization

Organization

Organization

An Organization contains any number of organizations (single-parent hierarchy).

Organization.orgParentID matches hasParent->organization.ID

Person-belongsTo-Organization

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the Person in this relationship (i.e., the Person who belongs to an Organization).

(no note)

(toID)

REQUIRED

string

The ID of the Organization in this relationship (i.e., the Organization to which this Person belongs).

(no note)

Organization-hasParent-Organization

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the child Organization in this relationship.

(no note)

(toID)

REQUIRED

string

The ID of the parent Organization in this relationship. Navigate in reverse direction to obtain children of a particular parent.

Representing the relationship in this direction (from child to parent) optimizes moving (i.e., changing the parent of) an org. Representing the relationship in the direction from parent to child means you'd have to update both the old parent and the new parent in order to move an org.

Role

Each Role is an abstraction that represents a job function that people perform within an enterprise. These are often called "business-roles", "enterprise-roles" or "job-roles" (in order to distinguish them from the "application-roles" or "duty-roles" that represent privileges a person have in the context of a specific system or application).

Roles are often nested hierarchically. Each Role can have at most one parent. The semantics of containment can vary across different implementations of Role-Based Access Control (RBAC), but each child-role usually extends the parent-role in some sense. SIMPLEST may not need to standardize the semantics of containment (although this could be very valuable), but SIMPLEST will need to distinguish between roles that are assigned and those that are inherited (that is, role-memberships that are implied by the ancestry of a role that is assigned). The roles that are assigned specifically to a Person are generally most salient. A backend IAM system that is responsible for provisioning or compliance may care a great deal about how a role is comprised or is derived.

Scalar Attributes of Role

attributeName

Required?

Syntax
(if more specific than string)

Properties
(if not single-valued, read-write)

Description

Notes

ID

REQUIRED*

(ID)

sv; read-only post-create

Identifier for this Role, unique within target.)

Required by protocol. Compare to PSOID in SPML (or to ID in RESTPML).

objectClass

REQUIRED*

sv; read-only post-create

Identifies the class of this object, in this case "Role".

Required by protocol. Compare to Object-Class (or to class in RESTPML).

Name

Optional

(Name)

Name of this Role.

(no note)

Description

Optional

Business-friendly explanation of this Role--e.g., purpose and scope.

(no note)

roleParentID

Optional

(ID)

Identifies (is the ID of) the role that contains this role directly. The topmost role has itself as parent.

This is a view on relationship Role-hasParent-Role, if that relationship is supported.

roleChildrenIDs

Optional

(ID)

multi-valued

Each value identifies (is the ID of) a role that this role contains directly.

This is a view on relationship Role-hasParent-Role, if that relationship is supported.

roleAncestorsIDs

Optional

(ID)

multi-valued

Each value identifies (is the ID of) a role that contains this role either directly or indirectly. The topmost role has only itself as an ancestor.

Derived from relationship Role-hasParent-Role, if that relationship is supported. May scale poorly due to indirect derivation and potentially large number of values.

roleDescendantIDs

Optional

(ID)

multi-valued

Each value identifies (is the ID of) a role that this role contains either directly or indirectly.

Derived from relationship Role-hasParent-Role, if that relationship is supported. May scale poorly due to indirect derivation and potentially large number of values.

roleNamePath

Optional

String, delimited internally.

The path from the topmost role to this role: a delimited list of role names.

Summarizes containment in a user-friendly manner. GPC: What delimiter should we use?

roleIDPath

Optional

String, delimited internally.

The path from the topmost role to this role: a delimited list of role IDs.

Summarizes containment in a program-friendly manner. GPC: What delimiter should we use?

displayName?

The name to present rather than the actual name of this role.

(no note)

ownerID

(ID)

Identifier of the Person (SME) who is responsible for this role.

Should match the "ID" of the Person object that represents the owner.

ownerName

(Name)

Name of the Person (SME) who is responsible for this role.

Should match the "Name" of the Person object that represents the owner. (If 'ownerID' is also supported, then should match the 'Name' of the Person object identitified by 'ownerID'.)

membershipApproversIDs

(ID)

Each value identifies a Person (SME) who can approve the assignments of persons to perform this role.

Each value should match the "ID" of the Person object that represents a membership-approver.

membershipApproversNames

(Name)

Each value is the Name of a Person (SME) who can approve the asssignments of persons to perform this role.

Each value should match the "Name" of the Person object that represents a membership-approver. (If 'membershipApproversIDs' is also supported, then each value should match the 'Name' of a Person object identified by 'membershipApproversIDs'.)

membersIDs

(ID)

Each value identifies a Person who performs (i.e., has been directly assigned) this role.

This is an inverse view on Person-performs-Role, if that relationship type is supported. May scale poorly (due to a potentially large number of values).

membersNames

(Name)

Each value is the Name of a Person who performs (i.e., has been directly assigned) this role.

Should match the "Name" of the Person object that represents each member. See attribute 'membersIDs' in this section.

Complex Attributes of Role (i.e., Relationships of Role to itself)

(None at this time)

Relationships of Role to Other Entities (Person, Organization, Group or Role)

Relationship-Type Name

From-Entity

To-Entity

Description

Notes

Person-performs-Role

Person

Organization

A Person may perform any number of Roles within an enterprise. Represents direct assignment of roles.

See Person.primaryRole and Person.secondaryRoles.

Role-hasParent-Role

Role

Role

A Role contains any number of roles (single-parent hierarchy).

Role.roleParentID matches hasParent->role.ID

Person-performs-Role

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the Person in this relationship (i.e., the Person who performs a Role).

(no note)

(toID)

REQUIRED

string

The ID of the Role in this relationship (i.e., the Role that this Person performs).

(no note)

isPrimary

Optional

boolean

True if this value should be treated as the primary value. At most one value should be marked as primary (for this relationship on any one Person).

GPC: Do we need 'isPrimary'?

howAssigned

Optional

string

Identifies the mechanism of the assignment of this role to this person. For example, assigned by "Request" or by "Administrator" or by "Rule".

(no note)

whoAssigned

Optional

string

Identifies the source of the assignment of this role to this person. For example, a particular Person (requestor or administrator) or a particular Rule object.

(no note)

dateAssigned

Optional

date-time

Specifies the date and time that this person was assigned to this role. See also dateAssignmentBegins.

(no note)

dateAssignmentBegins

Optional

date-time

Specifies the date and time that the assignment of this role to this person became (or will become) effective.

(no note)

dateAssignmentEnds

Optional

date-time

Specifies the date and time that the assignment of this role to this person lapsed (or will lapse).

(no note)

Role-hasParent-Role

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the child Role in this relationship.

(no note)

(toID)

REQUIRED

string

The ID of the parent Role in this relationship. Navigate in reverse direction to obtain children of a particular parent.

Representing the relationship in this direction (from child to parent) optimizes moving (i.e., changing the parent of) a role. Representing the relationship in the direction from parent to child means that you'd have to update both the old parent and the new parent in order to move a role.

Group

Group is often conflated with Role, even though Role has a distinct semantic meaning. Contributing to this confusion is the fact that a native structure for representing groups (e.g., within LDAP) is often used to represent the membership of each role.

Semantically, however, Groups differ from Roles. Where each Role represents a job function within an enterprise, a Group represents an arbitrary collection. Where a Role generally has only Persons as its members, a Group can contain any kind of object (for example, printers). Where Roles generally form a single-parent hierarchy, each Group can be contained by multiple Groups.

Scalar Attributes of Group

attributeName

Required?

Syntax
(if more specific than string)

Properties
(if not single-valued, read-write)

Description

Notes

ID

REQUIRED*

(ID)

sv; read-only post-create

Identifier for this Group, unique within target.)

Required by protocol. Compare to PSOID in SPML (or to ID in RESTPML).

objectClass

REQUIRED*

sv; read-only post-create

Identifies the class of this object, in this case "Group".

Required by protocol. Compare to Object-Class (or to class in RESTPML).

Name

Optional

(Name)

Name of this Group.

(no note)

Description

Optional

Business-friendly explanation of this Group--e.g., purpose and scope.

(no note)

containsDirectlyGroupsIDs

Optional

(ID)

multi-valued

Each value identifies (is the ID of) a group that this group contains directly. A group must not contain itself, whether directly or indirectly.

This is a view on relationship Group-contains-Group, if that relationship is supported.

containsIndirectlyGroupsIDs

Optional

(ID)

multi-valued

Each value identifies (is the ID of) a group that this group contains either directly or indirectly. A group must not contain itself, whether directly or indirectly.

This is derived from relationship Group-contains-Group, if that relationship is supported. May scale poorly due to indirect derivation and potentially large number of values.

displayName?

Optional

The name to present rather than the actual name of this group.

(no note)

ownerID

Optional

(ID)

Identifier of the Person (SME) who is responsible for this group.

Should match the "ID" of the Person object that represents the owner.

ownerName

Optional

(Name)

Name of the Person (SME) who is responsible for this group.

Should match the "Name" of the Person object that represents the owner. (If 'ownerID' is also supported, then should match the 'Name' of the Person object identitified by 'ownerID'.)

membershipApproversIDs

Optional

(ID)

multi-valued

Each value identifies a Person (SME) who can approve the assignments of persons to (be members of) this group.

Each value should match the "ID" of the Person object that represents a membership-approver.

membershipApproversNames

Optional

(Name)

multi-valued

Each value is the Name of a Person (SME) who can approve the assignments of persons to (be members of) this group.

Each value should match the "Name" of the Person object that represents a membership-approver. (If 'membershipApproversIDs' is also supported, then each value should match the 'Name' of a Person object identified by 'membershipApproversIDs'.)

memberPersonsIDs

Optional

(ID)

multi-valued

Each value identifies a Person who is a member of (i.e., has been directly assigned) this group.

This is an inverse view on Person-memberOf-Group, if that relationship type is supported. May scale poorly (due to a potentially large number of values).

memberPersonsNames

Optional

(Name)

multi-valued

Each value is the Name of a Person who is a member of (i.e., has been directly assigned) this group.

Should match the "Name" of the Person object that represents each member. See attribute 'memberPersonsIDs' in this section.

memberNonPersonsIDs

Optional

(ID)

multi-valued

Each value identifies an object that is not a Person but is a member of (i.e., has been directly assigned) this group.

Should match the "ID" of the object that represents each member of this group (and is not a Person). May scale poorly (due to a potentially large number of values).

memberNonPersonsNames

Optional

(Name)

multi-valued

Each value is the Name of an object that is not a Person but is a member of (i.e., has been directly assigned) this group.

Should match the "Name" of the object that represents each member of this group (and is not a Person). See attribute 'memberNonPersonsIDs' in this section.

Complex Attributes of Group (i.e., Relationships of Group to itself)

(None at this time)

Relationships of Group to Other Entities (Person, Organization, Role or Group)

Relationship-Type Name

From-Entity

To-Entity

Description

Notes

Person-memberOf-Group

Person

Group

A Person may perform any number of Roles within an enterprise. Represents direct assignment of roles.

See Person.primaryGroup and Person.secondaryGroups.

Group-contains-Group

Group

Group

A Group may contain any number of groups (as long as it does not contain itself, whether directly or indirectly).

(no note)

Person-memberOf-Group

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the Person in this relationship (i.e., the Person who is a member of a Group).

(no note)

(toID)

REQUIRED

string

The ID of the Group in this relationship (i.e., the Group of which this Person is a member).

(no note)

isPrimary

Optional

boolean

True if this value should be treated as the primary value. At most one value should be marked as primary (for this relationship on any one Person).

GPC: Do we need 'isPrimary'? I don't think this really makes sense for group-memberships.

howAssigned

Optional

string

Identifies the mechanism of the assignment of this group to this person. For example, assigned by "Request" or by "Administrator" or by "Rule".

(no note)

whoAssigned

Optional

string

Identifies the source of the assignment of this group to this person. For example, a particular Person (requestor or administrator) or a particular Rule object.

(no note)

dateAssigned

Optional

date-time

Specifies the date and time that this person was assigned to this group. See also dateAssignmentBegins.

(no note)

dateAssignmentBegins

Optional

date-time

Specifies the date and time that the assignment of this group to this person became (or will become) effective.

(no note)

dateAssignmentEnds

Optional

date-time

Specifies the date and time that the assignment of this group to this person lapsed (or will lapse).

(no note)

Group-contains-Group

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the containing Group in this relationship.

(no note)

(toID)

REQUIRED

string

The ID of the contained Group in this relationship. Navigate in reverse direction to obtain direct containers of a particular group.

Representing the relationship in this direction (from containing to contained) optimizes validation to prevent circular reference (i.e., preventing any group from containing itself, whether directly or indirectly).

Account Management: Target and Account

Accounts on Targets are the next level of detail in terms of entities to manage. While Person is the primary representation of a user, a need eventually arises to represent individual Targets, which are specific systems or applications to which a person might have access. Each Account represents a Person's access to a Target. NOTE: Accounts are typically the most numerous entity. Since each Person can own multiple accounts, there tend to be many of them.

The "Person-owns-Account" relationship is the prime example of a relationship that spans targets. In most cases, the native representation of an account cannot refer to its owner, which often resides on a separate target. Similarly, the native representation of a Person usually cannot refer to multiple accounts, each of which may reside on separate target. Thus some sort of an IAM system (whether homegrown or a commercial product) usually stores separately information about which Person owns which accounts. (The rare exceptions to this are when authentication is accomplished via single-signon and authorization is based entirely on attributes of the person. In such cases, there is no provisioning--no persistent account-object--and thus probably no persistent relationship between person and account. However, an enterprise may still record for reasons of compliance-reporting which person owns which accounts--see "Provisioning and Compliance" below.)

Target

Each Target represents a logical endpoint, usually a specific system or application to which a Person might have access. A target also can be used to represent something more abstract, for example a collection of physical endpoints, an ordered set of system or applications that depend on one another, or even a specific quality of service for any of the previous. Typically, however, a Target is just a specific instance of some kind of system or application--e.g., A Unix host, an LDAP directory service, a RACF instance, and so forth.

(@TODO: Insert table for attributes of Target? Probably don't need it, since it's part of the Schema.)

Account

Each Account represents an identity within the context of a specific system or application. An account confers access to the target system or application. One Person usually owns each Account--although there are exceptions such as shared accounts (which multiple people may use) and service-accounts (which system components may use but no actual Person necessarily owns).

Traditionally, access to a system or application was represented statically by some form of Account, which was provisioned manually or automatically. In some cases, modern IAM systems now grant equivalent access dynamically, e.g., by evaluating access-policies at runtime. Even where access to the target application is granted dynamically, there is a need for the purposes of access-review and compliance to represent the effective access as if it were an account that had been provisioned. This allows a reviewer to attest that the access granted to each Person is appropriate for that Person.

NOTE: SIMPLEST predefines certain key attributes and relationships for Account, but each Target also defines as part of its the schema additional attributes that are specific to an account on that Target.

Scalar Attributes of Account

attributeName

Required?

Syntax
(if more specific than string)

Properties
(if not single-valued, read-write)

Description

Notes

objectClass

REQUIRED*

Identifies the class of this object, in this case 'Account'.

Required by protocol. Compare to Object-Class (or to class in RESTPML).

ID

REQUIRED*

(ID)

sv; read-only post-create

Identifier for this Account, unique within target.)

Required by protocol. Compare to PSOID in SPML (or to ID in RESTPML).

name

Optional

(Name)

Friendly and mutable name of this Account.

On some targets, the name of an account can differ from its loginName.

loginName

Optional

Name used when authenticating with this Account.

(no note)

password

Optional

Password (shared secret) used to authenticate with this Account.

SPMLv2 Password Capability.

passwordIsExpired

Optional

boolean

If read as 'true', indicates that the password for this Account is no longer valid. Set to 'true' in order to mark the current password value as invalid. (Set to 'false' in order to mark the current password value as valid.)

SPMLv2 Password Capability.

passwordExpireDate

Optional

timestamp

Date and time that the current password for this Account will expire.

SPMLv2 Password Capability.

passwordToValidate

Optional

write-only

Set this to a value in order to determine whether the specified value would be valid as a password for this Account. Expect an error if the password would not be valid.

SPMLv2 Password Capability.

passwordIsReset

Optional

boolean

If read as 'true', indicates that the current password value was generated (and communicated out-of-band to the owner of the Account). Set to 'true' in order to replace the current password with a generated value. (Expect the new password value to be communicated to the owner of the account out-of-band.) The value will remain 'true' until the account-owner sets a new password, at which time the value will be read as 'false'.

SPMLv2 Password Capability.

isDisabled

Optional

boolean

True if this Account's password is currently expired; otherwise false.

SPMLv2 Suspend Capability.

disableDate

Optional

timestamp

Date and time that all access by this Account is scheduled to be prevented. Set a new value (in UTC format with no timezone) in order to change the date and time at which all access by this Account is scheduled to be prevented. Set to an empty value in order to remove the scheduled disablement.

SPMLv2 Suspend Capability.

enableDate

Optional

timestamp

Date and time that all access by this Account is scheduled to be allowed. Set a new value (in UTC format with no timezone) in order to change the date and time at which all access by this Account is scheduled to be allowed. Set to an empty value in order to remove the scheduled enablement.

SPMLv2 Suspend Capability.

ownerID

Optional

(ID)

Identifier of the Person who uses this account.

Compare to Relationship 'Person-owns-Account'. If both are supported, should match the value of "fromID" where the value of 'toID' is the ID of this account.

ownerName

Optional

(Name)

Name of the Person who uses this account.

Should match the "Name" of the Person object that represents the owner. (If 'ownerID' is also supported, then should match the 'Name' of the Person object identitified by 'ownerID'.)

isLocked

Optional

boolean

If read as 'true', indicates that the Target currently (and temporarily) prevents access by this Account. Set to 'true' in order to prevent temporarily access by this Account. Set to 'false' in order to re-enable all access by this Account (if access was temporarily disabled due to native lockOut).

(no note)

(per Schema of Account object-class on Target)

(per Schema of Account object-class on Target)

(per Schema of Account object-class on Target)

(per Schema of Account object-class on Target).

(per Schema of Account object-class on Target).

SIMPLEST predefines certain key attributes and relationships for Account, but each Target also defines as part of its the schema additional attributes that are specific to an account on that Target.

Complex Attributes of Account (i.e., Relationships of Account to itself)

(None at this time--SIMPLEST currently predefines no complex attribute of Account.)

NOTE: Each Target defines as part of its the schema additional attributes that are specific to an account on that Target. Some of these attributes (for example, EBS Responsibilities or RACF Group Memberships) may be complex.

Relationships of Account to Other Entities (Person, Organization, Role, Group or Target)

Relationship-Type Name

From-Entity

To-Entity

Description

Notes

Person-owns-Account

Person

Account

A Person may own any number of Accounts within an enterprise. Each account confers the ability to access a Target (system or application). Each Account has at most one owner (except for privileged accounts--e.g., root or Administrator--to which access may be managed specially--e.g., via checkout). An unowned account is often considered to be a risk from the standpoint of governance and compliance.

See Account.ownerID and Account.ownerName.

Target-accepts-Account

Target

Account

A Target may accept any number of Accounts. Each account confers the ability to access that Target (i.e., login to that system or application).

No need to represent this type of relationship explicitly. The SPML protocol specifies that every object (PSO) exists on some Target. The representation proposed for RESTPML also makes this relationship explicit--a Target contains Object-Classes and an Object-Class contains instances of that Object-Class--e.g., Account. The main purpose for supporting this type of relationship ('Target-accepts-Account') would be to expose additional information about the relationship between the Target and each individual Account. In such cases, it might be just as easy to represent this information as attributes on the Account as to represent this information as attributes on the 'Target-accepts-Account' relationship--unless you don't want this to be visible by default in each Account object.

Person-owns-Account

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the Person in this relationship (i.e., the Person who owns an Account).

(no note)

(toID)

REQUIRED

string

The ID of the Account in this relationship (i.e., the Account that this Person owns).

(no note)

howAssigned

Optional

string

Identifies the mechanism of the assignment of this account to this person. For example, assigned by "Request" or by "Administrator" or by "Access-Policy".

(no note)

whoAssigned

Optional

string

Identifies the source of the assignment of this account to this person. For example, a particular Person (requestor or administrator) or a particular Access-Policy object.

Any number of access-policies could grant an account to a Person. In such cases, this attribute will identify only one source, although there could be many.

dateAssigned

Optional

date-time

Specifies the date and time that this account was assigned to this Person. See also dateAssignmentBegins.

(no note)

dateAssignmentBegins

Optional

date-time

Specifies the date and time that the assignment of this account to this person became (or will become) effective.

(no note)

dateAssignmentEnds

Optional

date-time

Specifies the date and time that the assignment of this account to this person lapsed (or will lapse).

(no note)

Target-accepts-Account

(Implicit in containment of Account by Target.)

(No need to represent this type of relationship explicitly. See Notes on Target-accepts-Account above.)

Provisioning and Compliance: Access-Privilege and Access-Policy

Each Target already includes in its schema a fair amount of metadata: for example, each Object-Class that it exposes and the set of Attribute-Definitions for each object-class:

Identity- and Access-Management (IAM) Systems use target meta-data to add and update objects (PSOs). Provisioning systems in particular uses target meta-data to build forms that guide users in editing objects on various target systems and applications.

IAM Systems also add their own meta-data and management constructs. A Role may have any number of Access-Policies, each of which confers any number of Access-Privileges:

Object-Class

(@TODO: Insert table for attributes of Object-Class? Probably don't need it, since it's part of the Schema.)

Attribute-Definition

(@TODO: Insert table for attributes of Attribute-Definition? Probably don't need it, since it's part of the Schema.)

Access-Privilege

Each Access-Privilege--also known sometimes as an "entitlement-definition"--defines a particular value that a specific attribute of an account may contain. (Note well that an Access-Privilege is a meta-data object--i.e., a particular value for a specific instance of Attribute-Definition associated with an Object-Class that represents an Account on a Target.) When an account has an attribute-value that matches this Access-Privilege, this confers some power or ability within the target system or application. For example, a value of "true" for an attribute named "isAdministrator" might allow one to affect the accounts of others. On a different target, membership in a group called "Administrators" might also allow one to affect other accounts and other types of objects on that target. (NOTE: for convenience, an account's memberships in various groups might be represented as values of an attribute of account called "groups". Although the target natively might persist separately the membership of each group, it is much easier (e.g., for authorization and compliance-reporting) to consume a "groups" attribute, each value of which names a distinct group of which the account is a member.)

Scalar Attributes of Access-Privilege

attributeName

Required?

Syntax
(if more specific than string)

Properties
(if not single-valued, read-write)

Description

Notes

objectClass

REQUIRED*

Identifies the class of this object, in this case 'Access-Privilege'.

Required by protocol. Compare to Object-Class (or to class in RESTPML).

ID

REQUIRED*

(ID)

sv; read-only post-create

Identifier for this Access-Privileg, unique within target.)

Required by protocol. Compare to PSOID in SPML (or to ID in RESTPML).

attributeName

REQUIRED

The name of the attribute for which this access-privilege defines a specific value.

Must match the name of an attribute-definition within the Schema of the Object-Class that represents Account on this Target.

attributeValue

REQUIRED

The specific value (of the attribute specified by the value of 'attributeName') for which this access-privilege defines meta-data.

The combination of attributeName and attributeValue must be unique within this Target--at most one Access-Privilege may define meta-data for a particular value of a particular attribute.

displayAttributeValue

Optional

Any value to display rather than the actual attributeValue--e.g., a formatted value that translates certain components of the value.

Might want to translate OIDs into names, truncate or translate DNs into a form more recognizable to users.

Description

Optional

Business-friendly explanation of this Access-Privilege--e.g., its purpose and scope.

(no note)

technicalDescription

Optional

A more detailed (and possibly less business-friendly) explanation of this Access-Privilege--e.g., the full set of privileges that it confers.

(no note)

ownerID

Optional

(ID)

Identifier (ID) of the Person (SME) who is responsible for the definition of this access-privilege and for its membership--that is, the set of accounts that have attribute-values that match this access-privilege.

(no note)

ownerName

Optional

(Name)

Name of the Person who is responsible for the definition and membership of this Access-Privilege.

Should match the "Name" of the Person object that represents the owner. (If 'ownerID' is also supported, then should match the 'Name' of the Person object identitified by 'ownerID'.)

Complex Attributes of Access-Privilege (i.e., Relationships of Access-Privilege to itself)

(None at this time--SIMPLEST currently predefines no complex attribute of Access-Privilege.)

Relationships of Access-Privilege to Other Entities

Relationship-Type Name

From-Entity

To-Entity

Description

Notes

Attribute-Definition-hasValue-Access-Privilege

Attribute-Definition

Access-Privilege

An Attribute-Definition may have any number of Access-Privileges. Each access-privilege represents a distinct value that the corresponding attribute of an account may contain. Each access-privilege confers a specific power or ability within that Target (e.g., the ability to act in specific ways on objects within that system or application).

No need to represent this type of relationship explicitly. The SPML protocol specifies that every Target defines in its schema the attributes for each object-class that it intends to expose. The value of 'attributeName' within each Access-Privilege refers to a specific attribute-definition for an object-class that represents Account on that Target. There is no need to expose additional information about the relationship between the Attribute-Definition and each Access-Privilege. Even if there were such a need, it would be just as easy to represent this information as attributes on each Access-Privilege as it would be to represent this information as attributes on the 'AttributeDefinition-hasValue-AccessPrivilege' relationship.

Attribute-Definition-hasValue-Access-Privilege

(Implicit--AccessPrivilege refers by name to AttributeDefinition.)

(No need to represent this type of relationship explicitly. See Notes on AttributeDefinition-hasValue-AccessPrivilege above.)

Access-Policy

Each Access-Policy confers a specific set of access-privileges. An Access-Policy can be associated with any number of Roles. (Because multiple roles may confer some of the same privileges, the ability to associate a particular Access-Policy with several different Roles helps to reduce redundancy and to promote consistency.)

In most provisioning systems and compliance systems, the set of access-privileges that a particular access-policy confers is relatively static. Until the access-policy is changed, it will confers the same set of access-privileges. However, in dynamic entitlements services, the set of access-privileges that a particular access-policy confers is determined dynamically--e.g., a decision at runtime based on the evaluation in a particular context of conditions that are defined in the access-policy. Such conditions are not represented in this draft of SIMPLEST because 1) there may be any number of such conditions; and 2) conditions may be complex or proprietary; and 3) other standards (such as XACML) already define a common way to represent such conditions. Any provider is of course free to expose attributes of Access-Policy beyond those proposed here. For now, representing the conditions under which a particular access-policy confers a particular access-privilege seems overly complex. A future version of this proposal might include attributes that represent such conditions if someone were to propose a reasonable way to model them.

Scalar Attributes of Access-Policy

attributeName

Required?

Syntax
(if more specific than string)

Properties
(if not single-valued, read-write)

Description

Notes

objectClass

REQUIRED*

Identifies the class of this object, in this case 'Access-Privilege'.

Required by protocol. Compare to Object-Class (or to class in RESTPML).

ID

REQUIRED*

(ID)

sv; read-only post-create

Identifier for this Access-Privileg, unique within target.)

Required by protocol. Compare to PSOID in SPML (or to ID in RESTPML).

name

Optional

Any (user-friendly and mutable) name for this Access-Policy.

(no note)

description

Optional

Business-friendly explanation of this Access-Policy--e.g., its purpose and scope.

(no note)

comments

Optional

Any notes regarding this Access-Policy.

(no note)

ownerID

Optional

(ID)

Identifier (ID) of the Person (SME) who is responsible for the definition of this Access-Policy and for its associations with Roles.

GPC: Should ownerID and ownerName be multi-valued?

ownerName

Optional

(Name)

Name of the Person who is responsible for the definition of this Access-Policy and for its associations with Roles.

Should match the "Name" of the Person object that represents the owner. (If 'ownerID' is also supported, then should match the 'Name' of the Person object identitified by 'ownerID'.) GPC: Should ownerID and ownerName be multivalued?

roleIDs

Optional

(ID)

multi-valued

Each value identifies (is the ID of) a role that has this Access-Policy.

Compare to Relationship Role-has-Access-Policy. (If both are supported, each value should match a value of 'fromID' within Role-has-Access-Policy where the value of 'toID' identifies this Access-Policy.)

roleNames

Optional

(Name)

multi-valued

Each value names (is the Name of) a role that has this Access-Policy.

Compare to Relationship Role-has-Access-Policy. (If both are supported, each value should match the 'Name' of a Role identified by a value of 'fromID' within Role-has-Access-Policy where the value of 'toID' identifies this Access-Policy.)

accessPrivilegeIDs

Optional

(ID)

multi-valued

Each value identifies (is the ID of) an Access-Privilege that this Access-Policy confers.

Compare to Relationship Access-Policy-confers-Access-Privilege. (If both are supported, each value should match a value of 'toID' within Access-Policy-confers-Access-Privilege where the value of 'fromID' identifies this Access-Policy.)

accessPrivilegeNames

Optional

(Name)

multi-valued

Each value names (is the Name of) an Access-Privilege that this Access-Policy confers.

Compare to Relationship Access-Policy-confers-Access-Privilege. (If both are supported, each value should match the 'Name' of an Access-Privilege identified by a value of 'toID' within Access-Policy-confers-Access-Privilege where the value of 'fromID' identifies this Access-Policy.)

targetIDs

Optional

(ID)

multi-valued

Each value identifies (is the ID of) a Target for which this Access-Policy confers an Access-Privilege.

Derived as a convenience from accessPrivilegeIDs (or Relationship Access-Policy-confers-Access-Privilege).

Complex Attributes of Access-Policy (i.e., Relationships of Access-Policy to itself)

(None at this time--SIMPLEST currently predefines no complex attribute of Access-Policy.)

Relationships of Access-Policy to Other Entities

Relationship-Type Name

From-Entity

To-Entity

Description

Notes

Role-has-Access-Policy

Role

Access-Policy

A Role may have any number of Access-Policies. Any number of Roles may have a specific Access-Policy.

(no note)

Access-Policy-confers-Access-Privilege

Access-Policy

Access-Privilege

An Access-Policy may confer any number of Access-Privileges. Any number of Access-Policies may confer a specific Access-Privilege.

(no note)

Role-has-Access-Policy

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the Role in this relationship (i.e., the Role that has an Access-Policy).

(no note)

(toID)

REQUIRED

string

The ID of the Access-Policy in this relationship (i.e., the Access-Policy that the Role has).

(no note)

whoAssigned

Optional

string

Identifies the source of the assignment of this access-policy to this role. For example, a particular Person (administrator) who added the access-policy to the role.

(no note)

dateAssigned

Optional

date-time

Specifies the date and time that this access-policy was assigned to this Role. See also dateAssignmentBegins.

(no note)

dateAssignmentBegins

Optional

date-time

Specifies the date and time that the assignment of this access-policy to this role became (or will become) effective.

(no note)

dateAssignmentEnds

Optional

date-time

Specifies the date and time that the assignment of this access-policy to this role lapsed (or will lapse).

(no note)

Access-Policy-confers-Access-Privilege

attributeName

Required?

Syntax

Description

Notes

(fromID)

REQUIRED

string

The ID of the Access-Policy in this relationship (i.e., the Access-Policy that confers an Access-Privilege).

(no note)

(toID)

REQUIRED

string

The ID of the Access-Privilege in this relationship (i.e., the Access-Privilege that the Access-Policy confers).

(no note)

whoAssigned

Optional

string

Identifies the source of the assignment of this access-privilege to this access-policy. For example, a particular Person (administrator) who added the access-privilege to the access-policy.

(no note)

dateAssigned

Optional

date-time

Specifies the date and time that this access-privilege was assigned to this access-policy. See also dateAssignmentBegins.

(no note)

dateAssignmentBegins

Optional

date-time

Specifies the date and time that the assignment of this access-privilege to this access-policy became (or will become) effective.

(no note)

dateAssignmentEnds

Optional

date-time

Specifies the date and time that the assignment of this access-privilege to this access-policy lapsed (or will lapse).

(no note)

simplest (last edited 2011-09-27 01:35:03 by gary.p.cole)