Re: [openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.
On Mon, Jul 7, 2014 at 3:05 PM, Adam Young ayo...@redhat.com wrote:
On 07/07/2014 11:11 AM, Dolph Mathews wrote:
On Fri, Jul 4, 2014 at 5:13 PM, Adam Young ayo...@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: [openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.
On Fri, Jul 04, 2014 at 06:13:30PM -0400, Adam Young 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.
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.
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.
Using this time limit horizon should extend all the unscoped token
every x min (with x 10). Is this useful or could be long lived but
revocable by Keystone? In this case, after the unscoped token is
revoked it cannot be used to get a scoped token.
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.
Comments?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Eng. Marco Fargetta, PhD
Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy
EMail: marco.farge...@ct.infn.it
smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.
On 07/07/2014 05:39 AM, Marco Fargetta wrote:
On Fri, Jul 04, 2014 at 06:13:30PM -0400, Adam Young 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.
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.
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.
Using this time limit horizon should extend all the unscoped token
every x min (with x 10). Is this useful or could be long lived but
revocable by Keystone? In this case, after the unscoped token is
revoked it cannot be used to get a scoped token.
Close. I was thinking more along the lines of Horizon looking at the
unscoped token and, if it is about to expire, exchanging one unscoped
token for another. The unscoped tokens would have a short time-to-live
(10 minutes) and any scoped tokens they create would have the same time
span: we could in theory make the unscoped last longer, but I don't
really think it would be necessary.
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.
Comments?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.
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. Using this time limit horizon should extend all the unscoped token every x min (with x 10). Is this useful or could be long lived but revocable by Keystone? In this case, after the unscoped token is revoked it cannot be used to get a scoped token. Close. I was thinking more along the lines of Horizon looking at the unscoped token and, if it is about to expire, exchanging one unscoped token for another. The unscoped tokens would have a short time-to-live (10 minutes) and any scoped tokens they create would have the same time span: we could in theory make the unscoped last longer, but I don't really think it would be necessary. When should Horizon check the token validity? If it depends from external events, like user interactions, I think the time-frame should be similar to the user session to avoid the need of authenticate users many times inside the session. If you use an external thread to renew the token then they could be shorter but this would generate some traffic to evaluate. smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.
On 07/07/2014 10:33 AM, Marco Fargetta wrote: 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. Using this time limit horizon should extend all the unscoped token every x min (with x 10). Is this useful or could be long lived but revocable by Keystone? In this case, after the unscoped token is revoked it cannot be used to get a scoped token. Close. I was thinking more along the lines of Horizon looking at the unscoped token and, if it is about to expire, exchanging one unscoped token for another. The unscoped tokens would have a short time-to-live (10 minutes) and any scoped tokens they create would have the same time span: we could in theory make the unscoped last longer, but I don't really think it would be necessary. When should Horizon check the token validity? If it depends from external events, like user interactions, I think the time-frame should be similar to the user session to avoid the need of authenticate users many times inside the session. If you use an external thread to renew the token then they could be shorter but this would generate some traffic to evaluate. The session token would be saved in the users HTTP session cookie. When a user interacts with Horizon, django-openstack-auth would check for the presence of the session cookie, and, if the cookie is about to expire, extend it. It does mean that the Horizon web app can only perform operations when actively initiated by the user, otherwise the session will be automatically extended forever if the user justs sits on the page. Using an ajax approach with automatically timed refreshes, could potentially lead to this, but it is not the case now. The threshold to refresh should be fairly close to session time out: If the session times out in 20 minutes, don't refresh every 30 seconds. If the token duration is 10 minutes, and the user triggers a Horizon request at 9 minutes and 30 seconds, django-openstack-auth can refresh the token: a 30 second window is reasonable. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.
On Fri, Jul 4, 2014 at 5:13 PM, Adam Young ayo...@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?
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?
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.
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.
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?
Comments?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.
On 07/07/2014 11:11 AM, Dolph Mathews wrote:
On Fri, Jul 4, 2014 at 5:13 PM, Adam Young ayo...@redhat.com
mailto:ayo...@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.
But this enumeration is going to have to be performed by Horizon every
time a user initially logs in. 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.
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.
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.
Comments?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.
Probably should not have posted this over a weekend, especially a Long
weekend.
On 07/04/2014 06:13 PM, Adam Young 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.
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.
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.
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.
Comments?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
