X/Open Single Sign-on Service (XSSO) -
Pluggable Authentication Modules
X/Open Single Sign-on Service (XSSO) -
Pluggable Authentication Modules
Copyright © 1997 The Open Group
XSSO Account Management Services
The essential objective of XSSO Account Management services is
to provide support for the development of applications to implement
co-ordinated management of account information bases in a
heterogeneous set of security domains (platforms and applications).
As described in
Introduction to Single Sign-on
an individual end-user of a distributed system typically requires the
capability to utilize many different platforms and applications
(domains). To provide this capability an individual needs to be
represented by entries in the account information bases appropriate
to each of those domains.
Each individual domain will have its own set of account attributes
to be managed. These are referenced to domain specific identities
and have domain specific formats. The requirement on XSSO is to
provide the capability of managing a minimum common core set of such
attributes with the capability for future extension.
- The business benefit sought from the specification of the XSSO
ACM Service is a reduction in the number of administrative interactions
with the system to manage individual accounts. In an approach based on a
minimum common core set of attributes, the extent to which these
benefits are realisable within a particular system depend upon an
assumption that any additional attributes required for accounts
by a particular domain can be generated on basis of domain defined
defaults or derived from XSSO provided attribute values on the basis
of domain defined rules. As an example, under DCE the creation of a
login account requires the previous creation of the appropriate
principal, group and organization registry entries.
Scope of XSSO Account Management
XBSS Functional Requirements
The core requirements of XSSO Account Management are based upon
requirements detailed in the XBSS. These encompass both Account
Level Policies and System Level
The following requirements are applicable to the administration of
By default all accounts within the scope of a policy domain shall be
uniquely identified for the purposes of authentication and security
audit. This may be achieved by the use of a single unique identity
within the policy domain or by a one to one mapping of primary domain
identity to secondary domain identity if a single identity
representation cannot be used for all services within the policy domain.
- It is acceptable for identities or attributes used solely for the
purposes of authorization to be shared by several principals. Examples
of such use are for the support of roles and anonymous ftp services.
Authentication data shall include information for
verifying the identity of individual principals.
Policy attributes of individual principals shall be maintained (for
example, groups, time intervals, location).
At least a primary group is
- Some implementations support the concept of supplementary groups in
which a principal may exercise the rights applicable to a set of
Within the XSSO, the concept of a group is
subsumed as an account attribute and is not separately distinguished.
An administrator shall be able to enable and disable an account.
An administrator shall be able to enquire of status information for all
active principals and all accounts (enabled or disabled).
Initialize and change an account password.
Set password expiration at any time, including before first use.
Audit event pre-selection mask by account.
The following XBSS requirements are applicable and controlled on
a policy domain wide basis:
An administrator shall be able to configure the period by which
subsequent sign-on attempts are delayed after a failed sign-on attempt.
Configure password ageing parameters.
Configure period and frequency of end-user notification of password expiry.
Configure password re-use controls on the basis of at least one of:
Period of time.
Number of password changes.
Minimum change period.
Configure required complexity of end-user entered passwords.
Basic Functional Requirements
The XSSO ACM-API is required to support the following functions
within the domain supporting the interface:
- Add Account
Create a new account.
- Delete Account
- If done thoroughly, this encompasses the deletion or reassignment of
system resources currently assigned to the account according to
the applicable policy. For example,
files owned by the account should be deleted or have their ownership
changed. Access authorizations specifically assigned for the account
should be removed. For example, this may imply a change of ACLs and file
- Update Account
Change the value of account attributes.
- List Accounts
List all accounts or accounts based on optional selection criteria. This may
include the selective listing of "active accounts" for those domains in
which the interpretation of an "active account" is defined.
- Disable/Enable Account
Disable and enable the use of an account to access the services of the domain.
The disabling of an account should include, where possible, the
disabling of any scheduled sessions for the account and the termination of any
interactive sessions for the account that are in progress at the time the
account is disabled.
- Update Account Authentication Information
This includes update of account authentication information by an
administrator, including a forced change on first usage,
and by the end-user via XSSO Sign-on Services.
An administrator may also be able to update the method or methods
In the first version of XSSO the only form of authentication information
required to be supported are passwords and pass phrases but the
specification should not preclude future extensibility.
- Add Account Attribute
Create a new attribute that may be assigned to accounts.
- Delete Account Attribute
Delete an attribute. Where possible this should include the removal of
this attribute from all accounts, or should only succeed if the
attribute is not currently assigned to any account.
- Set Account Attributes
Set the values of attributes for an account.
- Get Account Attributes
Retrieve the attributes assigned to an account.
Account Management Authorities
The account management authorities identified below are disjoint
authorities that are used to control the exercise of Account Management
Functions in support of the principles of Least privilege and Separation
Required to create, populate, and modify accounts.
Excludes modification of audit attributes, authentication information
and account enabling, disabling and deletion.
Required to assign attributes to accounts. This authority may be
parameterized to control the modification of discrete sets of
- The next two authorities can be considered as specific examples of the
authority with the sets of attributes which they cover having
particular security significance.
Required to modify account audit attributes.
Required to set and modify account authentication information
attributes, and to enable, disable, and delete accounts.
Required to configure XSSO UAM services.
For example to add/modify/delete
domain types and domain instances.
Common Core Account Attributes
The common core attributes for accounts represent the minimum set of
attributes required by XBSS for the purposes
of both account level and system level policy enforcement.
These attributes are not necessarily applicable nor mappable to all
component account registries within a policy domain but a XSSO
implementation has to be capable of supporting their management.
The common core attributes comprise:
Human readable text string. Must be unique within the domain of definition.
Domain internal accountID that must be unique within the domain of definition.
- Account Enabled Flag
Account enabled if flag set, account disabled if unset.
- Account Last Used
Date and time the account was last used in an authentication operation.
- Authentication Information
For the current specification this comprises at least a password. In
the future it may include information such as authentication method.
- Authentication Information Expiry
The date and time at which the current authentication information
expires at which system level policy may enforce an authentication
information change. Appropriate setting of this attribute can force an
authentication information change on the next use of the account for a
- Account Audit Identity
Identity assigned to an account for audit purposes within domain.
(May be the same as Account_ID.)
- Account Audit Pre-selection Mask
Configuration of audit profile for account for those component
services that support the control of audit service by account.
- Authorization Attributes
Set of authorizations assigned to account. These may include
access identities, roles identities, service specific privileges, and
These may be specific to each component service within a XSSO policy
- Account Environment Data
Information that defines the environment to be created on
session establishment within which the account is required to operate.
For example, shell or application, home directory, environment
variables, resource quotas, default resource access permissions, and
These will be specific to each component service within a XSSO policy
The interface style required to support XSSO is that in which the minimum
information necessary to identify the
account is always required and all parameters, whether core or extended
are passed as a list of attribute/value pairs as and when required.
- The issue of atomicity of operations and locking has been discussed and
the need to identify any implicit locking mechanisms in the use
of the interface identified. This is only of concern in update operations.
The semantics of the operation require defining. There are two possible
Replace complete account information with information supplied in
function call, or
Add or replace only the specific information included in the function
Management of Account Information for Multiple Services
A concept of XSSO Account Administration is that XSSO provides a
common management interface to account information for all the component
services within an XSSO Policy Domain.
Each component service may identify its account attributes by
and represent them in different formats. Each domain may also utilize
different naming schemes for account identities. It is therefore necessary
that functionality is included in an implementation of XSSO UAM to
enable an administrator to configure the mapping and XSSO sign-on
components, such as PAM, to be able to get the mapping to support
secondary sign-on operations.
Such mappings may be based on two approaches:
In which the secondary domain representation of an identity or attribute
may be derived from the primary domain representation on the basis of a
In which the mapping cannot be derived on the basis of a transformation
rule but has to be explicitly defined.
The XSSO administrative application management information base
requires to hold the following information:
- Register of Domain Types
This is a register of the different types of domains that are integrated
with and managed by the XSSO administrative application. For each
domain type, a list of the domain attributes is maintained.
- Register of Domain Instances
This is a register of instances of domains managed by the XSSO
administrative application. For each instance of a domain, its location
and domain type is maintained.
- Register of Accounts
This is a register of the accounts managed by the XSSO
administrative application. For each account a list of the domain
instances within which it is registered and the attributes assigned to
it within each domain instance are maintained. This may include copies
of the credentials required
to authenticate to the domain if required to support secondary sign-on.
The XSSO may not necessarily maintain a copy of the attributes assigned
within each domain instance provided that it can retrieve the
information from the domain itself when required.
- Default Account Profiles
To facilitate the assignment of attributes across multiple domains to
accounts and the simultaneous registration of principals in
multiple domains then a set of account profiles may be defined. These
may include rules for derivation or look up of secondary domain specific
attributes based on
XSSO domain based attributes.
Registry of Domain Types
For each domain typ, a set of attributes is required to be registered.
For each attribute the following information may be required:
The domain type to which the attribute belongs.
The internal label by which the attribute is referenced.
The human readable label used to reference the attribute.
- Attribute_Format (Encoding)
The format in which the attribute value is represented for storage and
The rule by which the default value of this attribute is derived.
The domain specific authorities that have to be possessed by a caller of
the ACM-API in order to query or modify this attribute.
XSSO Account Management Implementation Considerations
Mapping of Administrative Authorities to XSSO UAM Agents
An XSSO implementation needs to be able to map the domain specific
authorities required to manage the attributes within the domain to the
XSSO administrative authorities and roles that it supports. That is, an
XSSO agent requires sufficient privilege to manage the domain that it
services. The exercise of those privileges must be matched to the
authorization assigned to the initiating administrator principals.
The security context of an XSSO agent invoked within a specific domain
on behalf of an XSSO
Administrator is required to reflect the security context of the XSSO
XSSO Management Information Base Initialization
An implementation is required to define how the XSSO Management
Information Base is initialized.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.