SCIM Extension for Privileged Access ManagementSailPointkelly.grizzle@sailpoint.comThycoticben.yoder@thycotic.comBomgarjjones@bomgar.comLieberman Softwarephil@liebsoft.comCyberArkEdward.Nunez@cyberark.com
The System for Cross-domain Identity Management (SCIM) specification provides schemas
that represent common identity information about users and groups. Privileged Access Management (PAM) software
typically makes use of common user and group models - as well as defining additional constructs - to provide
fine-grained authorization and management for privileged access.
This document contains a SCIM 2.0 extension for Privileged Access Management, which includes extensions to
the core User and Group objects, and new resource types and schemas for standard Privileged Access Management
constructs. This extension is intended to provide greater interoperability between PAM software and clients,
a common language for PAM concepts, and a baseline that can be further extended to support more complex PAM
requirements.
Most Privileged Access Management (PAM) software contains external APIs that can be used to manage users,
groups, privileged access, and authorization to privileged data. However, these APIs are not consistent
across different software (e.g. - some software uses REST and some uses SOAP), and each API exposes different
functionality. This makes it difficult for a client to externally manage multiple PAM providers.
The System for Cross-domain Identity Management (SCIM) specification provides schemas that represent common
identity information about users and groups. Privileged Access Management (PAM) software typically makes use
of common user and group models - as well as defining additional constructs - to provide fine-grained
authorization and management for privileged access.
This document contains a SCIM 2.0 extension for Privileged Access Management, which includes extensions to
the core User and Group objects, and new resource types and schemas for standard Privileged Access Management
constructs. This extension is intended to provide greater interoperability between PAM software and clients,
a common language for PAM concepts, and a baseline that can be further extended to support more complex PAM
requirements.
Some providers MAY not support all of the endpoints or data that is described in this extension. When this is
encountered, the PAM provider can safely treat endpoints or data as optional.
A user account that can be used to access the PAM system to manage or access privileged data. This user
can either exist only in the PAM system or can be an external user that is defined in another system
(e.g. - Active Directory or LDAP).
A group of users or other groups that can be used to govern access within the PAM system. This group
can either exist only in the PAM system or can be an external group that is defined in another system
(e.g. - Active Directory or LDAP).
A Container is a logical grouping of privileged data (credentials, etc...) that can be used for
organizational or operational purposes. Access control lists (ACLs) can be applied to a container to
control which users and groups have permissions to the privileged data in the container.
Privileged data is secret information that is protected by the PAM system (e.g. - credentials for a
privileged account, an SSH key, etc...). Privileged data MAY be stored inside of a Container, but does
not have to be. Access control lists (ACLs) can be applied to privileged data to control which users
and groups have permissions to the privileged data. More often, the ACL information is inherited from
the container.
An access control list can be associated with a Container or Privileged Data. This contains information
about which users and groups have access to the Container or Privileged Data, and what rights they have.
An External Store is a system that contains users and groups (e.g. - Active Directory or LDAP) that can
be used by a PAM system. This allows using existing infrastructure and group definitions to provide
authorization, authentication, and information within a PAM system.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
.Throughout this document, values are quoted to indicate that they are
to be taken literally. When using these values in protocol messages, the
quotes MUST NOT be used as part of the value.
In a PAM system, users and groups can either be locally or externally defined. When local, the user or group
exists only on the PAM system. When external, the user or group is defined in an External Store, and is
somehow synchronized into the PAM system. In this case, the PAM system keeps a record of the external user or
group, along with a reference that can be used to correlate the record back to the External Store. To support
this, an optional schema extension "urn:ietf:params:scim:schemas:pam:1.0:LinkedObject" SHOULD be added to the
User and Group resource types.
The "urn:ietf:params:scim:schemas:pam:1.0:LinkedObject" schema contains the following attributes.
The name of the External Source from which the User or Group came. If this is a local User or Group,
this is null. Required if nativeIdentifier is non-null.
The unique identifier of the User or Group on the External Source (e.g. - an LDAP distinguished name).
If this is a local User or Group, this is null. Required if source is non-null.
The following is a non-normative example of a User with the LinkedObject extension.
Members of external groups are stored and managed on the External Store, and not in the PAM system. As a
result, the User and Group representations returned by the PAM system MAY return empty values for the
"groups" and "members" attributes, respectively. Additionally, the PAM system MAY choose to return an
error response with the 400 status code and "invalidSyntax" error type for requests that attempt to
modify or create a group with an invalid configuration. Examples include, but are not limited to:
An external group with any members.
An external group with local Users or Groups as members.
A local group with external Users or Groups as members.
PAM systems define additional constructs to provide enhanced authorization, authentication, and management for
privileged data. To support this, the SCIM PAM extension defines additional ResourceTypes and Schemas that MAY
be implemented by the service provider. If implemented, these ResourceTypes SHOULD support all SCIM operations
. All attributes defined in the schemas are optional unless explicitly marked as
REQUIRED.
A Container is a logical grouping of privileged data that can be used for organizational or operational
purposes.
The Container ResourceType supports reading and managing containers, and has the following properties.
Container/Containersurn:ietf:params:scim:schemas:pam:1.0:Container
Clients MAY have a reference to the Container name but not the ID. For this reason, it is RECOMMENDED that
service providers implement filtering that allows equality matching on the "name" attribute. Example (note
that escaping has been removed for readability):
The "urn:ietf:params:scim:schemas:pam:1.0:Container" defines all common attributes for a Container.
The unique identifier of the Container. REQUIREDThe name of the Container. REQUIREDThe display name of the Container. OPTIONAL. If displayName is unassigned, the name MAY be used as the display name.The description of the Container. OPTIONAL
The type of container. There are no canonical values defined for type, but service providers MAY choose to define
the valid types. OPTIONAL if the PAM system does not support multiple types of Containers.
A complex attribute that defines the parent Container of this Container if the service provider supports
hierarchies of containers. The following sub-attributes are defined.
The ID of the Container that is the parent of this Container in the hierarchy.A URI reference to the Container that is the parent of this Container in the hierarchy.The display name of the Container that is the parent of this Container in the hierarchy.
A complex attribute that defines the User that is the owner of this Container. OPTIONAL. The following sub-attributes
are defined.
The ID of the User that owns this Container.A URI reference to the User that owns this Container.The display name of the user that owns this Container.
A multi-valued complex attribute that contains the PrivilegedData that resides in this Container. Service
providers MAY choose to make this attribute have a "returned" value of "request" if the list of privileged
data could be very large. Using this option will prevent this attribute from being returned upon retrieval
unless explicitly requested using the "attributes" query parameter. The following sub-attributes are
defined.
The ID of the PrivilegedData.A URI reference to the PrivilegedData.The displayable value of the PrivilegedData.The type of the PrivilegedData.
The following is a non-normative example of a Container.
Privileged data is secret information that is protected by the PAM system (e.g. - credentials for a privileged
account, an SSH key, etc...). Privileged data MAY be stored inside of a Container, but does not have to be.
The PrivilegedData ResourceType supports reading and managing privileged data, and has the following properties.
PrivilegedData/PrivilegedDataurn:ietf:params:scim:schemas:pam:1.0:PrivilegedData
The "urn:ietf:params:scim:schemas:pam:1.0:PrivilegedData" defines all common attributes for a PrivilegedData.
The unique identifier of the PrivilegedData. REQUIREDA descriptive name for this piece of PrivilegedData. For example, root@mylinuxhost. REQUIREDA description for this piece of PrivilegedData.
The type of PrivilegedData. The value will be dependent on what is supported by the PAM system. Examples
include 'credential', 'ssh key', 'file', etc... OPTIONAL.
The following is a non-normative example of a PrivilegedData.
A ContainerPermission contains authorization information that describes which rights a User or Group has on a
Container. This is a piece of an Access Control List that contains all information about a specific User or
Group in relation to a specific Container. Typically, permissions that are granted on a Container apply to
all privileged data that resides in the container.
The ContainerPermission ResourceType supports reading and managing permissions that a User or Group have on
a Container, and has the following properties.
ContainerPermission/ContainerPermissionsurn:ietf:params:scim:schemas:pam:1.0:ContainerPermission
It is expected that clients will need to find the all permissions on a specific Container, permissions
that are granted to a specific User or Group, or permissions for a specific user or group on a specific
container. For this reason, it is RECOMMENDED that service providers implement filtering that allows
equality matching on the "container.value", "user.value", and "group.value" attributes. Example (note
that escaping has been removed and newlines added for readability):
The "urn:ietf:params:scim:schemas:pam:1.0:ContainerPermission" defines all common attributes for a ContainerPermission.
The unique identifier of the ContainerPermission. REQUIRED
A complex attribute that references the Container that these permissions apply to. The following sub-attributes
are defined. REQUIRED
The ID of the Container that these permissions apply to.A URI reference to the Container that these permissions apply to.The name of the Container that these permissions apply to.The display name of the Container that these permissions apply to.
A complex attribute that references the User that these permissions apply to. Either this attribute or "group" is required.
The following sub-attributes are defined.
The ID of the User that these permissions apply to.A URI reference to the User that these permissions apply to.The display name of the User that these permissions apply to.
A complex attribute that references the Group that these permissions apply to. Either this attribute or "user" is required.
The following sub-attributes are defined.
The ID of the Group that these permissions apply to.A URI reference to the Group that these permissions apply to.The display name of the Group that these permissions apply to.
An array of strings that are the names of the rights that the User or Group has on this Container. There are
no canonical values defined for rights, and these will vary between service providers.
The following is a non-normative example of a ContainerPermission.
A PrivilegedDataPermission contains authorization information that describes which rights a User or Group has on a
PrivilegedData. This is a piece of an Access Control List that contains all information about a specific User or
Group in relation to a specific piece of privileged data. This resource MUST only return permissions that are
granted directly to the PrivilegedData. Permissions that are inherited from a Container on the PrivilegedData
MUST NOT be returned. This resource type and schema are OPTIONAL if the service provider does not support
permissions on privileged data.
The PrivilegedDataPermission ResourceType supports reading and managing permissions that a User or Group have on
a PrivilegedData, and has the following properties.
PrivilegedDataPermission/PrivilegedDataPermissionsurn:ietf:params:scim:schemas:pam:1.0:PrivilegedDataPermission
It is expected that clients will need to find the all permissions on a specific PrivilegedData, permissions
that are granted to a specific User or Group, or permissions for a specific user or group on a specific
privileged data item. For this reason, it is RECOMMENDED that service providers implement filtering that
allows equality matching on the "privilegedData.value", "user.value", and "group.value" attributes.
Example (note that escaping has been removed and newlines added for readability):
The "urn:ietf:params:scim:schemas:pam:1.0:PrivilegedDataPermission" defines all common attributes for a PrivilegedDataPermission.
The unique identifier of the PrivilegedDataPermission. REQUIRED
A complex attribute that references the PrivilegedData that these permissions apply to. The following sub-attributes
are defined. REQUIRED
The ID of the PrivilegedData that these permissions apply to.A URI reference to the PrivilegedData that these permissions apply to.The display name of the PrivilegedData that these permissions apply to.
A complex attribute that references the User that these permissions apply to. Either this attribute or "group" is required.
The following sub-attributes are defined.
The ID of the User that these permissions apply to.A URI reference to the User that these permissions apply to.The display name of the User that these permissions apply to.
A complex attribute that references the Group that these permissions apply to. Either this attribute or "user" is required.
The following sub-attributes are defined.
The ID of the Group that these permissions apply to.A URI reference to the Group that these permissions apply to.The display name of the Group that these permissions apply to.
An array of strings that are the names of the rights that the User or Group has on this PrivilegedData. There are
no canonical values defined for rights, and these will vary between service providers.
The following is a non-normative example of a PrivilegedDataPermission.
The following section provide representations of schemas for the schema extensions and new schemas
introduced in this document.