www.openxpki.org/trunk/src/htdocs/news/story-20070126.html

   1 <%attr>
   2   title => 'Success story'
   3 </%attr>
   4
   5 <h2>Success story: SmartCard personalization self-service application</h2>
   6 <p>
   7 The first production deployment of OpenXPKI was performed on Friday,
   8 2007-01-26 by <a href="http://www.cynops.de/">Cynops GmbH</a> for
   9 a customer.
  10 </p>
  11 <p>
  12 In the current implementation phase OpenXPKI is solely used for
  13 one single purpose - it implements a self-service application for
  14 SmartCard personalization.
  15 </p>
  16
  17 <h4>System environment</h4>
  18 <p>
  19 SuSE Linux SLES 8, Oracle 9, nCipher nC1002W/nC3022W/nC4032W HSM,
  20 Apache 1.3, RSA Access Manager, RSA SID-800 tokens
  21 </p>
  22
  23 <h4>Authentication</h4>
  24 <p>
  25 For user authentication a RSA token based Web
  26 Single-Sign-On solution implemented with RSA ClearTrust (now called RSA
  27 Access Manager) is used. The web server configuration looks very much like a
  28 basic authentication in front of the web application, and it also
  29 sets some environment variables that the application can evaluate to
  30 obtain login user information.
  31 </p>
  32
  33 <h4>Authorization</h4>
  34 <p>
  35 The OpenXPKI authorization configuration for users is using an
  36 "External Static" that only calls /bin/true and sets the role "User".
  37 (The actual authentication is performed by the authentication module
  38 configured in the web server config.)
  39 </p>
  40
  41 <p>
  42 RA and CA operator authentication also works via the SSO mechanism.
  43 However, the logged in user can pick "RA Operator" or "CA Operator"
  44 instead of "User". The configuration is again "External Static" but
  45 in this case it calls a shell script which checks the authenticated
  46 user name against LDAP groups that list acceptable RA/CA operators.
  47 If authorized, the user gets the corresponding role for the rest of
  48 the session.
  49 </p>
  50
  51 <h4>SmartCard personalization</h4>
  52 <p>
  53 The application uses the SmardCard Personalization workflow
  54 as shipped in rev 709.
  55 A User can either login normally to the application and pick
  56 "Personalize SmartCard" from the top level menu. However, using
  57 mod_rewrite a rewrite rule for https://servername/token was
  58 configured to a deep link into the application. It directly starts the
  59 personalization workflow and hides the user menu.
  60 </p>
  61 <p>
  62 The workflow queries user data from an LDAP directory and stores the
  63 required fields in the workflow instance context.
  64 The user is then prompted to insert a SmartCard token. If the correct
  65 Crypto Service Provider is installed (and the user is using MS
  66 IE...), a key pair is generated on the token. The browser sends the
  67 CSR to OpenXPKI which inserts the CSR into the workflow.
  68 </p>
  69 <p>
  70 The HSM-protected CA key is usually always online, so certificate
  71 issuance can happen right away. The personalization workflow forks a
  72 certificate issuance workflow and waits for its completion. Once the
  73 certificate is issued the workflow continues and instructs IE to
  74 install the certificate on the user's token.
  75 </p>
  76 <p>
  77 In this installations two certificates per user are created, and both are
  78 requested and installed in the same session. Due to the low speed of
  79 the used SmartCard tokens the full personalization process takes
  80 about 4 minutes.
  81 </p>
  82