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
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
> > 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
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo