Jump to: navigation, search

Barbican/Discussion-Federated-Barbican

< Barbican
Revision as of 20:33, 17 August 2015 by Arun Kant (talk | contribs) (Overview)

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.

General Federated Barbican Flow


Comments

1) Clarification around flow: As result of part 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?