Table of Contents

  1. Deploying and Configuring the Bandit IdP
    1. Introduction
    2. Deploying As a Tomcat Servlet On Linux
      1. Apache Connector
      2. Java Version Notes
      3. Enabling Strong Encryption
      4. Miscellaneous Issues
    3. Configuring The IdP
      1. Define Configuration Files and Admin Password
      2. Define User Attributes
      3. Define Card Templates
      4. Define Java Keystore
      5. Define IdAS Contexts
        1. XML File Context File Format
      6. Verify/Finish Installation
      7. Restart IdP
    4. Notes From Users Who Have Installed the Bandit IdP
  2. Miscellaneous Setup Tasks for Bandit IdP
    1. Introduction
    2. Backend Repository Configuration
      1. LDAP Repositories
        1. OpenLDAP
    3. Creating and Using Your Own CA and Certificates
      1. Using tinyca on Linux
      2. Installing Certificates For Apache SSL
      3. Installing CA Certificate For Windows CardSpace Selector
      4. Installing CA Certificate For ISS Selector

Miscellaneous Setup Tasks for Bandit IdP

Introduction

We have assumed that prior to deploying the IdP, you have installed a system that can properly host the IdP. However, we also recognize that this process can be difficult and error prone itself. There are many things that must be properly setup. We have attempted to document some of those that may be less obvious than typical ones. We have also tried to document any information that may prove useful to you as you setup such a system.

Backend Repository Configuration

This section contains information about setting up your backend repository that doesn't really have anything to do with configuring the IdP perse.

LDAP Repositories

OpenLDAP

  • For managed cards which are backed by a personal card, the JNDI context provider expects there to be a "cardKeyHash" attribute which is multi-valued. A hash of the personal card's PPID+PublicKey should be stored here. This will require you to extend the LDAP schema. Create a file called "cardspace.schema" and put the following lines into that file:
attributetype ( 2.16.840.1.113719.1.1.4.1.666.667 NAME 'cardKeyHash' DESC 'sha1(base64(PPID + Public Key Modulus + Public Key Exponent))' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)

objectclass ( 2.16.840.1.113719.1.1.4.1.666.667 NAME 'cardSpacePerson' DESC 'Auxiliary class for !CardSpace related attributes' AUXILIARY MAY cardKeyHash)
  • Place the file in the openldap "schema" directory - the schema directory is likely to be placed at /usr/local/etc/openldap/schema.
  • Edit the slapd.conf file and add a line which contains the full path to the new schema file:

include /usr/local/etc/openldap/schema/cardspace.schema

Creating and Using Your Own CA and Certificates

To host an IdP, you will need X509 certificates issued by a recognized certificate authority (such as VeriSign, Equifax, etc.). Of course, this takes time and costs money. An alternative is to use readily available tools to create your own certificates. The downside to this approach is that you have to be your own CA (Certificate Authority). This is problematic for browsers, as they generally have a list of certificate authorities they recognize. However, they all have mechanisms for importing new certificate authorities, so for testing purposes and pilot systems, this is a cheaper and convenient alternative that can prove useful. Ultimately, for a system you deploy live, you will want certificates issued by "real" certificate authorities.

The following sections detail one convenient way to create and use your own CA Certificates. There are many ways this can be done. Gene Gotimer from Privo (www.privo.com), is a user who has deployed the Bandit IdP using his own CA and self-issued certificates. He has provided a very helpful set of step by step instructions explaining how he did it. See here for details.

Using tinyca on Linux

On many Linux systems there is a handy utility called tinyca (Tiny Certificate Authority). It is really a GUI front end for the openssl tool. If you don't have it, you find out more about it here. The link includes downloads. You can use the openssl tool directly, but it is much more difficult.

Using tinyca (invoke by calling tinyca2), you will want to do the following (how to do these things should be obvious from the UI):

  1. Create a New CA. There is typically a button called New CA for doing this. You can have multiple CAs managed by tinyca. The name you give your CA can be anything you want - this determines where on your local system the certificates, keys, etc. get stored. The Common Name field is generally supposed to be the name of your CA server (e.g., ca.myserver.com). It doesn't have to be a real server name.
  2. Export the CA. You need to export the CA (there is a button called Export CA) to a file on your local system so that you can later on import it as a trusted root for your browsers and card selectors. Choose the PEM format.
  3. Create a Server Certificate. Click the Certificates tab to see options for creating certificates. There will be a New button at the top of the screen. You will be prompted whether to create a server or client certificate. Choose server. You will then be prompted to fill in information for your certificate. The Common Name should be the name of the server where you will use the certificate (e.g. idp.myserver.com).
  4. Export the Server Certificate. Click the Export button. You will actually want to export this certificate twice, once in PEM format, and once in PKCS#12 format. When you export it in PEM format, there is no need to include the private key or fingerprint. When you export to PKCS#12 format, it automatically exports both the certificate and the private key, which is exactly what you want. The PKCS#12 file will be imported later into a Java keystore (JKS). When you export to PKCS#12, there will be a radio button asking you if you also want to export the CA certificate to the PKCS#12 file. Click No.
  5. Export the Certificate Private Key. Click the Keys tab. You should see your privete key listed. Select it and click the Export button. Select PEM format, and on the radiio button that says "Without Passphrase" click Yes. The reason we are exporting the private key is so we can use it for Apache SSL. We choose without a passphrase so that Apache can use the key without having to prompt the user for the password every time.

Installing Certificates For Apache SSL

Apache uses two files: an SSL certificate (in PEM format), and a private key (also in PEM format). Whether you got these from a regular certificate authority (like VeriSign, Equifax, etc.), or created them yourself in some way (see [[Miscellaneous IdP Tasks#Creating_and_Using_Your_Own_CA_and_Certificates|above]]), all you need to do is copy the files to the appropriate directories for apache to use them. Usually, these are as follows:

  • /etc/apache2/ssl.crt/server.crt. This is the PEM file that contains the SSL certificate. Copy your certificate PEM file over this.
  • /etc/apache2/ssl.key/server.key. This is the PEM file that contains the SSL certificate private key. Copy your private key PEM file over this.

The easiest way to set up a virtual host is to edit up a local.conf file that is included from httpd.conf (both located in /etc/apache2). Here is an example of a local.conf file:

NameVirtualHost *:80
NameVirtualHost *:443

<VirtualHost *:80>
ServerAdmin admin@mycorp.com
DocumentRoot /srv/www/htdocs
ServerName mycorp
</VirtualHost>

<VirtualHost *:443>
ServerAdmin admin@mycorp.com
DocumentRoot /srv/www/htdocs
ServerName mycorp
SSLEngine on
SSLCertificateFile /etc/apache2/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/server.key
</VirtualHost>

<VirtualHost *:80>
ServerAdmin admin@mycorp.com
DocumentRoot /srv/www/htdocs
ServerName mycorp
RedirectMatch permanent (/.*) https://www.mycorp.com$1
</VirtualHost>

Installing CA Certificate For Windows CardSpace Selector

If you are using a CA that you created (see [[Miscellaneous_IdP_Tasks#Using_tinyca_on_Linux|Using tinyca on Linux]] above), info cards you generate that use certificates generated from that CA cannnot be imported into CardSpace unless your Windows system recognizes your CA as a trusted root. To make your CA a trusted root, take the CA certificate (NOT the other certificate you generated), and import it as a trusted root via Internet Explorer. Depending on your version of IE, mechanisms for doing this are usually found under the Internet Options. Be sure to import it as a Trusted Root Authority, NOT as a regular certificate.

Installing CA Certificate For ISS Selector

If you are using a CA that you created (see [[Miscellaneous_IdP_Tasks#Using_tinyca_on_Linux|Using tinyca on Linux]] above), info cards you generate that use certificates generated from that CA cannnot be imported into the ISS card store unless ISS can verify the certificate chain all the way back to the Certificate Authority (it makes calls into openssl to do this). ISS will tell opensll to look for root and intermediate certificates in a certificate chain in the /usr/lib/iss/certs directory. To install your CA certificate, simply copy the CA PEM file you exported above into this directory and then run the following command:

c_rehash /usr/lib/iss/certs

You will then need to restart the ISS daemon (issd) in order for it to recognize this new trusted root. NOTE: If you created a certificate chain that has more than a root CA certificate, all of the intermediate certificates should also be installed in this directory. There is no need to install leaf certificates in this directory.