I interviewed Glenn MacDonald  for this topic.  Glenn is a Senior Software Engineer at Citrix. He has been with Citrix since 2003 and has worked on every release of Password Manger.  He has a Masters degree in Computing Science from Simon Fraser University and over fifteen years of software development experience.  The interview did not actually take place on the yacht, below.

Q: When did CPM begin to provide provisioning?
A:  The CPM Provisioning feature was introduced during the Nassau release in 2005. The intent of this feature was to empower CPM administrators with the ability to provide users' secondary credentials directly to CPM, rather than forcing users to do so.  Being unable to do this had been an administrator pain point during CPM roll outs and when new applications were added to deployments.
In  a sense, provisioning in CPM provides additional security, in removing the responsibility from users for providing secondary credentials,  as users tend to do things like write down their passwords before entering them.

Provisioning in CPM increases the security by avoiding the initial distribution of credentials details directly to the user. Typically this is done by a less secure method such as a memo, voice mail or email.Another focus of the feature was to provide a means to integrate with existing identity management and provisioning systems (e.g. Courion Account Courier).

Q: Does CPM provisioning set up user accounts in applications?
A: No, it just informs CPM of the users' the credentials.

Q: How does it work?
A: The new web service (the Provisioning service) responsible for receiving the provisioning commands was added to the CPM Service.  These commands are added to a per-user queue located in the user specific container of the central store. Eventually the Plugin executes the queued commands to complete the provisioning action.

Q: Is it really that simple?

A: Of course not! There are lots of details to do this securely, but that's the basic flow.

 Q: Can you elaborate on those security details?
A:  Recall that the CPM Plugin protects a user's credentials using user specific keys. (i.e. Only the Plugin running in a user session can obtain the keys). This implies that it is impossible for the Provisioning service to directly execute the commands and alter the user's central store data. (i.e. the service can't add a credential because it doesn't have the key to protect the secrets).  This is why the commands are queued until a Plugin running as the user requests them. The service is completely responsible for the life cycle and encryption of the queued commands.

The Plugin does not directly access the queued commands - it obtains them from the Provisioning service over an SSL connection. Once the Plugin has successfully executed the commands, it informs the service that the queue can be deleted.
 
Q: Is the provisioning feature standards-based, since there are many provisioning products out there to integrate with?
A:  As a matter of fact, it is.  To ease third party integrations, we opted to use the SPML V2.0 open standard. The Service Provisioning Markup Language (SPML) is an XML-based framework, developed by OASIS, for exchanging user, resource and service provisioning information. Additionally, many identity management systems already support SPML 2.0.  A connector is required for identity management integration.

Q: Why do I need a custom connector if my identity management system already supports SPML 2.0?
A: To understand why a custom connector is needed, you need to consider the conceptual differences between provisioning for CPM and provisioning in general.

Consider a typical provisioning scenario from the perspective of an administrator of an identity management system. A new employee has joined the company and needs to be provisioned with a domain account and specific accounts for SAP, Outlook, etc. The administrator will request that an SAP account get created. To do this, the identity management system will send a message to the Provisioning Service Provider (PSP) for SAP.

"Hey SAP PSP, create a new account with user name=baracko and password=prez"
The Provisioning Service Provider will create the account and return a reference ID for the account.

Next, the administrator would want to provision CPM with the newly created SAP credential. The message that the CPM Provisioning Service needs to receive must say:
"Hey CPM Provisioning Service, for the domain user bobama, add a credential for SAP having the user name=baracko and password=prez"
First, notice that provisioning from the CPM perspective is simply providing the user with his CPM secondary credentials. There is NO creation of the accounts accessed with those credentials. Those accounts must be created by an outside means completely separate from CPM. Essentially, CPM provisioning is the act of populating the user's credential store - i.e., the administrator is populating a small data store and not actually provisioning accounts or resources.

Q:  I sort of see what you mean. The CPM provisioning command added the SAP credential for the specified domain user, it didn't actually create the SAP account. How does CPM know what "SAP" refers to in the command?
A: Good, you've noticed the second subtlety. Ultimately, the goal is to have CPM submit this credential when it detects to the SAP logon page. To achieve this, the credential needs to be associated with a specific application definition.

A unique GUID is assigned to every application definition when it is created in the CPM Administrative Console. This GUID is included in the command to provide the link between the credential and the application that the credential is for. So, the message actually needs to be:
"Hey CPM Provisioning Service, for the domain user bobama, add a credential for GUID-of-SAP-application-definition having the user name=baracko and password=prez"
The connector needs to provide the mapping between the application definition GUIDs and the credentials.

Q: How does the custom connector learn the application definition GUIDs?
A:  To determine the list of applications definitions available to a user, the connector needs to send a lookupApplicationRequest. The response to this will contain a list of the applications defined in the User Configuration associated with that user. The description of each application definition will contain the GUID and the fields in the a credential (e.g. user id, password and database name). Note that the lookupApplicationRequest command is a CPM specific, custom extension to SPML v2.0.
 
Q: Are you saying a custom connector is needed because it has to provide the binding between the CPM application definitions and the specific credentials?
A: Exactly!
The connector needs to know:

-  the mapping between the application definition GUIDs and the credentials.

- how to use the lookupApplicationRequest custom command to obtain the application definition GUIDs

- how to construct the CPM specific SPML extensions to use in the data elements of the commands.