By user12582982 on Nov 16, 2009
One of our partners is offering Managed Smartcard Services. This means that an enterprise is able to outsource all of their smartcard and PKI services to a 3rd party. Part of their card lifecycle management service is the whole enrollment, personalization and issuance of the smartcards. This means that a new employee will get an invitation to visit one of a chain of certified professional photographers in his or her hometown neighborhood to take a picture to go on the card. The smartcard is then printed with the company's and personal information including the employee's photo and is provisioned with the user's certificates. The certificate will contain the user's UPN that will also need to get into the company's Active Directory so that the employees can use smartcard login to their desktop. For this to happen, many scenario's can be thought off including a fully automated provisioning of AD by tools like Sun Identity Manager up until manually adding new users from a batch csv file. After this is all done the card is then sent to the employee's home address together with a PIN letter, ready to activate and use.
Recently I have been investigating how this Managed Smartcard Service could be used to easily give employees access to their Windows desktops via strong authentication using our partner's Managed Smartcard Service. The basis for this setup is a customer using Citrix XenApp (formerly known as Presentation Server) to access its desktops using Sun Ray thin clients.
The entire demo environment has three servers, two clients and a live Internet connection. Clients are a fat laptop client and a Sun Ray thin client. The servers are a Sun Ray server (with PCSC lite software), a Citrix XenApp server with AET middleware software (used by our partner) installed on it, and a AD Domain Controller that is setup to trust certificates issued by our Managed Smartcard Service Provider's CA. This environment is connected to the Internet so the validity of certificates can be checked via OCSP at the Managed Smartcard Service OCSP responders. As can be seen in the short demonstration video (02:27) below both fat and thin clients can be used interchangeably without any problem.
Since the issued smartcards are sent directly from the 3rd party (our
partner) to the company's employees, we needed to find a way to
register the cards in the company's Sun Ray (or VDI) environment. The Sun Ray token ID is
composed from several characteristics of the card being fabricator,
type, batch and serial number of the card. Within the Sun Ray server
software, this token ID is composed automatically by the corresponding
smartcard config file. Composing this token ID beforehand through a
script is theoretically possible but is easily broken
since e.g. type and batch numbers could change without notice. Another idea would be to register the smartcard when it is used for the first time by the customer's employee.
However, even more simple is to make the Sun Ray services layer completely 'transparent' to all the backend services (like with VDI). This is what is used in this setup where just the certificates are read and transferred to the backend Citrix XenApp servers which have the AET middleware on it and where all the OCSP checking and final authentication based on the UPN in the certificate will take place.
All in all, we found that Managed Smartcard services can be used very easy together with Sun VDI and Citrix where both fat and thin clients can be used together...
Have fun, Rene.