Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add logic for using Auth.Period when handling auth login/renew requests #3677

Merged
merged 10 commits into from
Dec 15, 2017

Conversation

calvn
Copy link
Contributor

@calvn calvn commented Dec 12, 2017

I started off with backend changes on approle only, and if the logic looks correct I'll update the other backend that uses period afterwards.

@calvn calvn requested a review from jefferai December 12, 2017 15:29
@@ -518,6 +531,11 @@ func (c *Core) handleLoginRequest(req *logical.Request) (retResp *logical.Respon
auth.Accessor = te.Accessor
auth.Policies = te.Policies

// Set auth.TTL if not set, used below in RegisterAuth
if auth.TTL == 0 {
auth.TTL = tokenTTL
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be set to be the period's value if that's present. Not sure if we want that, or have it set to DefaultLeaseTTL.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tokenTTL should already be the period's value from above if it's present. Actually, I think what needs to happen here is that in all cases we need to set auth.TTL to the tokenTTL value. That will ensure that the expiration manager always uses the correct value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I'll do auth.TTL = te.TTL since these two should be set to the same value.

@calvn
Copy link
Contributor Author

calvn commented Dec 14, 2017

TestTokenStore_RolePeriod and TestTokenStore_Periodic are now failing due to Period being checked against sys/mount MaxLeaseTTL. This suggests that currently Period can be a higher value that the sys/mount's max TTL.

@jefferai
Copy link
Member

@calvn Indeed, but I can't think of a use case for having the period (not total lifetime of the token, just the period) be that long.

@calvn
Copy link
Contributor Author

calvn commented Dec 14, 2017

Likewise. I can change the tests so that they pass, but I am a bit concerned that changing the current behavior might break people's role setup in the cases where they have period > max TTL. Their next token renewal would fail.

@jefferai
Copy link
Member

@calvn shouldn't it simply cap the value rather than fail it? (Ideally with a warning in the response.)

@calvn
Copy link
Contributor Author

calvn commented Dec 14, 2017

Yea it should so we're good here, my bad.

@calvn calvn added this to the 0.9.1 milestone Dec 14, 2017
@calvn calvn merged commit 895cffa into master Dec 15, 2017
@calvn calvn deleted the auth-period-logic branch December 15, 2017 18:30
chrishoffman pushed a commit that referenced this pull request Dec 15, 2017
* oss/master:
  Defer reader.Close that is used to determine sha256
  changelog++
  Avoid unseal failure if plugin backends fail to setup during postUnseal (#3686)
  Add logic for using Auth.Period when handling auth login/renew requests (#3677)
  plugins/database: use context with plugins that use database/sql package (#3691)
  changelog++
  Fix plaintext backup in transit (#3692)
  Database gRPC plugins (#3666)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants