Up till now, authorization in the KRA has been very coarse. In the default install, there was only one set of agents which could either store or retrieve keys. Now it was (and still is) possible to create additional groups and modify acls for particular operations, but the ACLs still governed all keys. It was not possible to specify that some keys would be governed by some agents, and others by different agents. Moreover, all requests were visible by all agents.

With the advent of the use of the KRA to store secrets for different applications (for instance, barbican and IPA), the need to segregate keys(secrets) and requests on those secrets became important. Moreover, even without other applications, there was a need to be able to segregate keys amongst different sub-organizations.

A new database attribute ("realm") has been added to the KeyRecord and RequestRecord. This of course means that a database migration is required for existing instances. The "realm" is a tag that maps to a particular authorization instance as configured in the CS.cfg.

When a secret is archived or generated through the REST interface, the user has the option of providing a value for the authorization realm. We’ll see an example of this below. This value is stored in the secret’s key record. When the secret is retrieved, the server will notice that the key entry has a realm, and will invoke the authorization plugin defined for that realm in CS.cfg. That authorization plugin will determine whether access is allowed.

Actually, the logic for realms is as follows:

• if no realm is defined, allow access.

• if no authz plugin is defined for that realm, then deny access. This is to ensure that requests do not inadvertently get relegated to the default realm through typos.

• If the authz plugin defined for the realm allows access, allow access.

• Otherwise deny access.

Realm authorization has been added to all important operations, including:

• archiving or generating keys

• recovering keys

• listing keys and key requests

• acting on key requests (approving, rejecting etc.)

The authorization call for each operation will include the resource, realm and operation. It will be up to the authz plugin to determine access appropriately.

A new basic group base authz plugin has been added that simply provide access based on group membership. In addition, the ACL plugins have been modified to combine the realm and resource to check for a realm-specific resource of the format "realm.resource". Examples of both plugins will be shown below.

Remember that the realm authorization is in addition (and after) any other authz mechanisms in place. By default, for instance, the KRA requires authentication with a client certificate and that the requester be a KRA agent.

Lets make all this more explicit. In this example, we will store and retrieve secrets using a tag "barbican".

For the authz instance, we will use the newly added BasicGroupACL authz instance, which simply determines access depending on whether a user is a member of a group found in the KRA database. This plugin was provided for testing and simple purposes (and may in fact be used in the first pass) for the Barbican application, but we expect that other applications might use a more complicated authz plugin - something for instance that subclasses the BasicAclAuthz plugin.

We will add the following lines to the KRA CS.cfg (and restart the server):

This configures the BasicGroupAuthz instance to be invoked when a key has the "barbican" realm. Access will be granted if the requester is part of the "barbican" group in the KRA’s internal DB.

We will now create two users:

• agent1 - agent1 is not a member of the barbican group. He will not be able to archive, read, list or recover barbican tagged keys or requests.

• agent2 - agent2 will be a member of the barbican group and therefore will be able to perform all operations on barbican tagged secrets and requests,

Note that both agents will be members of the KRA Agents group. Otherwise, they would not be able to access anything on the KRA at all. Moreover, as members of the KRA Agents group, they have access to all requests and keys that are not explicitly tagged with a realm. We will call this the default/non-realm case.

Below are commands used to create all the relevant users, provide them with certificates, and associate them with the relevant groups.

We can now use agent2 to archive and generate secrets tagged both with and without a barbican realm.

Based on the setup above, we expect the following behavior:

It is also possible to archive secrets (specifically private encryption keys) through the CA-KRA connector by executing a profile in which archival is enabled. An example of this is the caDualCert profile, where the encryption key is archived to the KRA.

If the CA administrator wishes to enforce that the key should be stored within a particular realm, he can add a new default and constraint to the relevant profile. Enrollments using that profile will then have the realm injected into the request and passed to the KRA for archival.

Moreover, when enrollments are submitted, an authz check will be performed to confirm that the user is permitted to submit requests to that realm. The authz setup is identical to the KRA authz setup.

The instructions below show how to set up a CA profile to use the 'barbican' realm.

• Add the realm default and constraint to the desired profile.

• Set up a barbican authz plugin in CS.cfg:

• Add an acl to allow users to submit to the barbican realm:

• Submit a request to the relevant profile. In the case of this example, we will be using a modified caDualCert profile.