This is the KRA ACL proposal ready for initial review.

The path should be /kra/rest/keyrequests/{id}?action=approve

The path should be /kra/rest/keyrequests/retrieve.

a password

/kra/rest/keys/{id}

This sentence needs to be clarified.

To avoid confusion "project" should be called "tag".

This is a bit confusing. Probably it should be clarified that "escrow agent" is not a KRA agent. Alternatively we can call it "escrow officer".

/keys/{key_id}/retrieve

Does this mean we will no longer use pkidbuser, at least for KRA?

Does the KRA admin have full access to the ACI in all projects? Or should there be project-specific admins that can manage project-specific ACI? Or should this task be delegated to project-specific admins?

If we're going to support project-specific admin/agent, this interface is too generic, it allows the project-specific admin/agent to create an ACI for any project.

Do these values have DN schema? We may need to set up referint for them (especially tag objects).

404 seems more appropriate.

Is there an immediate use case for modifying the CLI to support GSS-API, given that Barbican and IPA are the drivers?

typo: documeNtation

ftweedal :)

Could you elaborate as to what is the alternative to the simplifying assumption? What are we simplifying from.

Just curious as to what the agents would write to these records that are say owned by a regular user?

I am assuming that the user U0 is some kind of special user that is tasked with referencing the proper tag and come up with a list of users allowed to see his secret?

If this were just a dead simple user that wants to archive his secret, will he have to set all these fields? Apologies if I missed that part.

The "tag" terminology is a little bit too generic/confusing. It might be better to use "project" like originally proposed. However, instead of defining just the permission, a "project" should define a set users, roles, and the resources (i.e. secrets).

The permission to the secrets can be determined by static ACIs and attributes defined in the secret itself.

There should be a REST interface to manage "projects" too. Basically a "project" can be considered as "light-weight KRA".

If we use static ACI at top-level entries, the ACI can be added automatically when KRA is installed or when a project is created. A project can optionally have a default escrow officer.

In IPA a vault can be owned by multiple owners, so the secret must be owned by multiple owners too.

We can also add an "escrowOfficers" attribute to store non-default escrow officers (e.g. department-specific officers).

The IPA tag/project should be created automatically when KRA is installed in IPA. The IPA admin later can add a global escrow officer for all IPA secrets. Alternatively, the IPA admin can add an escrow officer to a specific group to manage secrets belonging to the group.

Defining a new ACL is too low-level and error-prone. Permissions can be defined using static/global ACLs and other attributes as described in lines #134 & #182.

Since tag is global in KRA, the user might pick a wrong tag and accidentally exposes the secret to people in a different project:

$ ipa vault-add test --tag sales_secrets (whose sales dept?)

IPA should create all vaults with "ipa" project automatically. This should automatically grant IPA default escrow officer access to all IPA secrets.

To create group-specific escrow officer, IPA might need to provide new commands, for example:

$ ipa vault-group-add sales --escrow-officer-group "cn=Escrow Officers"

$ ipa vault-add test --group sales

The vault group only exists in IPA so it's not possible to incorrectly pick a group from another project.

We can also add a "groups" attribute to store the groups this vault belongs to as described in line #193. The "groups" attribute will automatically grant group-specific escrow officers access to this secret.

Similar to line #182, Barbican should create all vaults with "barbican" project.

Constructing a correct database-level ACI is not trivial, so ideally ACIs should be static and few so it can be reviewed easily. Allowing dynamic ACI, even if it's limited to KRA admins, is risky.

If this were application-level ACI, it is fine if we want to provide a REST interface for it.

Yes. The usual method of accessing the database only through
a single dbuser would not be used in these cases. Eventually, it will likely go away.

The simplifying assumption is perhaps a clarification of my understanding. One basic change here is that we are getting
user and group information from an external authentication
source -- in this case, most likely - the IPA database.

I was imagining a situation where multiple authentication sources were present -- what happens if uid=admin is defined in both the KRA and IPA databases? In this case, there is no problem because the users map to different DNs.

The important point is that identities provided to us by GSSAPI are unique.

What you describe is my initial understanding of how a project should be constituted. I'll add this to the alternatives section below.

nkinder mentioned though that it scales and performs better to have static tags that can be attached to secrets, rather than per-secret ACIs. So the idea is:

We have users defined by our identity provider (IPA) or internal db.
We have groups defined by our identity provider (IPA) or internal db.
We have ACIs that are defined at the top level which reference users/groups/tags.
Secrets are tagged.

In this model, ACIs represent the fundamental relationship of users, groups and secrets (as mediated through tags)

In the model you propose, projects represent the fundamental relationship between secrets, users and groups.

Need to clarify that GSSAPI will only be used between IPA and PKI, but not between PKI and DS, although IPA is already using GSSAPI to communicate to DS directly.

Can we call this "permission"? "Tag" is too generic and what it really does is granting permissions.

I actually think "Tag" is more appropriate between the two. If "Tag" means some other things that could confuse anyone, words like "Label", "World", "scope" etc. to differentiate the realm or scope of the relevance could be used.

If this is going to be a field that requires external management, then perhaps the "owner" field should be outside of the CS system. And perhaps change this field to be "creator" instead, a single value field that is populated when the record was first created.

I actually prefer this one instead of special casing in the other method.

It is probably fine to have metadata put in the key record at the time of creation, as long as no further management needed after the creation.

I don't think non-CS role users should go into the KRA database. The day-to-day management of non-CS users should be kept out of the core CS.

yes

I was hoping that tags are static. Again, I'm hoping to keep day-to-day management of these out of the CS authorities..
Could the tag be static, and you have another external acl to specify whether an app has to a specific tag or not?

yes. Overall, I believe that any application specific components, e.g. authentication and authorization are best to be implemented with plugin framework;
To maximize the flexibility of a product, its best to keep application-specific code/data outside of the core (non-plugin) areas. That's why I am making the suggestions that I have made as far for this design.

will do.

I think "tag" is more appropriate too. We could use "Label" if that is less confusing. We are labeling or tagging a secret to be of a specific type, so that we know how to apply permissions rules to it.

tag != permission
tag => (implies) set of permissions

What other use of "tag" are we trying to disambiguate against?

It does make things cleaner, although there are migration considerations here. We don't want to disable existing customer's access to their secrets if a migration script failed to run.

Most likely, what we'll end up doing is having a migration script that adds the special tag, and then, on completion, sets a config flag that disables the special casing.

Because the metadata is user-defined, I don't think we can enforce that it will not change. IPA, for example, will store the vault_secret_id here, and while that does not currently change, it seems unreasonable for us to require them to create a brand new secret and remove the old one in order to change it.

This is just defining a user-defined metadata field -- why does it have to be immutable?

Eventually, barbican users will be defined in an IPA database and the barbican-dogtag-plugin will use kerberos/GSSAPI to talk with Dogtag. There is a lot of work needed to get there though.

In the interim and because it is possible to deploy the KRA with Barbican outside of IPA -- the simplest possible scenario to promote adoption -- we need to add the user to the KRA DB.

Note that we now need to consider CS as just another (albeit important) application that is using the KRA. If we have CS users, why not barbican users?

Consider that several applications need to use the KRA to store secrets. Right now we have three -- CS, IPA Vault and Barbican.

Each application needs to contact the KRA administrator to:
a) register a plugin for authz
b) register tag(s) that map to that authz plugin

This must be done in co-ordination with the KRA administrator to ensure that the apps do not use the same tag.

This is just adding an interface that can be used by KRA admins to do this task, rather than having to go to the console (which we are trying to deprecate, remember?). It also allows apps to be added post-install possibly without server restart.

We don't expect this to be a daily occurrence. We do expect though, that this should be made easy for the admin to do.

Exactly. But tags are the way we associate authz plugins with specific keys. We need to manage those just as we need to manage which authz plugins are registered.

You could say that adding and mapping a tag is part of registering an authz plugin.

I'm ok with this suggestion. If IPA or another app wants to have multiple "owners", then they can -- and in fact do -- keep track of it. Endi?

The concern is if there's no well-defined usage people might use tags for things other than permission. When that happens it could interfere with how the permission works, and it would be harder to separate permission tags and non-permission tags later.

Since we won't be using GSSAPI between PKI and DS, there is actually no need to have an owner/creator field in the DS since all secrets will only be accessed by pkidbuser. If we plan to have users other than pkidbuser to access the secrets, then it would make sense to have owner(s)/creator field with an ACL that grants certain permission.

Also, since we won't be using GSSAPI between PKI and DS, there is no need to store tags in the DS either. The PKI server can utilize an authorization plugin to check with IPA if the user has access to certain secrets (which can be determined by IPA vault ownership/membership).