Difference between revisions of "Barbican/Discussion-Federated-Barbican"
m (→Overview) |
m (→Comments) |
||
| Line 20: | Line 20: | ||
| − | 1) Clarification around flow: As result of | + | 1) Clarification around flow: As result of step 2, client will get unscoped token for on-premise keystone and then use will that token to get scoped token for that on-premise cloud. Then client can use that scoped token <big>to talk directly</big> to on-premise Barbican. I don't think there is any Barbican to Barbican request redirection (which is more around resource federation use case which is not supported). Can someone clarify that? |
Revision as of 22:30, 17 August 2015
Contents
This wiki page is a work in progress, intended to get contributors thinking about how to implement a Federated Barbican.
There is a current desire for Barbican to be able to federate secrets from a private cloud into a public cloud.
Overview
In the current Barbican implementation, only one secret crypto device may be attached to the back end. This becomes problematic when a client wants to hook up their KMIP device within a public cloud infrastructure. The proposed solution is to create a federated barbican where a separate barbican is put in front of a client's KMIP device on-prem and when a request is made to the public barbican, it is authenticated and routed to the private Barbican when necessary.
Comments
1) Clarification around flow: As result of step 2, client will get unscoped token for on-premise keystone and then use will that token to get scoped token for that on-premise cloud. Then client can use that scoped token to talk directly to on-premise Barbican. I don't think there is any Barbican to Barbican request redirection (which is more around resource federation use case which is not supported). Can someone clarify that?
