Open Stack

Sorry to be a persistent pest :-)
But you need to have a properly specified trust model so that the system 
can compute an unbroken chain of trust from the configured in root(s) of 
trust to the user. A typical way of passing trust from a CA trust anchor 
is by it issuing either an X.509 AC or SAML assertion to a user which 
details the privileges it has (in this case admin user). The assertion 
can contain the public key of the user as well as the role, so that any 
recipient can unambiguously deduce that this user has been given the 
admin role

regards

david


On 24/04/2013 17:03, Adam Young wrote:
> On 04/24/2013 08:27 AM, Dolph Mathews wrote:
>> Given that credentials are owned by users, and there may be more than
>> one "admin" user, I'm not sure that's ideal.
> The plan was always to have some way to scoped down the signing cert.
> It seems like the two potential scopes is either the "keystone" user or
> the keystone endpoint.  It seems like the User object is more consistent
> with the rest of the cert management.  We can specify who the default
> signing user is either in a config file change or via some new API.  I'm
> trying to do this within the previous design approach, though, and I am
> not certain that any new API is really desirable.  We had discussed
> using the Credentials API for this in the past.  Agreeds that we
> shouldn't just say "admin" although that might be a viable default.
>
> An alternative is to require a "signing user" field into the PKI token
> format.  That was an extension I was planning for anyway, but had not
> yet specified.  It still leaves undefinied how to enforce that a given
> user certificate is authorized to sign tokens.
>
> We need to ship the  CA cert alongside the signing cert as well.
>
> The more I think about it, the more I am concerned with using the
> credential API as is.  I think that the certificates we are talking
> about here need to be very carefully controlled.  We don't want someone
> uploading their own certificate and redirecting the PKI sigining to
> their own machines certificate.  I think that the signing certificates
> need to be stored in the filesystem, and the Keystone Posix user (or
> Apache HTTPD user) should only have read access to these.
>
>
>
>
>
>>
>>
>> -Dolph
>>
>>
>> On Tue, Apr 23, 2013 at 11:04 PM, Adam Young <ayoung at redhat.com
>> <mailto:ayoung at redhat.com>> wrote:
>>
>>     On 04/23/2013 10:29 PM, Dolph Mathews wrote:
>>>     It's not a core API feature, because as Jonathan pointed out, the
>>>     resources don't make sense in a UUID configuration. If it ends up
>>>     in v3, it should be done as an extension and they should raise a
>>>     404 when the token_format is UUID (or in Havana, a standalone
>>>     middleware that you install when opting for the PKI token_factory
>>>     plugin).
>>
>>     I'd like to leave it as V2 only.  For V3, we should make use of
>>     the credential API. The CA cert and the signing certs should both
>>     be owned by the keystone admin user, so the question is how should
>>     the auth_token middleware figure that out?
>>
>>
>>>
>>>
>>>     -Dolph
>>>
>>>
>>>     On Tue, Apr 23, 2013 at 8:13 PM, Adam Young <ayoung at redhat.com
>>>     <mailto:ayoung at redhat.com>> wrote:
>>>
>>>         On 04/23/2013 06:22 PM, Yee, Guang wrote:
>>>>
>>>>         I think that’s debatable. But please file a bug so we can
>>>>         keep track of it.
>>>>
>>>>         Thanks,
>>>>
>>>>         Guang
>>>>
>>>>         *From:*Brownell, Jonathan C (Corvallis)
>>>>         *Sent:* Tuesday, April 23, 2013 3:10 PM
>>>>         *To:* Yee, Guang; Miller, Mark M (EB SW Cloud - R&D -
>>>>         Corvallis); Adam Young; Dolph Mathews
>>>>         *Subject:* RE: Keystone Certificate Distribution
>>>>
>>>>         I was also surprised to see that the /v2.0/certificates/*
>>>>         content is available even when the token_format = UUID.
>>>>
>>>>         Jonathan
>>>>
>>>>         *From:*Yee, Guang
>>>>         *Sent:* Tuesday, April 23, 2013 2:24 PM
>>>>         *To:* Miller, Mark M (EB SW Cloud - R&D - Corvallis); Adam
>>>>         Young; Dolph Mathews
>>>>         *Cc:* Brownell, Jonathan C (Corvallis)
>>>>         *Subject:* RE: Keystone Certificate Distribution
>>>>
>>>>         Adam, Dolph,
>>>>
>>>>         Looks like the certificate distribution APIs are not in the
>>>>         V3 API set.
>>>>
>>>>         /certificates/ca
>>>>
>>>>         /certificates/signing
>>>>
>>>>         You guys recall why we didn’t include them. In any case,
>>>>         given that PKI token is now the default, we should include
>>>>         them in 3.1. What say you?
>>>>
>>>>         Guang
>>>>
>>>         No, it is not a bug.  The content of that file might not be
>>>         needed, but there is no reason to hide it.
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>