Open Stack

On Mon, Jul 7, 2014 at 3:05 PM, Adam Young <ayoung at redhat.com> wrote:

>  On 07/07/2014 11:11 AM, Dolph Mathews wrote:
>
>
> On Fri, Jul 4, 2014 at 5:13 PM, Adam Young <ayoung at redhat.com> wrote:
>
>> Unscoped tokens are really a proxy for the Horizon session, so lets treat
>> them that way.
>>
>>
>> 1.  When a user authenticates unscoped, they should get back a list of
>> their projects:
>>
>> some thing along the lines of:
>>
>> domains [{   name = d1,
>>                  projects [ p1, p2, p3]},
>>                {   name = d2,
>>                  projects [ p4, p5, p6]}]
>>
>> Not the service catalog.  These are not in the token, only in the
>> response body.
>>
>
>  Users can scope to either domains or projects, and we have two core
> calls to enumerate the available scopes:
>
>    GET /v3/users/{user_id}/projects
>   GET /v3/users/{user_id}/domains
>
>  There's also `/v3/role_assignments` and `/v3/OS-FEDERATION/projects`,
> but let's ignore those for the moment.
>
>  You're then proposing that the contents of these two calls be included
> in the token response, rather than requiring the client to make a discrete
> call - so this is just an optimization. What's the reasoning for pursuing
> this optimization?
>
> It is a little more than just an optimization.
>
> An unscoped token does not currently return a service catalog, and there
> really is no need for it to do so if it is only ever going to be used to
> talk to keystone.  Right now, Horizon cannot work with unscoped tokens, as
> you need a service catalog in order to fetch the projects list.
>

That sounds like a client-side issue.


>
>
> But this enumeration is going to have to be performed by Horizon every
> time a user initially logs in.
>

So, an optimization that only benefits a user-initiated operation.


> In addition, those calls would require custom policy on them, and part of
> the problem we have is that the policy needs to exactly match;  if a user
> can get an unscoped token, they need this information to be able to select
> what scope to match for a scoped token.
>

I'm not sure I follow this point - it seems to suggest that unscoped tokens
break policy, but the reasoning doesn't seem related?


>
>
>
>
>
>
>>
>>
>> 2.  Unscoped tokens are only initially via HTTPS and require client
>> certificate validation or Kerberos authentication from Horizon. Unscoped
>> tokens are only usable from the same origin as they were originally
>> requested.
>>
>
>  That's just token binding in use? It sounds reasonable, but then seems
> to break down as soon as you make a call across an untrusted boundary from
> one service to another (and some deployments don't consider any two
> services to trust each other). When & where do you expect this to be
> enforced?
>
>
> I expect this to be enforced from Keystone.  Specifically, I would say
> that Horizon would get a client certificate to be used whenever it was
> making calls to Keystone on behalf of a user.  The goal is to make people
> comfortable with the endless extension of sessions, by showing that it only
> can be done from a specific endpoint.
>
> Client cert verification can be done in mod_ssl, or mod_nss, or in the ssl
> handling code in eventlet.
>
> Kerberos would work for this as well, just didn't want to make that a hard
> requirement.
>
> The same mechanism (client cert verification) could be used when Horizon
> talks to any of the other services, but that would be beyond the scope of
> this proposal.
>

Before we dismiss it as being outside the scope of this proposal, I'd like
to understand the intended impact and where the trust boundaries are
defined. You didn't seem to answer that here?


>
>
>
>
>
>>
>>
>> 3.  Unscoped tokens should be very short lived:  10 minutes. Unscoped
>> tokens should be infinitely extensible:   If I hand an unscoped token to
>> keystone, I get one good for another 10 minutes.
>>
>
>  Is there no limit to this? With token binding, I don't think there needs
> to be... but I still want to ask.
>
> Explicit revoke or 10 minute time out seem to be sufficient.  However, if
> there is a lot of demand, we could make a max token refresh counter or time
> window, say 8 hours.
>
>
>
>
>>
>>
>> 4.  Unscoped tokens are only accepted in Keystone.  They can only be used
>> to get a scoped token.  Only unscoped tokens can be used to get another
>> token.
>>
>
>  "Unscoped tokens are only accepted in Keystone": +1, and that should be
> true today. But I'm not sure where you're taking the second half of this,
> as it conflicts with the assertion you made in #3: "If I hand an unscoped
> token to keystone, I get one good for another 10 minutes."
>
>
> Good clarification; I wrote  that wrong.  unscoped tokens can only be used
> for
>
> A)  Getting a scoped token
> B)  Getting an unscoped token with an extended lifespan
> C)  (potentially) Keystone specific operations that do not require RBAC.
>
> (C) is not in the scope of this discussion and only included for
> completeness.
>
>
>
>  "Only unscoped tokens can be used to get another token." This also
> sounds reasonable, but I recall you looking into changing this behavior
> once, and found a use case for re-scoping scoped tokens that we couldn't
> break?
>
>
> It was that use case that triggered this discussion;  Horizon uses one
> scoped token to get another scoped token.  If keystone makes the above
> mechanism the default, then Django-openstack-auth can adjust to work with
> the unscoped->scoped only rule.
>

It sounds like the only blocker in this thread is a client-side issue that
can be resolved in Horizon, and the use case you're describing in horizon
is entirely possible without any modifications to Keystone.


>
>
>
>
>>
>>
>> Comments?
>>
>> _______________________________________________
>> 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/20140708/8d1c13c1/attachment.html>