Migrating from Borland Security Service 5.1

This document describes the steps involved in migrating from Borland Security Service 5.1 manually. Users can also opt to use the configMigrator executable to assist in the migration exercises. The configMigrator will assist in the JAAS config file and property file migration.

There are a very few source code incompatibilities; these will not affect BES users. However, applications that use the BSS API at the CORBA level may be affected. See the source code incompatibility section for details.

This document contains the following sections. Each section details the steps involved in migrating a particular component.

JAAS config file changes

  1. Edit your JAAS config file. If it contains a "Client" entry, remove it.
  2. If a "System" configuration entry does not exist, go to the next step.
  3. For each entry in the "System" entry, record the realm name as follows:
    If the LoginModule is... then note down...
    com.borland.security.provider.authn.ClientSideDataCollection GSSUP#realm
    com.borland.security.provider.authn.CertLoginModule Certificate#ALL
    not one of the above and the "realm" name has a corresponding realm entry in the JAAS config file the realm name as is.
  4. Remove the "System" entry from the JAAS config file and save the file. Keep the list of realms around.
  5. You may now end up with an empty JAAS file, in which case, remove it and remove the property vbroker.security.authentication.config from your property file.

Property file changes

  1. Check the property vbroker.security.login. Follow instructions corresponding to its value.
  2. Check the property vbroker.security.assertions.trust.<*>. For each entry, replace the principal name with a role in an authorization domain defined. If an appropriate role does not exist, then add a role to an authorization domain (update the corresponding role map file).
  3. For each authorization domain defined, see if there are one or more properties defined called vbroker.security.domain.<domain_name>.runas.<rolename>. For each such entry, replace the value (should be a user@realm value), with an alias. Note the value and the corresponding alias that you have provided. The alias can be any string that helps you identify this identity. If the value of the property is use-caller-identity, then ignore it. There is no change needed for the property.

Vault regeneration

Check the vbroker.security.login property. If that points to a vault file, then you must regenerate your vault.

  1. Remove the existing vault.
  2. Run vaultgen from the directory where you will run your process. This is needed to ensure that all relative paths in the config files and the vault are accurate for the runtime. Run vaultgen as follows: 
    vaultgen -config [path to config] -vault [path to vault]
  3. For each realm in the realm list from the first step, call: 
    > login [realmname]
  4. For each alias that is configured for runas, call: 
    > runas [alias] [realm]

    where realm is the realm part of user@realm that was the original value of the realm.

  5. Provide the username as the username and a password to authenticate that user.

AppServer migration

For the AppServer, the server runs from the directory:

<install_root>/var/servers/<servername>

and the partition from the directory:

<install_root>/var/servers/<servername>/partitions/<partitionname>

So, you should run vaultgen for these processes from the appropriate directory.

The files to consider for the Server for migration are:

The files to consider for the Partition are:

Note: By default, the management ORBs in the server and the Partition use the same management_vault, so the vault needs to be migrated only once.

Source code incompatibility

The following is the only source code incompatibility in the new Security Service.