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.

I conferred with some of the security experts at Citrix on the topic of people and security.  Their advice came in several key areas:  

Physical access to IT assets: Gaining physical access to machines greatly increases the damage and theft of data a malicious user can do.   For this reason, admins should restrict physical access to sensitive resources - for example, restricting access to the XenApp farm to Citrix administrators with authorized access cards. 

Citrix products offer a great advantage in making it unnecessary to have applications and data locally stored, so physical access is less of an issue.  Some of our most security sensitive customers publish the application that can manipulate sensitive data but disable client drive mapping and the clipboard virtual channel and print screen functionality so that no data can leave the data center. 

Unattended and unlocked user workstations are also a liability and a policy that requires users to lock workstations when they leave the work area is strongly suggested.  System configuration to lock workstations after a few minutes of inactivity and password-protected screen savers are also good measures. 

Separation of Duties: Security policy should be such that no one person or role holds all control.  This means assigning roles in a manner in which it takes more than one person to accomplish certain tasks.  For example, if the task is releasing a binary to a customer, a software developer should not QA their own code.  Similarly, an administrator's activities should be monitored by a separate auditing role. 

Citrix brings value here as well, with a separate role for Citrix Administrators who share control of the overall system with Local and Network Administrators.  The Citrix Administrators manage only the Citrix environment, so there is additional separation of duties.

  Least Privilege:  The old "need to know" basis!  Well in this case, "need to have permission to do."  People's roles in an organization and access rights should be broken down to grant users only the privileges that they need for their particular jobs.  This applies to admins as well - for example, the database admin should not have management rights on the mail server or security console or the network. 

Citrix allows you to publish applications using different roles to further restrict access to certain data and privileges.   
The whole point of least privilege is that if an attacker is able to compromise an account, they can only do a small subset of tasks on the network/database/machine. 

Password Policies:

There are several ways people can weaken corporate security with their management of passwords.  The problem with passwords is users would like them to be easy to remember.  As a result, they may attempt to simplify things by using the following bad practices:

-         Write down their passwords

-         Set all of their application passwords to the same thing

-         Use really easy-to-guess passwords, like their dog's name

-         Use the same password every other time they change it (just alternating)

-         Using trivial and short passwords, like 123

-         Never changing their passwords 

These user antics are not good for corporate security!  Security Policy should specify:

-         Password length

-         Password complexity (require special characters, mix of letters and numbers, etc.)

-         Password history enforcement (force a new password and don't allow repeats for a certain number of passwords.)

-         Disallowing the use of dictionary words in the password

-         Prohibit the use of obvious words, like Citrix, in a password

-         Password expiry, forcing password changes 

Enforcement of this policy is a different matter.  Citrix Password Manager can help administrators enforce these policies in a corporate setting.  Plus, with CPM you can configure such that users do not even know their own passwords, very effectively preventing sharing.  As a side benefit, if the user leaves, de-provisioning and assuring the user can no longer access any assets is much easier, since the user didn't know their passwords in the first place. 

Robert O'Keefe has created a demo of how to use the Citrix Password Manager Localization SDK, which can be used to localize the CPM plugin to languages beyond those natively supported.

video:src=http://www.youtube.com/watch?v=sYxBOsIGzc8

I spent some time recently chatting with Ross Duncan, VP of Channels at Gemalto, due to my role as product manager for Citrix Password Manager.While Citrix remains "strong authentication agnostic", Ross raised some great points: - Passwords are bad - I don't think anyone will argue this point!  There have been many solutions to enforce management of passwords to mitigate the inherent weakness.  Then those "solutions" that make passwords more complex can cause user convenience problems - plus bad behavior such as passwords written down, using the same password for many applications, and so on.  Then the help desk calls are both extensive and expensive.  - eSSO means putting all the keys to the kingdom in one place.  This allows IT to use hyper-secure passwords (20+ characters, special characters, etc.) that change rapidly.  However, the end user now has only ONE password to know - therefore there is a case to augment it with a strong authentication device like Gemalto smart cards. - Coupling of eSSO and smart cards brings the ultimate in convenience with maximum security - the user inserts their card, enters their PIN, and they can securely access the system.  This is much easier then entering user name/password - easier and more secure. - Vendors like Gemalto are integrated with Citrix Password Manager, smooth roaming/Hot Desktop, XenApp and CAG, which is convenient for customers.
We also discussed the merits of converging logical and physical security.  This always looks great on powerpoints, but it has been a real slow starter in real life.  It's been discussed for 8 years that I personally know about, but the actual implementations are lagging.  It always struck me this way: the physical security personnel and the IT security personnel are usually in different areas within and organization, and there are numerous political barriers to having the two groups work together and contribute budgets to make a badge/technology/management decision together.  I know Gemalto has partnerships to do this, but it seems to me to face obstacles.  Would like to hear comments!
 

Several striking aspects:

• All presentations about security in a virtualized environment were mobbed.  People were pretty angry when turned away at the doors of the presentation rooms, but fire marshall regulations prevented people from standing at the back.  It appears this is the "next interesting thing" in security, and there is great curiosity.  On the reality side, there were very few products / technology for sale to address the potential issues.  I believe there are a great many startup companies currently in stealth mode in this area.
  
• The days of radical and revolutionary change in security from the late '90's and early '00's are way over.   The big vendors seem to be just pulling together "fix it all" suites as best they can through acquisitions.
  
• Michael Chertoff's presentation was a tad scary: he mentioned that government agency computers are all interconnected, and that security is not consistent across all agencies (some have 24/7 monitoring for security and some don't).  This is bad for the obvious reason - just like in the movies, the bad guys can find an innocuous-looking, under-protected entrance and get to the agencies of interest.  The other scary part was that Mr. Chertoff seemed to think 24/7 monitoring was the main thing.  I'd tend to focus on preventative measures, vulnerability assessment, intrusion detection, user training, Identity and Access Management, strong authentication and other areas as well, but they were not mentioned.
  
• Bruce Shneier's presentation on security rationalization was provocative.  He focused on the separation between reality, feelings and models by "experts" when it comes to assessing security risks.  One example was the Tylenol scare, and it was successfully addressed from a commercial standpoint by adding hermetic seals to bottles.  It made people feel better.  The reality is that a syringe could inject poison pretty easily, but people feel better.  He also introduced the notion of "security theatrics", where the media and security vendors exaggerate risks and cause people to feel bad when the reality just doesn't match.  Interesting concept.

RSA Conference is growing: attendance was estimated at 17,000

This is a little-known fact that may be very interesting for customers who want SSO, but realize Password Manager does not natively support your language.  We have an SDK available for partners to do their own translations of the CPM UI.  It is available for free, and has already been requested by partners in Russia, Czech Republic, Sweden, Italy, Greece and Poland.

This SDK can be used with standalone CPM and XenApp Platinum (Single Sign-on powered by Password Manager.)  Both offerings are the same code base.

Our terms are intentionally simple: the local Citrix rep approves the partner to me, partner signs a EULA, I give the partner access to the SDK via FTP, and the partner owns the resultant work effort (of course CPM licenses are still required for the customers purchasing translated versions from the partner.)

The caveats are that the business partner is responsible for keeping up with changes as new releases are provided from Citrix, and the local Citrix account team vouches for the integrity of the partner.  We need to be sure the UI delivered is of quality, hence the local team involvement.

If you're interested, please have your Citrix rep contact kate.brew@citrix.com

 Would also appreciate comments on this approach - yea or nay!

Most people don't realize the value of the answers to their personal security questions (Citrix Password Manager calls this Question Based Authentication.)  As it turns out, those answers are more valuable than passwords.  If someone learns enough answers to your personal security questions, they very often can reset your password and have access to your accounts.  Yes, that includes your online bank account and it's a very real problem.  In fact, I have a friend so paranoid about this that he swears his favorite color is "three."

 Some of the issues around personal security questions are kind of interesting.  For example, I've dealt with customers where personal privacy of employees is a big consideration in selecting the questions.  Let's call that one "sensitivity".  Another issue is what I'll call "changeability" - your favorite movie may change from month to month.  Then another issue is what I'll call "detectability" - my place of birth is public record, if somebody happens to know where I was born and what my maiden name was.  Both of those are completely unguessable in my case so I am probably safe on that problem. 

 Then there is always my favorite, "guessability" - there are only so many colors, even if you count teal and puce.

We can't forget the punctuation marks either.  Tricky to remember whether I indicated a teacher's name as Mrs. Winters, Ms. Winters, Mrs Winters or Ms Winters when I signed up for a web account.  Have to be careful on that one.

 We are finding that the more flexibility you can allow the better on these personal security questions for CPM.  Let companies write their own personal security questions that are more obscure than place of birth.  Let people choose between a number of security questions that they find unique and easy to remember.

In fact, I'd love some comments on pet peeves and helpfuls suggestions on personal security questions!