Update `SessionManager` implementation for non-renewable tokens about spring-vault HOT 6 OPEN

I appreciate your suggestion. What is missing in the existing session manager to meet your requirements?

We would rather want to reuse existing infrastructure (also for the reactive side) to avoid introducing additional unrelated complexity.

from spring-vault.

What is missing in the existing session manager to meet your requirements?

Our requirement is to allow regeneration of token (not renewal - because our policy does not allow renewal) in the session manager. If I'm understanding correctly, the current LifecycleAwareSessionManager which gets autoconfigured can only renew (if the token can be renewed), but not regenerate the token. To maintain the current behavior, this feature could be implemented behind a configuration option.

I would be happy to assist with contribution if this is something that would be desired.

from spring-vault.

If I'm understanding correctly, the current LifecycleAwareSessionManager which gets autoconfigured can only renew (if the token can be renewed), but not regenerate the token.

Session managers obtain a new token if the current one is expired. Renewal is attempted until hitting max_ttl. Since I'm not familiar with the actual setup for your tokens, help is appreciated to try out our session managers and report back what is happening vs. what needs to be done to enable your use case.

I could well imagine that if the token isn't renewable, then our renewal scheduler doesn't get activated and therefore, an expired token remains active. With that scenario in mind, we could still enable a background thread to monitor the token. If the token is about to expire, we drop the token and request a new one.

That's similar to what we do now, except that we attempt renewal before we detect whether a token is about to expire.

from spring-vault.

Ah I see, it seems I was misunderstanding. I now see this comment at the top of the LifeCycleSessionManager:

 * If Token renewal runs into a client-side error, it assumes the token was
 * revoked/expired. It discards the token state so the next attempt will lead to another
 * login attempt.

I think the bug here is that the renewal does not get scheduled if the token can't be renewed, therefore the token never gets revoked, and the subsequent request does not regenerate the token/login again. I can confirm this behavior with our application and provide a minimal replicable example, but I think it's pretty clear from the existing session manager code that this is the behavior.

With that scenario in mind, we could still enable a background thread to monitor the token. If the token is about to expire, we drop the token and request a new one.

I think this is a good solution. I'm thinking it could be implemented in a similar way to token renewal - schedule a task to set the current token to Optional.empty() at the lease_duration timeout. Then the next request will regenerate the token. Does that work for you?

from spring-vault.

That sounds straight-forward. We have a few utilities to calculate a point in time when the token is expected to expire with an additional threshold that can drop the token a tad earlier to avoid token usage in the second it is about to expire.

from spring-vault.

Ok, that makes sense, I'm familiar with the configs you mentioned. I'll try to make this contribution soon.

from spring-vault.