SPML 2.0 Concepts

Introduction This document outlines the concepts of SPML 2.0 and how these address the PSTC’s requirements for SPML 2.0. This document attempts to capture the consensus reached at F2F#5 on this subject. The body of this discussion may also contribute to non-normative content in the specification.

In summary, SPML 2.0 extends the 1.0 definition of provisioning so as to better:  reflect the provisioning domain (including account-specific operations)  support complex objects (including relationships between objects)  encourage interoperability between provisioning systems

Glossary Wherever practical, we use the terminology and concepts of SPML 1.0. However, some meanings have been adapted and some are mapped to new terms or simpler synonyms.

Term Synonym Description Change Requesting Authority requestor A client of a Unchanged. (RA) provisioning service Provisioning Service provider A server of Unchanged. Provider provisioning. Target endpoint A logical endpoint Implicit in SPML 1.0. for provisioning. Explicit in SPML 2.0. Represents any number of actual endpoints. Provisioning Service object A uniquely Unchanged. Object (PSO) identified data structure. Typically represents an information object on a target. Provisioning Service object An object created, Removed in SPML 2.0. Target Data (PSTD) modified or deleted Now treated as a on a target by a provisioning service provider. object (PSO). Interface A named set of New in SPML 2.0 operations. Capabilities A map that specifies New in SPML 2.0 for each PSO type the list of interfaces the provider supports. Requesting Authority (RA) The concept of a requesting authority is unchanged from SPML 1.0. The requestor of provisioning services is a program that the provider (PSP) trusts.

NOTE: This term describes a role in the protocol flow rather than a specific class of software since a provider can act as a requestor to another provider. In this sense, “requestor” and “provider” are similar to “client” and “server”.

Provisioning Service Provider (PSP) The concept of a provisioning service provider is unchanged from SPML 1.0. The provider is a program that knows how to manage accounts and other objects on one or more targets.

Target A target is a logical endpoint for provisioning. The concept of a target was implicit in SPML 1.0—for example, in the notion of a provisioning service target data object (PSTD). SPML 1.0 implied one-to-one relationship between target and PSP: each PSP was a target.

SPML 2.0 allows each provider to expose one or more targets to requestors. Provisioning operations that expose a “target” parameter allow the requestor to specify the set of targets on which the provider should operate. In this sense, each target represents a choice that the provider exposes to the requestor.  A “black-box” provider offers no choice to a requestor; such a provider exposes only one target. The provider alone decides the actual endpoints for any provisioning operation.  A “white-box” provider exposes more than one target and allows a requestor to specify the target(s) for provisioning. However, since the target is a logical endpoint, the provider retains control over the actual endpoints.

A target may represent any number—i.e. zero, one or more—actual endpoints. A provider can use the target to expose a friendly name or a functional description that the requestor may recognize. A provider may also use a target to group related endpoints— for example, the set of endpoints required to access a particular application or service. In essence, a target abstracts the underlying topology so that the provider doesn’t need to exposes it and the requestor doesn’t need to understand it.

Extending SPML to include explicit support for Targets is a direct example of reflecting more of the provisioning domain in the SPML protocol. Provisioning Service Object (PSO) The concept of a provisioning service object is only slightly changed from SPML 1.0. A provisioning service object is still a uniquely identified data structure managed by the provider that the requestor can manipulate. A PSO typically represents an information object on a target.

The difference is that each PSO is bound beneath a target in SPML 2.0. Since each provider now exposes at least one target, and since requestors are allowed to provision to specific targets, it follows that each PSO relates to a target.

Interfaces and Capabilities The concepts of interfaces and capabilities are new in SPML 2.0. The mandatory operations defined as the “core” of SPML 1.0 remain generic. However, SPML 2.0 also specifies several optional interfaces.

Optional interfaces define related operations. One optional interface defines search operations (the ‘search’ operation was optional in SPML 1.0). Another optional interface defines operations to enable and disable provisioning service objects. A third optional interface defines operations to manipulate passwords. (These operations are common and useful in managing accounts, but not every PSO is an account. It makes little sense to set a password on an organizational unit. How can a provider tell requestors which operations make sense for which types of objects?)

Capabilities declare the interfaces supported for each type of object. In SPML 2.0, each target advertises its capabilities. That is, each target specifies the set of interfaces that it supports for each type of provisioning service object (PSO). Allowing each target to specify the set of operations it supports for each type of PSO allows SPML 2.0 to define additional operations without “hard-coding” the set of object types to which they apply. This enables the SPML specification to reflect the domain of account-centric provisioning without imposing undue burden (and without imposing undue restriction) on implementers.

Custom interfaces extend SPML while preserving interoperability. Perhaps more importantly, any implementer can use the same technique to define additional interfaces and to share them with other implementers. Since XML Schema requires a namespace, implementers retain control over their own definitions and over sharing them. This allows vendors and other implementers deploying SPML to publish and to refine interoperable specifications without having to wait on a standards body to ratify them.

Provisioning Service Target Data (PSTD) The concept of a provisioning service target data object has been removed from SPML 2.0. Each target-specific information object is now treated as a provisioning service object (PSO). Put differently, every PSO is now target-specific. Relationships SPML 2.0 will provide explicit support for modeling relationships. Relationships are an important tool for modeling the domain of provisioning. SPML 2.0 will support two explicit relationship types, Containment and Reference. Containment relationships are hiearchical—for example, an organizational tree. Reference relationships are arbitrary— for example, group memberships.

An object type could support both types of relationships. For example, suppose that a particular target allows group definitions to be nested. In this case, each group may contain other groups. A group might also refer to (other objects as) its members. Each of those member objects could refer to one or more groups.

Containment relationships The SPML “core” interface will support containment relationships. Every object (PSO) is bound beneath some parent—the default parent is the target.

An optional “containment” interface allows a requestor to specify a new parent for an object. (As with any optional interface, the capabilities of the target specify the types of object for which the provider supports the interface. For example, a provider might support the containment interface for organizational units but not for accounts.)

Reference relationships TBD. One or more optional interfaces will support reference relationships. We currently envision support for directed, point-to-point relationships. We envision being able to:  Add or remove reference relationships (of a specified type) between two specified objects.  Query for the objects to which a specified object refers (filtered by a specified relationship type).  Query for the objects that refer to a specified object (filtered by a specified relationship type).