Open Stack

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 
> <mailto: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
>         <mailto: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
>     <mailto: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/20121008/e5132c5b/attachment-0001.html>