Difference between revisions of "Barbican/Discussion-Federated-Barbican"
< Barbican
| Line 36: | Line 36: | ||
The scenario I am thinking about is swift encryption. | The scenario I am thinking about is swift encryption. | ||
| + | There are two ideas that myself, diazjf, and edtubill have been working on: | ||
| − | ===== | + | 1. Proxy redirect |
| + | 2. Crypto Driver | ||
| + | |||
| + | === Proxy === | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | == Comments == | ||
* 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? | * 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? | ||
**Silos - I think you are right. The way federated keystone is implemented now you first get a token to get access to the federated resources. The new diagram should reflect that. However I think this does raise a concern. In a production environment there would need to be some type of automation to tell barbican which keys are in the public barbican and which keys are in the federated barbican. That way the barbicanclient knows when to make a request to the public barbican or federated barbican. Does anyone else see this as a problem? | **Silos - I think you are right. The way federated keystone is implemented now you first get a token to get access to the federated resources. The new diagram should reflect that. However I think this does raise a concern. In a production environment there would need to be some type of automation to tell barbican which keys are in the public barbican and which keys are in the federated barbican. That way the barbicanclient knows when to make a request to the public barbican or federated barbican. Does anyone else see this as a problem? | ||
**Diazjf - Correct, The public Keystone will act as an IdP(Identity Provider), and the Private as a SP(Service Provider). The user must then use the IdP to obtain a SAML assertion and then use that assertion in order to generate an unscoped token for the SP. Then that token must be scoped, before an actions can be performed with it. For this K2K (Keystone-Keystone) Federation is required. A similar process must be done when using OpenIDC if 2 keystones are setup to use the same IdP. My concern here is that the user will need to know where the secret is stored before asking for it. I would propose for Secret objects to have a flag to check if its a link and be able to include links to a Barbican secret in another location. Hence, no special commands need to be performed for storing/getting a secret. | **Diazjf - Correct, The public Keystone will act as an IdP(Identity Provider), and the Private as a SP(Service Provider). The user must then use the IdP to obtain a SAML assertion and then use that assertion in order to generate an unscoped token for the SP. Then that token must be scoped, before an actions can be performed with it. For this K2K (Keystone-Keystone) Federation is required. A similar process must be done when using OpenIDC if 2 keystones are setup to use the same IdP. My concern here is that the user will need to know where the secret is stored before asking for it. I would propose for Secret objects to have a flag to check if its a link and be able to include links to a Barbican secret in another location. Hence, no special commands need to be performed for storing/getting a secret. | ||
Revision as of 19:36, 31 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.
Federated Keystone Currently
The diagram below shows how Federated Keystone would currently work with Barbican. Everything that would be necessary to deploy an environment such as the one below, already exists in Barbican and Keystone.
Federated Barbican
Federated Keystone offers a good amount of solutions to some issues. These include:
- Scaling Barbicans
- Multiple Crypto Devices
- Workload Distribution
- Hybrid Barbicans
However, there are still a few limitations that need to be addressed.
The biggest one that I can see is automation of the key retrieval.
This problem does not appear to be unique to us. I would think other services might have set up some kind of pipeline or middleware of some sort that automatically takes care of steps 1-5. That is currently something I am looking into right now.
The other concern is directing the secret retrieval to the correct barbican. The scenario I am thinking about is swift encryption.
There are two ideas that myself, diazjf, and edtubill have been working on:
1. Proxy redirect 2. Crypto Driver
Proxy
Comments
- 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?
- Silos - I think you are right. The way federated keystone is implemented now you first get a token to get access to the federated resources. The new diagram should reflect that. However I think this does raise a concern. In a production environment there would need to be some type of automation to tell barbican which keys are in the public barbican and which keys are in the federated barbican. That way the barbicanclient knows when to make a request to the public barbican or federated barbican. Does anyone else see this as a problem?
- Diazjf - Correct, The public Keystone will act as an IdP(Identity Provider), and the Private as a SP(Service Provider). The user must then use the IdP to obtain a SAML assertion and then use that assertion in order to generate an unscoped token for the SP. Then that token must be scoped, before an actions can be performed with it. For this K2K (Keystone-Keystone) Federation is required. A similar process must be done when using OpenIDC if 2 keystones are setup to use the same IdP. My concern here is that the user will need to know where the secret is stored before asking for it. I would propose for Secret objects to have a flag to check if its a link and be able to include links to a Barbican secret in another location. Hence, no special commands need to be performed for storing/getting a secret.
