Open Stack

The fundamental question I still have is tracking posix user data.  Is that
something we want to pass forward from directory services backending
openstack or is it outside of the scope of keystone?

If it is in scope do we want to provide an internal directory and if so do
we want to optionally allow keystone to provide on the fly posix data for
backends lacking posix schemas.

This is "relevant to my interests".

-Matt

On Tue, Oct 2, 2012 at 12:01 PM, Adam Young <ayoung at redhat.com> wrote:

> On 10/02/2012 01:58 PM, Ralf Haferkamp wrote:
>
>> On Tue, Oct 02, 2012 at 01:06:44PM -0400, Adam Young wrote:
>>
>>> On 10/02/2012 12:07 PM, Ralf Haferkamp wrote:
>>>
>>>> On Thu, Sep 27, 2012 at 01:52:25PM -0400, Adam Young wrote:
>>>>
>>>>> On 09/27/2012 04:15 AM, Ralf Haferkamp wrote:
>>>>>
>>>> [..]
>>>>
>>>>> BTW, has anybody else been working on this already? Does this even
>>>>>>>> sound like a
>>>>>>>> feature worth adding?
>>>>>>>>
>>>>>>> Yes, I have, but you are aehad of me.  Please post your patch.  It
>>>>> is the right approach.
>>>>>
>>>> I have just pushed the code to the "external-branch" in my github clone
>>>> at:
>>>> https://github.com/rhafer/**keystone/tree/external-auth<https://github.com/rhafer/keystone/tree/external-auth>
>>>>
>>>> Feel free to review and comment. It still needs quite a bit of testing.
>>>> But the
>>>> basics seem to work for me. Currently, to use external authentication
>>>> you need
>>>> to POST something like this to the /tokens URL (as with
>>>> username/password
>>>> authentication the "tenantName" is optional):
>>>>
>>>>      {
>>>>          "auth": {
>>>>                  "external": "True",
>>>>                  "tenantName": "test"
>>>>          }
>>>>      }
>>>>
>>> Good first take.  However, I would prefer to add an else block on:
>>>
>> Yes, this seems to make sense. I'll rework the code accordingly. (It
>> might take a
>> little while though as I'll be afk for a few days)
>>
>>    if auth is None
>>>    if 'REMOTE_USER' in context:
>>>       #assume external request for unscoped token
>>>    if 'passwordCredentials' in auth:
>>>      #UserID and Password passed explicitly here will trump REMOTE_USER
>>>    elif 'token' in auth:
>>>      ...
>>>    else
>>>       if 'REMOTE_USER' in context:
>>>         if 'tenantName' in auth:
>>>            # allocate scoped token
>>>             #not 100% sure I want to allow this, but that is a different
>>> discussion
>>>
>> I was thinking about that as well, but then I could not really come up
>> with a
>> reason for not allowing it :). Do have one?
>>
>
> My feeling is that a user should use an unscoped token like a TGT. It ties
> in with the delegation blueprint:
>
> http://wiki.openstack.org/**keystone/Delegation<http://wiki.openstack.org/keystone/Delegation>
>
>
>>           else:
>>>            #assume external request for unscoped token
>>>             #don't fail just because there is an auth block.
>>>
>>>
>>>
>>>
>>>  Of course you need keystone be backed by apache and apache configured
>>>> to do
>>>> somekind of authentication (up to now I just tested with mod_auth_kerb).
>>>> Additionally the ExternalAuthMiddleware needs to be added to keystone's
>>>> service
>>>> pipelines in keystone.conf
>>>>
>>> Fantastic.  Thanks for doing that.
>>>
>>>  I didn't have time yet to implement anything on the client side. Up to
>>>> now I
>>>> just used curl for testing. E.g. this works to request a scoped token
>>>> using
>>>> kerberos authentication:
>>>>
>>>>      curl -u : --negotiate http://<keystone-server>:5000/**v2.0/tokens
>>>> \
>>>>          -d '{"auth": {"external": "True", "tenantName": "test"}}' \
>>>>          -H "Content-type: application/json"
>>>>
>>> Yeah, lets Iron out the API before chasing the CLI.
>>>
>>> Nice work.
>>>
>> thanks for the feedback,
>>      Ralf
>>
>> ______________________________**_________________
>> 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 <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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121002/882db9e6/attachment-0001.html>