Java Security, 2nd Edition

Key Management in an Identity Scope

We’re now going to put together the identity scope with the information about the identity class to produce another key management system. One of the primary limitations of the default identity scope is that it’s based upon a single file. If you’re in a corporation, you may want to have an identity scope that encompasses the public keys of every employee in the corporation -- but you can’t afford to put the private keys of the employees in that database. Every employee needs read access to the database to obtain his or her own key; there’s no practical way with a single identity scope to prevent these users from reading each other’s private keys.

Hence, in this example, we’re going to develop an identity scope that provides for the architecture shown in Figure C-2.

There are two simple goals to this example:

• There should be a central database (identity scope) managed by the system administrators of the XYZ Corporation. This database will hold the public keys of all identities that are used in the system, along with a security level that is assigned to each identity.

• Each user should have a private database that holds the user’s private key. The user’s private key will be certified by the XYZ Corporation itself, so this private database will need to have the public key of the XYZ Corporation. We’ll make this scope the system scope so that it can encapsulate the knowledge that there are two scopes in use; to a program, it will appear as only a ...