Open Stack

I was having an issue extending the expiration on unscoped and
tenant/project scoped tokens retrieved with an existing token. I now
realize this is a feature, not a bug, but I've got some points to argue
that extending token expiration when getting a new token with an existing
one (renewal), is worth considering. Maybe as on option with a cap on
maximum renewal time.

Problem (as state before I realized this was a feature):

When I "renew" an unscoped token using an existing unscoped token, a new
token (access.token.id is different) is issued, but the expiration is
always the same as the first unscoped token that was returned on
authentication with a username and password. I expected the expiration to
extend with each new token, but this only seems to happen when an unscoped
token is retrieved by authenticating with a username and password, not when
an existing unscoped token is used to authenticate the request for a new
token.

Tenant/project scoped tokens, similarly, always return the expiration from
the unscoped token used to retrieve them. Since any unscoped tokens can't
get an updated expiration, the problem extends here.

I have an application where the user enters their username and password
once, and whenever a token is used, I mark it "dirty" so it is "renewed"
within 30 seconds. This way they don't have to re-login until they haven't
performed any actions for the ~1 hour expiration time Keystone grants. Now
clearly the expiration time is not moving ahead with these "renewals", so
it doesn't work as intended, and that leads me to seek some remedy. Storing
a username and password in browser local storage/cookies, or multiple on a
server that relays browser requests to api endpoints, would open a can of
worms.

Reasons to reconsider the expiration policy:

It looks like expiration is done this way to limit the damage from stolen
tokens, but if a token were stolen, it could be stolen from the same
location a username and password will now have to sit, to get around having
to re-supply them manually once an hour. Yes, forcing re-auth hourly with a
username and password, at the Keystone level, can limit damage if any of
the core Openstack services are compromised for the mass theft of tokens.
But limited damage will depend just as much on how quickly the compromise
is detected. The more time an attacker has in the system, the less his
actions will be hampered by a lack of token renewals. VMs can be
compromised, and data exported or destroyed given just a small window.

On the other hand, if a user facing application, or a long running service
supporting one, needs the API and is to remain convenient, they have to
store usernames and passwords. Sometimes that long running service is
connected to the outside world and faces security threats, such as when
relaying Openstack API requests to their respective internal network
endpoints - similar to what Horizon does. I wonder if I use Horizon
continuously, whether it will force me to manually re-authenticate hourly,
and if not, how it is getting around this problem, with or without storing
the username and password.

I suspect it is more probable to button up security closer to the core of
Openstack, rather than relying on many third party API consuming
apps/services to secure even more compromising credentials. Perhaps effort
could be put into auditing for atypical mass token renewal events, like a
sudden increase, or accumulating rate of renewal requests in proportion
with the number of tokens streamed into compromised state.

Allowing a maximum of 3 hours, in 1 hour renewal increments via Keystone,
and making that configurable, would be a good compromise for user/outside
facing apps/apis. Reducing temptation to adopt the security burden of
storing usernames and passwords, especially on a server exposed to the
outside or in storage that is outside (cookies & local storage), could
itself be a security boon.


For now, my application will force manual username and password re-auth
hourly, rather than letting idle time determine expiration by opting to
store username/password credentials, but it doesn't feel user friendly.

Lindsay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151117/d29a9c47/attachment.html>