Admin Gets 403 when GETing secret payload for certain ACLs

There is another access related issue associated with creator user access to private secret or container case (project-access is False) .

Right now, creator user can access private secret or container without need of having scoped token in same project as secret or container is created. With current behavior, creator user *always* have access even when admin user of that project has removed creator user roles for that project. This may not be correct desired behavior in cases when roles are removed to block access to creator user to a pool of shared private secret/containers

Hello Arun, I think you are talking about the fifth 'read-only' role that Adam Harwell suggested and that we've talked a little about since then. It seems we need to add this fifth role for sure, but must first bike shed on the name of it :) I'll add this to the next Barbican IRC meeting agenda....

I noticed that we had previously discussed the 'read-only' role...here's a link to the etherpad here: https://etherpad.openstack.org/p/barbican-acl-read-only-user-discussion

John: This issue mentioned above is slightly different as its related to user who has created the secret/container and not to ACL user. If I recall correctly, the additional role requirement is for ACL user. Generally "creator user" will have secret's project role as that user has initially created the secret in that project. So same role requirement is extended for allowing secret read in private secret case (project-access = False). Have made change in policy to have this requirement for creator user.

We can certainly extend "read-role" approach to creator user but then each creator user will need this role in addition to project role user already has. The difference is that creator user will need to scope to the project where this additional role is assigned to.

So option is either to treat "creator user" as default ACL user or can be treated as role based specific user in private case (partially similar to admin user). Once "new role" is identified, we can make needed change in policy for ACL users (and creator user if that's preferred option).

[John: This issue mentioned above is slightly different as its related to
user who has created the secret/container and not to ACL user. If I
recall correctly, the additional role requirement is for ACL user.]

I agree, but the comments on that bug seemed to stray into the ACL side of things.

[Generally "creator user" will have secret's project role as that user
has initially created the secret in that project. So same role
requirement is extended for allowing secret read in private secret case
(project-access = False). Have made change in policy to have this
requirement for creator user.]

I’m not sure I’m following this. I don’t think the role used to create/store the secret should have a bearing on what role is needed to retrieve it later?

[We can certainly extend "read-role" approach to creator user but then
each creator user will need this role in addition to project role user
already has. The difference is that creator user will need to scope to
the project where this additional role is assigned to.]

I don’t think the project matters…but yes, the user for whatever project they have the token for has to have the read-only (or ‘acl-user’) role if they are on he ACL for the secret. Deployers could choose to relax this if they wished to. I think this is something we could discuss on Monday though?

[So option is either to treat "creator user" as default ACL user or can
be treated as role based specific user in private case (partially
similar to admin user). Once "new role" is identified, we can make
needed change in policy for ACL users (and creator user if that's
preferred option).]

Yes I think that is a basic decision for folks to make.