SAML addresses the problem of how to exchange identity information between systems. That begs the question: how do these various systems set up the accounts and services that are being accessed? We learned in Chapter 5 that this happens in the provisioning and propagation phases of the digital identity lifecycle. Because a single identity may need to be used in multiple systems, automated provisioning is necessary. Automated provisioning is supported through the use of provisioning standards.
SPML , or Service Provisioning Markup Language, is an XML-based language for exchanging provisioning requests and responses. As mentioned at the beginning of this chapter, SPML is rather new and supported only by a few vendors, but it, or something like it, will be necessary to create automated identity systems. The goal of the SPML specification is to support the automation of all aspects of managing an identity throughout its entire lifecycle, including creating, amending, or revoking the identity. This section will discuss SPML and its use in automated provisioning.
SPML is defined in terms of three primary roles:
The entity making the provisioning request.
A SPML-enabled software service that responds to SPML requests from the RA.
The entity that performs the provisioning. Sometimes the PSP and PST are the same software agent, but they needn't be. The crucial difference is that while the PSP is required to understand SPML, the PST is not. So the PSP may be a frontend for other software services that do not understand SPML.
Like SAML, SPML defines a request-response protocol, with the RA making a request, in SPML, and the PSP returning a response or appropriate error code, in SPML.
There must be a preexisting trust relationship between the RA and the PSP. This trust relationship could be represented using SAML and transported using the web services profile shown in Figure 11-5. The SAML assertions would be carried in the SOAP header, and the SPML request and response would be transported as the payload in the SOAP body.
PSPs can make requests of other PSPs. So, for example, while the PST is not required to understand SPML, if it does, then the PSP communicating with it is functioning as an RA making a request of another PSP.
An example will serve to clarify the relationships and responsibilities of RAs, PSPs, and PSTs. Figure 11-6 diagrams an example of the provisioning activities related to creating a new account in an e-commerce system. The e-commerce sign-up process, acting as an RA, sends a SPML request to the e-commerce provisioning server, acting as the PSP, asking that a new e-commerce account be created. As we've seen, the SPML request could be carried in a SOAP message with a SAML authentication in the header establishing the identity of the RA. The e-commerce provisioning server, acting as the PSP, would use the SAML assertion to determine whether the RA is authorized to create an account of the type specified in the request and, if so, proceed.
The e-commerce provisioning server completes four different actions with four different PSTs to complete the provisioning action:
The e-commerce provisioning server creates an appropriate record in the account database. In this case, the account database is acting as a PST. This action is authenticated in whatever manner the database is configured to use, and the e-commerce provisioning server translates the SPML request into SQL and sends it to the account database using JDBC or something similar.
The e-commerce provisioning server creates a directory on the filesystem for storing files related to the new account using JNDI or something similar. Again, the commands and authentication are those appropriate to the PST, in this case, a filesystem.
The e-commerce provisioning server requests that the web server's authentication system, perhaps an LDAP server, create an account. Like actions 1 and 2, this task is accomplished by translating the SPML request into the native command set of the LDAP server, perhaps JNDI.
The e-commerce provisioning server, acting as an RA, sends a new SPML request to the credit card company's PSP, requesting that a merchant account be provisioned. The credit card company's PSP, in turn, makes some number of requests of other PSTs or PSPs to service the request.
Note that in all but the last task, the PSP translated the SPML request into the native API of the PST, because none of these servers understood SPML.
As a provisioning language, SPML creates and manages identifiers. There are two kinds of identifiers: those used globally within the provisioning system and those used by each of the target systems, or PSTs. These identifiers might be used to refer to subjects or resources.
The identifiers created by the PSTs need to be unique only within the PST's namespace. For example, in the e-commerce system discussed previously, the identifier in the accounts database would be the record ID. The identifiers associated with an individual PST are called Provisioning Service Target Data Identifiers (PSTD-IDs).
To be useful, PSTD-IDs must be related to some global identifier in the overall system. The SPML standard refers to this as a Provisioning Service Object Identifier (PSO-ID). The RA might choose the PSO-ID, or the PSP might manage it. In our example, the user is probably prompted for a memorable ID when she signs up, and so the RA would choose it, ensuring that it's unique. The PSP or RA must keep track of the PSO-IDs, and map them to the various PSTD-IDs associated with the identity.
SPML requests take one of several forms:
<addRequest/>
Used to request the creation of an account
<modifyRequest/>
Used to request that an account be updated
<deleteRequest/>
Used to request that an account be deleted
<searchRequest/>
Used to query the PSP about accounts and their properties
<schemaRequest/>
Allows an RA to request the provisioning schema from the PSP
These requests can have operational attributes attached and can be done in batch as well as singleton mode. The requests for adding, modifying, deleting, and searching the PSP are self-explanatory—they correspond to the types of actions you would expect to see in any data store. The schema request allows an RA to discover the types of requests it is allowed to use so that it can build appropriate add, modify, delete, and search requests. Discovery allows SPML to be flexible, because RAs can, if properly fashioned, react to changing PSP provisioning schema and adjust their actions accordingly.
To see how this might work, consider an employee provisioning system that manages the accounts on a Windows domain, GroupWise system, corporate HR directory, and Unix file server. Whenever a new employee is hired, new accounts are provisioned on each of these systems from a single action on the HR system. Now, imagine that the company has added a new corporate intranet that requires that an identity be provisioned on a web server. Rather than hardcoding into the RA the list of systems on which employees should receive accounts, we could write RA to query the PSP before making its request for the list. Now, by merely adding the new system to the schema of the PSP, any RA can create the right accounts.
To give you an idea of what a SPML request-response pair looks like, consider the following example of an <addRequest/>
element that creates an email account for a user:
<addRequest> <attributes> <attr name="objectclass"> <value>urn:...:SPML:interop:interopUser</value> </attr> <attr name="cn"> <value>Jane Doe</value> </attr> <attr name="mail"> <value>Jane.Doe@windley.com</value> </attr> <attr name="description"> <value>Jane Doe interopUser Subscription</value> </attr> <attr name="memberLevel"> <value>1</value> </attr> <attr name="company"> <value>Jane Doe Supply Co</value> </attr> <attr name="registrationTime"> <value>17-Nov-2004 12:00 </value> </attr> </attributes> </addRequest>
As usual, the XML is verbose, but perfectly readable. The PSP might respond to this request as follows:
<addResponse result = "urn:...:SPML:1:0#success"> <identifier type= "urn:...:SPML:1:0#EMailAddress"> <id>Jane.Doe@windley.com</id> </identifier> <attributes> <attr name="mailBoxLimit"> <value>50MB</value> </attr> </attributes> </addResponse>
This response returns the new identifier and an attribute giving the mailbox size. Other examples of SPML requests and responses can be found in the OASIS Core document on SPML at the Oasis Provisioning Services Technical Committee's web site.[*]