RBAC needs to be checked for stored-key orders
Bug #1446266 reported by
Dave McCowan
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Barbican |
Fix Released
|
High
|
Arun Kant |
Bug Description
For the use case “Order a certificate based on a stored key”:
If a container is restricted by an ACL, then that should be enforced if a user tries to order a certificate based on that container.
It is not.
A fix should go it two places:
In TypeOrderValida
In the worker, a second check should be made, in case the ACL has changed sinced validated.
Changed in barbican: | |
assignee: | nobody → Arun Kant (arunkant-uws) |
Changed in barbican: | |
importance: | Undecided → High |
milestone: | none → liberty-1 |
Changed in barbican: | |
status: | Fix Committed → Fix Released |
Changed in barbican: | |
milestone: | liberty-1 → 1.0.0 |
To post a comment you must log in.
I think this can be a simplified check since order are not covered by ACLs now, and therefore are still project-id based.
So I think if the stored key is not associated with the order's project-id, it should be rejected at API time (so no need to check this on the worker again later)
If that check passes on the API side, or the worker is now processing this order, a check is then made to see if the secret has an ACL associated with it. If it does, then I think initially we can reject this request as well.
We might relax this later and say that if the project-id is on the ACL for the stored key, then we allow the order to process. I say that because if a certificate/ container is the created based on the stored key, then an attempt to GET that container using the project-id should probably succeed.