<div dir="ltr">Hi Douglas,<div><br></div><div>Thank you very much for your feedback.</div><div><br></div><div>It is ideal to have keystone. However, building a keystone server and having it integrate with the existing identity service would be extra overhead. I'm looking for a simpler authentication/authorization method. I was not sure if authentication in barbican was tied to keystone or if there were other options. Repose is an interesting option. I'm going to take a look at it.</div><div><br></div><div>Another question - does barbican cache the master key from the HSM? Sometimes the response for storing/retrieving secrets and keys is very fast (less than a second) and other times it takes longer.</div><div><br></div><div>Thanks,</div><div>Naveed</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 25, 2017 at 12:37 PM, Douglas Mendizábal <span dir="ltr"><<a href="mailto:douglas.mendizabal@rackspace.com" target="_blank">douglas.mendizabal@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Hi Naveed,<br>
<br>
It is possible to deploy Barbican without Keystone, but you should<br>
take care to secure access to the service by other means.<br>
<br>
Typically, you would deploy Barbican and configure keystonemiddleware<br>
to validate keystone tokens provided by the user.  The middleware<br>
takes care of validating the token with the Keystone service and then<br>
adds the user information it recieved to the request in the form of<br>
new request headers. [1]<br>
<br>
Barbican will look at the X-Project-Id, X-User-Id and X-Roles headers<br>
in the request and apply the rules in policy.json [2] to decide<br>
whether the user sending the request should be allowed to access a<br>
secret or not.<br>
<br>
Whatever non-keystone auth option you choose must add those same<br>
headers to the request.<br>
<br>
For example, I have deployed Barbican using Repose [3] instead of<br>
keystonemiddleware to perform authN/authZ against my company's<br>
identity service.  I then configured Repose to add the required<br>
headers after validating the identity of the user.<br>
<br>
Since barbican is only looking at the request after Repose processed<br>
it, it made no difference that I was not using keystonemiddleware.<br>
<br>
If you really don't want any kind of auth in front of Barbican (not<br>
sure why you'd do this other than to kick the tires on the API) then<br>
you can look at the no-auth setup in [4].<br>
<br>
I hope that helps,<br>
- - Douglas<br>
<br>
<br>
[1]<br>
<a href="http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddl" rel="noreferrer" target="_blank">http://docs.openstack.org/<wbr>developer/keystonemiddleware/<wbr>api/keystonemiddl</a><br>
eware.auth_token.html#what-<wbr>auth-token-adds-to-the-<wbr>request-for-use-by-the<br>
- -openstack-service<br>
[2]<br>
<a href="https://github.com/openstack/barbican/blob/master/etc/barbican/policy.js" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>barbican/blob/master/etc/<wbr>barbican/policy.js</a><br>
on<br>
[3] <a href="http://www.openrepose.org/" rel="noreferrer" target="_blank">http://www.openrepose.org/</a><br>
[4] <a href="http://docs.openstack.org/developer/barbican/setup/noauth.html" rel="noreferrer" target="_blank">http://docs.openstack.org/<wbr>developer/barbican/setup/<wbr>noauth.html</a><br>
<div><div class="h5"><br>
On 1/25/17 11:09 AM, Naveed A wrote:<br>
> Hello,<br>
><br>
> Has anyone tried implementing barbican in standalone mode so that<br>
> it is connected to HSM or KMIP but not using keystone? Would such a<br>
> setup work?<br>
><br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________ Mailing list:<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack</a> Post<br>
> to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a> Unsubscribe :<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack</a><br>
><br>
-----BEGIN PGP SIGNATURE-----<br>
Comment: GPGTools - <a href="https://gpgtools.org" rel="noreferrer" target="_blank">https://gpgtools.org</a><br>
<br>
iQIcBAEBCgAGBQJYiQyBAAoJEB7Z2E<wbr>QgmLX7keEQAJBz8QEPrngmYyGGJZmR<wbr>sDGl<br>
RvufE1RnUZpyqWLNYUlip92QYJz5hl<wbr>R24jSwcXYhKdn/<wbr>p0TwYz3bw2Owu6k6XTzB<br>
vEvyswad+qEU7IXP0/<wbr>tMtjcWRiPLXvuZrniqhYuZ7Ivkv8Wy<wbr>MFQC3oddqUqkJXQl<br>
YO0wjaDf4r3KYBUA8/<wbr>bfEal3AdJ5OQjTchaQ6AbTEhqrRoOh<wbr>KMAhh42vHNOzphs9<br>
lhLTxqBfKW71uiK7NY9DOaJvTBD84T<wbr>ZmcD5/DQ64wvT2ELmrazCLvvtZ+AG/<wbr>sIdd<br>
9az4yH1LBfW9fwaHYuJZzJlUp8zgDd<wbr>m3ZikkRwKLLjUSZlshXlfWXpAMOMuA<wbr>x/OM<br>
qejjKgxpoIO5HsJg02MKVOEP9WXoeC<wbr>8jlfMqLlb9eDd3pFXNRHM16GVjiMeg<wbr>Vt6j<br>
hJJIRGm2AzWArsJRYchOqSE5ghsaK8<wbr>jwzBPuZv/<wbr>H5dCPTFuKthya6ir99j6BpSVL<br>
CGv/XCunAq4LZKXtv2U4Txps5+<wbr>QvFZ9nYkSOmLFn/<wbr>0smspOqWporherG9Kdfy4dQ<br>
UNQnlJ4O2HaAt4M1RPXFyLcweqYRfA<wbr>KcKyHJ1L/nQBZghCWwtKnvhsDft+<wbr>4TgdEG<br>
rk/PDML9Ru7ylnGqgYzIkUy/<wbr>l1rXUeWAEsUs/<wbr>GjPdVvjIuoAanuTaefP9TBjccjT<br>
9uJrpoasZJBrStSRIkMN<br>
=cfGX<br>
-----END PGP SIGNATURE-----<br>
<br>
______________________________<wbr>_________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack</a><br>
</blockquote></div><br></div>