Jump to: navigation, search

Difference between revisions of "Barbican/Discussion-Federated-Barbican"

(Overview)
(Overview)
Line 12: Line 12:
 
a request is made to the public barbican, it is authenticated and routed to the private Barbican when necessary.
 
a request is made to the public barbican, it is authenticated and routed to the private Barbican when necessary.
  
[[File:FederatedBarbicanDiagram.jpg|20px|framed|center|Generic Federated Barbican Flow]]
+
[[File:FederatedBarbicanDiagram.jpg|1000px|thumb|center|alt text]]

Revision as of 19:55, 10 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.

alt text