Open Stack

> The risk here is that changes to fix issues in Keystone that originate
with PKI/CMS handling will require changes to both Common and Keystone
projects in sync

Ah, yes... I just misunderstood the above!

+1 in favor of moving auth_token+hashing+cms to openstack-common.

-Dolph


On Tue, Sep 11, 2012 at 12:21 PM, Joseph Heck <heckj at mac.com> wrote:

> Not sure I understand your question Dolph - isn't CMS one of the pieces
> that he's suggesting?
>
> I think moving this into openstack-common would make good sense - the big
> request that's driving this (aside from general cleanliness) is the request
> to not have to install all of keystone to get the auth_token bits.
>
> The best way we can help with that is to make sure we have the
> dependencies well encapsulated around auth_token and share that info with
> the packagers (which I think reasonably means making some dev-docs notes
> about it - although we could of course just pop in and pester
> #openstack-packaging).
>
> -joe
>
>
> On Sep 11, 2012, at 10:05 AM, Dolph Mathews <dolph.mathews at gmail.com>
> wrote:
>
> Would it be appropriate to formally move cms into openstack-common as
> well? It seems clients should eventually consume some of that functionality
> as well (e.g. verify_token)?
>
> -Dolph
>
>
> On Tue, Sep 11, 2012 at 11:20 AM, Adam Young <ayoung at redhat.com> wrote:
>
>> I think that we can get away with the current set up for auth_token
>> middleware  (shipping it inside Keystone but deploying it as a stand alone
>> file) if we move its dependencies to openstack common.  Those dependencies
>> are:
>>
>> keystone/common/cms.py
>> keystone/common/utils.py
>>
>> cms Is all my work, and I am happy to change it to openstack commons
>> pulled in as a dependency.
>>
>> keystone/common/utils.py has one function in it that is used by
>> auth_token:
>>
>> utils.hash_signed_token(**signed_text)
>>
>> Which is a very thin wrapper around hashlib:
>>
>> def hash_signed_token(signed_text)**:
>>     hash_ = hashlib.md5()
>>     hash_.update(signed_text)
>>     return hash_.hexdigest()
>>
>> We can move this to the auth_token middleware, as the only other place it
>> is used is in the unit test code in keystone tests/test_auth_token_**
>> middleware.py
>>
>> This will add a hashlib dependency on auth_token middleware,  but it is
>> required for Signed token authentication anyway.
>>
>> The risk here is that changes to fix issues in Keystone that originate
>> with PKI/CMS handling will require changes to both Common and Keystone
>> projects in sync,  but if I get an agreement from the common folk  that
>> they will be responsive to Keystone changes, that should not be a real
>> problem.
>>
>>
>> Is this acceptable?
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120911/490641fb/attachment-0001.html>