Open Stack

I agree pretty much across the board.

On Mon, Oct 8, 2012 at 11:45 AM, Adam Young <ayoung at redhat.com> wrote:

>  On 10/02/2012 04:33 PM, Matt Joyce wrote:
>
> 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?
>
> I think for some deployments yes, others no, so we need to be aware.  I
> think that the cases where Keystone is used to add users to a posix
> compliant backend,  we need to make sure we can pass values other than
> those required strictly by Keystone, and we need to make sure we can tie in
> with, say, a backend UID generation scheme.
>
>
>
> 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.
>
>
> So for "centralized authentication,  local authorization "  my guess is
> the policy for synchronization needs to be configurable.  Even where all
> the group info is maintained in a backend local to keystone, we may need to
> sync some local group info from a remote system.  Getting that right will
> be, I think iterative, so p[lease record what your thoughts are, and lets
> make the blueprints as comprehensive as possible.  After that, we can
> prioritize the work.
>
>
>
>
> 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
>>>>>
>>>>> 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
>>
>>
>>>           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
>>> 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 listOpenStack-dev at lists.openstack.orghttp://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/20121008/40c46299/attachment.html>