Re: [openstack-dev] [keystone][security] Service User Permissions

[Jamie Lennox]

On 20 June 2016 at 12:33, Morgan Fainberg  wrote:

>
>
> On Sun, Jun 19, 2016 at 6:51 PM, Adam Young  wrote:
>
>> On 06/16/2016 02:19 AM, Jamie Lennox wrote:
>>
>> Thanks everyone for your input.
>>
>> I generally agree that there is something that doesn't quite feel right
>> about purely trusting this information to be passed from service to
>> service, this is why i was keen for outside input and I have been
>> rethinking the approach.
>>
>>
>> They really feel like a variation on Trust tokens.
>>
>> From the service perspective, they are tokens, just not the one the user
>> originally requested.
>>
>> The "reservation" as I see it is an implicit trust created by the user
>> requesting the operation on the initial service.
>>
>> When the service validates the token, it can get back the,  lets call it
>> a "reserved token" in keeping with the term reservation above.  That token
>> will have a longer life span than the one the user originally requested,
>> but (likely) fewer roles.
>>
>> When nova calls glance, and then glance calls Swift, we can again
>> transition to different reserved tokens if needs be.
>>
>>
>>
> I would really, really, really, prefer not to build in the need to
> "transition" between "reserved" tokens when jumping between services. This
> wont be "impossible", but I really don't want to start from the simpler
> proposal; It's a lot of moving parts.
>
> The big difference here is that trusts are explicit and have a LOT of
> overhead (and frankly would be clunky for this) as currently implemented,
> this is closer to an evolved version of the composite tokens we talked over
> in Paris.
>

It's kind of like each of those things - but i guess mentally i'm trying to
think of it differently and why I explicitly avoided calling it a token
even though there's the obvious similarity.

I'm trying to think of it as authorization for a single operation. Just by
nature of openstack that single operation might pass through a couple of
services to actually be completed.

I don't think we would ever transition or roll reservations. A reservation
lasts for the lifetime of one user request and represents permission for
the rest of openstack to execute this operation on behalf of the user. You
should not be able to use a reservation to fetch another token or
reservation, it is a verified bundle of state.

I also want to not think about it in terms of reducing roles. Ideally we
wouldn't even need to include roles in the reservation because we know up
front the policy check has succeeded (though i doubt this will be
practical). This reservation is only useful to perform the pre-authorized
operation it specifies. Roles are done with by this point, that check has
happened.

As i'm still trying to find good analogies i'll just try saying it in
different ways to get the point across:

An unscoped token is a user's authentication.
A scoped token is a user's authorization on some project.
A reservation is keystone's assertion that openstack services should
perform the enclosed operation for the enclosed user.

A user exchanges credentials for an unscoped token, then uses that to scope
a token to a project and then make calls. A service exchanges the scoped
token and current request information to create a reservation. Service to
service communication then is all about the reservation.

A reservation is operation state, it is not a token that can be used to
perform other actions.

Sorry for rambling.


>
>>
>>
>>
>> To this end i've proposed reservations (a name that doesn't feel right):
>> https://review.openstack.org/#/c/330329/
>>
>> At a gut feeling level i'm much happier with the concept. I think it will
>> allow us to handle the distinction between user->service and
>> service->service communication much better and has the added bonus of
>> potentially opening up some policy options in future.
>>
>> Please let me know of any concerns/thoughts on the new approach.
>>
>> Once again i've only written the proposal part of the spec as there will
>> be a lot of details to figure out if we go forward. It is also fairly rough
>> but it should convey the point.
>>
>>
>> Thanks
>>
>> Jamie
>>
>> On 3 June 2016 at 03:06, Shawn McKinney  wrote:
>>
>>>
>>> > On Jun 2, 2016, at 10:58 AM, Adam Young < 
>>> ayo...@redhat.com> wrote:
>>> >
>>> > Any senseible RBAC setup would support this, but we are not using a
>>> sensible one, we are using a hand rolled one. Replacing everything with
>>> Fortress implies a complete rewrite of what we do now.  Nuke it from orbit
>>> type stuff.
>>> >
>>> > What I would rather focus on is the splitting of the current policy
>>> into two parts:
>>> >
>>> > 1. Scope check done in code
>>> > 2. Role check done in middleware
>>> >
>>> > Role check should be donebased on URL, not on the policy key like
>>> identity:create_user
>>> >
>>> >
>>> > Then, yes, a Fortress style query could be done, or it could be 

Re: [openstack-dev] [keystone][security] Service User Permissions

[Morgan Fainberg]

On Sun, Jun 19, 2016 at 6:51 PM, Adam Young  wrote:

> On 06/16/2016 02:19 AM, Jamie Lennox wrote:
>
> Thanks everyone for your input.
>
> I generally agree that there is something that doesn't quite feel right
> about purely trusting this information to be passed from service to
> service, this is why i was keen for outside input and I have been
> rethinking the approach.
>
>
> They really feel like a variation on Trust tokens.
>
> From the service perspective, they are tokens, just not the one the user
> originally requested.
>
> The "reservation" as I see it is an implicit trust created by the user
> requesting the operation on the initial service.
>
> When the service validates the token, it can get back the,  lets call it a
> "reserved token" in keeping with the term reservation above.  That token
> will have a longer life span than the one the user originally requested,
> but (likely) fewer roles.
>
> When nova calls glance, and then glance calls Swift, we can again
> transition to different reserved tokens if needs be.
>
>
>
I would really, really, really, prefer not to build in the need to
"transition" between "reserved" tokens when jumping between services. This
wont be "impossible", but I really don't want to start from the simpler
proposal; It's a lot of moving parts.

The big difference here is that trusts are explicit and have a LOT of
overhead (and frankly would be clunky for this) as currently implemented,
this is closer to an evolved version of the composite tokens we talked over
in Paris.

--Morgan



>
>
>
> To this end i've proposed reservations (a name that doesn't feel right):
> https://review.openstack.org/#/c/330329/
>
> At a gut feeling level i'm much happier with the concept. I think it will
> allow us to handle the distinction between user->service and
> service->service communication much better and has the added bonus of
> potentially opening up some policy options in future.
>
> Please let me know of any concerns/thoughts on the new approach.
>
> Once again i've only written the proposal part of the spec as there will
> be a lot of details to figure out if we go forward. It is also fairly rough
> but it should convey the point.
>
>
> Thanks
>
> Jamie
>
> On 3 June 2016 at 03:06, Shawn McKinney  wrote:
>
>>
>> > On Jun 2, 2016, at 10:58 AM, Adam Young < 
>> ayo...@redhat.com> wrote:
>> >
>> > Any senseible RBAC setup would support this, but we are not using a
>> sensible one, we are using a hand rolled one. Replacing everything with
>> Fortress implies a complete rewrite of what we do now.  Nuke it from orbit
>> type stuff.
>> >
>> > What I would rather focus on is the splitting of the current policy
>> into two parts:
>> >
>> > 1. Scope check done in code
>> > 2. Role check done in middleware
>> >
>> > Role check should be donebased on URL, not on the policy key like
>> identity:create_user
>> >
>> >
>> > Then, yes, a Fortress style query could be done, or it could be done by
>> asking the service itself.
>>
>> Mostly in agreement.  I prefer to focus on the model (RBAC) rather than a
>> specific impl like Fortress. That is to say support the model and allow the
>> impl to remain pluggable.  That way you enable many vendors to participate
>> in your ecosystem and more important, one isn’t tied to a specific backend
>> (ldapv3, sql, …)
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] Service User Permissions

[Adam Young]

On 06/16/2016 02:19 AM, Jamie Lennox wrote:

Thanks everyone for your input.

I generally agree that there is something that doesn't quite feel 
right about purely trusting this information to be passed from service 
to service, this is why i was keen for outside input and I have been 
rethinking the approach.


They really feel like a variation on Trust tokens.

From the service perspective, they are tokens, just not the one the 
user originally requested.


The "reservation" as I see it is an implicit trust created by the user 
requesting the operation on the initial service.


When the service validates the token, it can get back the,  lets call it 
a "reserved token" in keeping with the term reservation above.  That 
token will have a longer life span than the one the user originally 
requested, but (likely) fewer roles.


When nova calls glance, and then glance calls Swift, we can again 
transition to different reserved tokens if needs be.







To this end i've proposed reservations (a name that doesn't feel 
right): https://review.openstack.org/#/c/330329/


At a gut feeling level i'm much happier with the concept. I think it 
will allow us to handle the distinction between user->service and 
service->service communication much better and has the added bonus of 
potentially opening up some policy options in future.


Please let me know of any concerns/thoughts on the new approach.

Once again i've only written the proposal part of the spec as there 
will be a lot of details to figure out if we go forward. It is also 
fairly rough but it should convey the point.



Thanks

Jamie

On 3 June 2016 at 03:06, Shawn McKinney > wrote:



> On Jun 2, 2016, at 10:58 AM, Adam Young > wrote:
>
> Any senseible RBAC setup would support this, but we are not
using a sensible one, we are using a hand rolled one. Replacing
everything with Fortress implies a complete rewrite of what we do
now.  Nuke it from orbit type stuff.
>
> What I would rather focus on is the splitting of the current
policy into two parts:
>
> 1. Scope check done in code
> 2. Role check done in middleware
>
> Role check should be donebased on URL, not on the policy key
like identity:create_user
>
>
> Then, yes, a Fortress style query could be done, or it could be
done by asking the service itself.

Mostly in agreement.  I prefer to focus on the model (RBAC) rather
than a specific impl like Fortress. That is to say support the
model and allow the impl to remain pluggable.  That way you enable
many vendors to participate in your ecosystem and more important,
one isn’t tied to a specific backend (ldapv3, sql, …)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] Service User Permissions

[Jamie Lennox]

Thanks everyone for your input.

I generally agree that there is something that doesn't quite feel right
about purely trusting this information to be passed from service to
service, this is why i was keen for outside input and I have been
rethinking the approach.

To this end i've proposed reservations (a name that doesn't feel right):
https://review.openstack.org/#/c/330329/

At a gut feeling level i'm much happier with the concept. I think it will
allow us to handle the distinction between user->service and
service->service communication much better and has the added bonus of
potentially opening up some policy options in future.

Please let me know of any concerns/thoughts on the new approach.

Once again i've only written the proposal part of the spec as there will be
a lot of details to figure out if we go forward. It is also fairly rough
but it should convey the point.


Thanks

Jamie

On 3 June 2016 at 03:06, Shawn McKinney  wrote:

>
> > On Jun 2, 2016, at 10:58 AM, Adam Young  wrote:
> >
> > Any senseible RBAC setup would support this, but we are not using a
> sensible one, we are using a hand rolled one. Replacing everything with
> Fortress implies a complete rewrite of what we do now.  Nuke it from orbit
> type stuff.
> >
> > What I would rather focus on is the splitting of the current policy into
> two parts:
> >
> > 1. Scope check done in code
> > 2. Role check done in middleware
> >
> > Role check should be donebased on URL, not on the policy key like
> identity:create_user
> >
> >
> > Then, yes, a Fortress style query could be done, or it could be done by
> asking the service itself.
>
> Mostly in agreement.  I prefer to focus on the model (RBAC) rather than a
> specific impl like Fortress. That is to say support the model and allow the
> impl to remain pluggable.  That way you enable many vendors to participate
> in your ecosystem and more important, one isn’t tied to a specific backend
> (ldapv3, sql, …)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] Service User Permissions

[Shawn McKinney]

> On Jun 2, 2016, at 10:58 AM, Adam Young  wrote:
> 
> Any senseible RBAC setup would support this, but we are not using a sensible 
> one, we are using a hand rolled one. Replacing everything with Fortress 
> implies a complete rewrite of what we do now.  Nuke it from orbit type stuff.
> 
> What I would rather focus on is the splitting of the current policy into two 
> parts:
> 
> 1. Scope check done in code
> 2. Role check done in middleware
> 
> Role check should be donebased on URL, not on the policy key like 
> identity:create_user
> 
> 
> Then, yes, a Fortress style query could be done, or it could be done by 
> asking the service itself.

Mostly in agreement.  I prefer to focus on the model (RBAC) rather than a 
specific impl like Fortress. That is to say support the model and allow the 
impl to remain pluggable.  That way you enable many vendors to participate in 
your ecosystem and more important, one isn’t tied to a specific backend 
(ldapv3, sql, …)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] Service User Permissions

[Adam Young]

On 06/02/2016 11:36 AM, Shawn McKinney wrote:

On Jun 2, 2016, at 10:03 AM, Adam Young  wrote:

To do all of this right, however, requires a degree of introspection that we do not have 
in OpenStack.  Trove needs to ask Nova "I want to do X, what role do I need?"  
and there is no where in the system today that this information lives.

So, while we could make something that works for service users as the problem 
is defined by Nova today, that would be, in a word, bad.  We need something 
that works for the larger OpenStack ecosystem, to include less trusted third 
party services, and still deal with the long running tasks.

Hello,

If openstack supported RBAC (ANSI INCITS 359) you would be able to call 
(something like) this API:

List permissionRoles(Permission  perm) throws SecurityException

Return a list of type String of all roles that have granted a particular 
permission.

RBAC Review APIs:
http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/ReviewMgr.html

One of the advantages of pursuing published standards, you enjoy support for 
requirements across a broad spectrum of requirements, and perhaps for things 
you didn’t know was needed (at design time).


Any senseible RBAC setup would support this, but we are not using a 
sensible one, we are using a hand rolled one.  Replacing everything with 
Fortress implies a complete rewrite of what we do now.  Nuke it from 
orbit type stuff.


What I would rather focus on is the splitting of the current policy into 
two parts:


1. Scope check done in code
2. Role check done in middleware

Role check should be donebased on URL, not on the policy key like 
identity:create_user



Then, yes, a Fortress style query could be done, or it could be done by 
asking the service itself.






Hope this helps,

Shawn
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] Service User Permissions

[Shawn McKinney]

> On Jun 2, 2016, at 10:03 AM, Adam Young  wrote:
> 
> To do all of this right, however, requires a degree of introspection that we 
> do not have in OpenStack.  Trove needs to ask Nova "I want to do X, what role 
> do I need?"  and there is no where in the system today that this information 
> lives.
> 
> So, while we could make something that works for service users as the problem 
> is defined by Nova today, that would be, in a word, bad.  We need something 
> that works for the larger OpenStack ecosystem, to include less trusted third 
> party services, and still deal with the long running tasks.

Hello,

If openstack supported RBAC (ANSI INCITS 359) you would be able to call 
(something like) this API:

List permissionRoles(Permission  perm) throws SecurityException

Return a list of type String of all roles that have granted a particular 
permission.

RBAC Review APIs:
http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/ReviewMgr.html

One of the advantages of pursuing published standards, you enjoy support for 
requirements across a broad spectrum of requirements, and perhaps for things 
you didn’t know was needed (at design time).

Hope this helps,

Shawn
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][security] Service User Permissions

[Adam Young]

On 06/02/2016 01:23 AM, Jamie Lennox wrote:

Hi All,

I'd like to bring to the attention of the wider security groups and 
OpenStack users the Service Users Permissions [1] spec currently 
proposed against keystonemiddleware.


To summarize quickly OpenStack has long had the problem of token 
expiry happening in the middle of a long running operation and failing 
service to service requests and there have been a number of ways 
proposed around this including trusts and using the service users to 
perform operations.


Ideally in a big system like this we only want to validate a token and 
policy once on a user's first entry to the system, however all 
services only communicate via the public interfaces so we cannot tell 
at validation time whether this is the first, second, or twentieth 
time we are validating a token. (If we ever do OpenStack 2.0 we should 
change this)


Validating the "token" happens only once.

Validating the "user" permissions can happen multiple times, assuming 
that nothing changes, the operation goes through.



The part I have trouble with is not Validating the delegation from the 
end user to the service user.  This is a CVE waiting to happen.


A users token should be short (5 minutes) and just kick off the 
workflow.  But that should then be used to create a delegation for the 
remote service.  THat delegation can last longer than the duration of 
the token, to cover the long running tasks, but should not last forever.


While the usual discussion centers aroun Nova based tasks, think about 
all the *aaService endpoint that are going to have this same need.  If I 
kick off a workflow via Trove or Sahara, that endpoint should only be 
able to do what I ask it to do:  spin up the appropriate number of  vms 
in the corresponding projects, and so on.


The delegation mechanism needs to be lighter weight than trusts, but 
should have the sma constraints (redelegation and so on).



To do all of this right, however, requires a degree of introspection 
that we do not have in OpenStack.  Trove needs to ask Nova "I want to do 
X, what role do I need?"  and there is no where in the system today that 
this information lives.


So, while we could make something that works for service users as the 
problem is defined by Nova today, that would be, in a word, bad.  We 
need something that works for the larger OpenStack ecosystem, to include 
less trusted third party services, and still deal with the long running 
tasks.


S4U2Proxy from the Kerberos world is a decent approximation of what we 
need.  A user with a service ticket goes to a remote service and askes 
for an operation.  That service then gets its own proxy service ticket, 
based on its own identity and the service ticket of the requesting 
user.  This Proxy  service ticket is then used for operations on behalf 
of the real user.  The proxy ticket can have a reduced degree of 
authorization, but does not require a deliberate delegation agreement 
between each user and the service.






The proposed spec provides a way to simulate the at-edge validation 
for service to service communication. If a request has an 
X-Service-Token header (an existing concept) then instead of 
validating the user's token we should trust all the headers sent with 
that request (X_USER_ID, X_PROJECT_ID etc). We would still validate 
the X-Service-Token header. This has the effect that one service 
asserts to another that it has already validated this token and the 
receiving service shouldn't validate it again and bypass the expiry 
problem.


The glaring security issue here is that a user with the service role 
can now emulate any request on behalf of any user by sending the 
expected authenticated headers. This will place an extreme level of 
trust on accounts that up to now have generally only been able to 
validate a token. There is both the concern here that a malicious 
service could craft new requests with bogus credentials as well as 
services deciding that this provides them the ability to do 
non-expiring trusts from a user where it can simply replay the headers 
it received on previous requests to perform future operations on 
behalf of a user. This is _absolutely not_ the intended use case but 
something I expect to come up.


There is a variation of this mentioned in the spec where we pass only 
the user-id, project-id and audit information from service to service 
and then middleware can recreate the token from this information 
similar to how fernet tokens work today. There is additional 
processing here which in the standard case will simply reproduce the 
same headers that the last service already knew and it still allows a 
large amount of emulation from the service.


There are possibly ways we can secure this header bundle via signing 
however the practical result is essentially a secondary expiry time 
and an operational complexity that will make PKI tokens and rotating 
fernet keys appear trivial for the benefit of securing a 

Re: [openstack-dev] [keystone][security] Service User Permissions

[David Chadwick]

Hi Jamie

In my opinion no security token should have the potential to last
forever. This is a bad idea and can lead to all sorts of security
vulnerabilities, some of which you highlight below. I thus take issue
with your statement 'Ideally in a big system like this we only want to
validate a token and policy once on a user's first entry to the system'.
Whilst this is true for many situations, I think it should be qualified
with a statement about how long this validation should hold for, such as
'but only for a configurable amount of time, or a certain amount of
resource usage'.

If a security token does not have an expiry time or condition, then
there are two common ways of solving this: polling or notifications.
Various techniques have been deployed for these e.g. CRLs,
publish/subscribe etc. This will require a security layer in OpenStack
that will allow interprocess communications. Is there any ongoing work
along these lines, or plans to introduce it? I believe that various
publish/subscribe mechanisms are available for OpenStack e.g. Marconi.
If so why not leverage one of these, rather than going down the path you
suggest?

At least one research project (e.g. Coco Cloud) has built U-Con into
OpenStack and this provides the functionality you require, but because
this implementation relies on XACML and obligations, it is probably too
heavyweight for you. However the conceptual model is sound and could be
adapted to solve your requirements.

Hope this is helpful to you

regards

David

On 02/06/2016 06:23, Jamie Lennox wrote:
> Hi All,
> 
> I'd like to bring to the attention of the wider security groups and
> OpenStack users the Service Users Permissions [1] spec currently
> proposed against keystonemiddleware.
> 
> To summarize quickly OpenStack has long had the problem of token expiry
> happening in the middle of a long running operation and failing service
> to service requests and there have been a number of ways proposed around
> this including trusts and using the service users to perform operations.
> 
> Ideally in a big system like this we only want to validate a token and
> policy once on a user's first entry to the system, however all services
> only communicate via the public interfaces so we cannot tell at
> validation time whether this is the first, second, or twentieth time we
> are validating a token. (If we ever do OpenStack 2.0 we should change this)
> 
> The proposed spec provides a way to simulate the at-edge validation for
> service to service communication. If a request has an X-Service-Token
> header (an existing concept) then instead of validating the user's token
> we should trust all the headers sent with that request (X_USER_ID,
> X_PROJECT_ID etc). We would still validate the X-Service-Token header.
> This has the effect that one service asserts to another that it has
> already validated this token and the receiving service shouldn't
> validate it again and bypass the expiry problem.
> 
> The glaring security issue here is that a user with the service role can
> now emulate any request on behalf of any user by sending the expected
> authenticated headers. This will place an extreme level of trust on
> accounts that up to now have generally only been able to validate a
> token. There is both the concern here that a malicious service could
> craft new requests with bogus credentials as well as services deciding
> that this provides them the ability to do non-expiring trusts from a
> user where it can simply replay the headers it received on previous
> requests to perform future operations on behalf of a user. This is
> _absolutely not_ the intended use case but something I expect to come up.
> 
> There is a variation of this mentioned in the spec where we pass only
> the user-id, project-id and audit information from service to service
> and then middleware can recreate the token from this information similar
> to how fernet tokens work today. There is additional processing here
> which in the standard case will simply reproduce the same headers that
> the last service already knew and it still allows a large amount of
> emulation from the service.
> 
> There are possibly ways we can secure this header bundle via signing
> however the practical result is essentially a secondary expiry time and
> an operational complexity that will make PKI tokens and rotating fernet
> keys appear trivial for the benefit of securing a service that we
> already trust with our tokens.
> 
> As this has such far reaching implications throughout openstack i would
> like outside input on whether the risks are worth the reward in this
> case, and what we would need to do to secure a deployment like this.
> 
> Please comment here and on the spec.
> 
> 
> 
> Thanks,
> 
> Jamie
> 
> 
> 
> [1] https://review.openstack.org/#/c/317266/
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: