Re: [openstack-dev] [Keystone][oslo] Trusted Messaging Question

2013-10-14 Thread Simo Sorce
e in front of keystone. Same for x509 certs, but again these are orthogonal uses. 3. As I explained on IRC, the idea for the secure messaging code was to draw a 'template' for the client side. So that additional methods could be plugged in. The securemessage class is quite abstract an

Re: [openstack-dev] Keystone Apache2 Installation Question

2013-10-14 Thread Simo Sorce
plugins. The only thing that > doesn't work is REMOTE_USER rewriting. Though you could probably add that > feature in somehow using a http response header or something. If all you end up using is basic auth, what is the point of using Kerberos at all ? Basic Auth should never be used w

Re: [openstack-dev] Http library usage by clients

2013-06-27 Thread Simo Sorce
> > trusts mechanism that was released with Grizzly, something that i > > understand is planned anyway. > > > > Indeed it is. But right now, the most excellent "make an EC2 keypair > and sign stuff with it" scheme is working out pretty wel

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

2013-07-02 Thread Simo Sorce
ntials API IFF > Keystone's v3 API is enabled in the deployment? Then, deprecate the old > code and when Keystone v2 API is sunsetted, then remove the old Nova > keypairs API codepaths? I guess you also need to handle a migration of the data from one store to the other ? Or are these data migrations left as an exercise to the admins ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

2013-07-02 Thread Simo Sorce
turf. So for the nova keypairs I think Keystone is the natural place, as that information doesn't need strong protection, it's just public keys. For private keys Keystone wouldn't do, and a URL redirection scheme as proposed by Jarret makes a lot of sense in this case. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

2013-07-02 Thread Simo Sorce
location. > > > +1 for using Barbican > If you do not trust keystone to give you the right information you have already lost as keystone is used (afaik) to check for authorization anyway. Can you be a little bit more explicit on the threat model you have in mind and what guarantees Bar

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

2013-07-02 Thread Simo Sorce
rom the BP which says Key Manager will be > separate service but not a part of Keystone. Sorry I don't follow, Barbican is separated from Keystone. > If no, then why we are thinking about new Key manager (which seems to me a > subset of above BP)? New ? Simo. -- S

[openstack-dev] [barbican] Use common openstack crypto from oslo ?

2013-07-18 Thread Simo Sorce
incomplete plus it seem to me (but it is late) that _strip_pad will just fail when the plaintext is an exact multiple of the block_size. Let me know if you need help using the (now) common crypto utils functions instead. Simo. -- Simo Sorce * Red Hat, Inc * New York

Re: [openstack-dev] [barbican] Use common openstack crypto from oslo ?

2013-07-18 Thread Simo Sorce
On Thu, 2013-07-18 at 22:16 -0400, Simo Sorce wrote: > I was taking a look at Barbican sources on github and I noticed there is > an implementation of a crypto class there. > > I was wondering if Barbican can be made to use the crypto utils pushed > to oslo-incubator instead of

Re: [openstack-dev] [keystone] Extending policy checking to include target entities

2013-07-23 Thread Simo Sorce
gt; >>>>> exist (since we can know where the non-existant object was!). So > >>>>> this would modify the expected return codes. > >>>>> > >>>>> - I really think we need some good documentation on how to bud > >>>>> keystone policy

Re: [openstack-dev] [keystone] [oslo] postpone key distribution bp until icehouse?

2013-08-13 Thread Simo Sorce
ty review". FWIW I did circulate the design for the security mechanism internally in Red Hat to some people with some expertise in crypto matters. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [oslo] postpone key distribution bp until icehouse?

2013-08-14 Thread Simo Sorce
On Wed, 2013-08-14 at 12:35 -0300, Thierry Carrez wrote: > Simo Sorce wrote: > >> During today's project status meeting [1], the state of KDS was > >> discussed [2]. To quote ttx directly: "we've been bitten in the past > >> with late security-se

Re: [openstack-dev] [keystone] [oslo] postpone key distribution bp until icehouse?

2013-08-14 Thread Simo Sorce
I haven't followed closely the latest discussions on this, so > maybe this is not as much duplication of effort as I think ? For the Nth time KDS and Barbican do not do the same job, no more than Keystone auth paths and barbican do the same job. All three use crypto and &#x

Re: [openstack-dev] [keystone] [oslo] postpone key distribution bp until icehouse?

2013-08-14 Thread Simo Sorce
se ? Why does it have to be > in havana ? Because it was painful top rebase due to the migrations code, however since Adam landed the code that splits migrations so that extensions can have their own separate code for that I think the burden will be substantially lower. If this is