-
Notifications
You must be signed in to change notification settings - Fork 48
Adds support to create users with credentials #334
Adds support to create users with credentials #334
Conversation
vijetm
commented
Nov 14, 2019
•
edited
Loading
edited
- Create user with password and recovery question/answer
- Added a new test to check for credentials update
@quantumew - I have tested the config manually, but haven't run the acceptance tests. Is there a way to run a single acceptance test? |
@vijetm try |
okta/resource_okta_user.go
Outdated
} | ||
|
||
if recoveryQuestion != "" { | ||
uc := &okta.UserCredentials{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just found a bug in this code where recovery_question
isn't being set for a user. Will fix it.
Will also need to update the tests to check if it is set. Sorry for this half-baked PR. :|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries at all. Thanks for the contribution. I will wait to review it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@quantumew - I have fixed the bug and tested it. Also ran the user resource related acceptance tests. Review when you can.
47162f5
to
ab261cb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @vijetm thanks for your update! Just a few things to address, thanks!
"password": &schema.Schema{ | ||
Type: schema.TypeString, | ||
Optional: true, | ||
Description: "User Password", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want this to be Sensitive: true
. Can we also make it clear in the docs and description that this WILL be stored in plain text in state?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It also looks like these properties are set on create only. Can we make that clear? "User's initial password. This value cannot be updated."
Technically these should be ForceNew: true
if they can only be set on create. We should warn of that in the description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, okta has an API that allows you to update a user's password. The go lang SDK also has an API to do this - https://github.com/okta/okta-sdk-golang/blob/master/tests/integration/user_test.go#L237
Would we still need the ForceNew: true
flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh coolio, no in that case we would just need to update our update function and support that. Hopefully I am reading this diff right, I am only seeing this logic in resourceUserCreate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you're reading it right. 😄
I will update the resourceUserUpdate
function as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe I've addressed all your concerns. Take a look.
okta/resource_okta_user.go
Outdated
recoveryQuestion := d.Get("recovery_question").(string) | ||
recoveryAnswer := d.Get("recovery_answer").(string) | ||
|
||
if recoveryQuestion != "" && len(recoveryAnswer) < 4 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be done via a ValidationFunc in the schema attribute.
userBody := okta.User{ | ||
Profile: profile, | ||
Credentials: uc, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be cleaned up a bit, no need to instantiate the struct twice
uc := &okta.UserCredentials{
Password: &okta.PasswordCredential{
Value: password,
},
}
if recoveryQuestion != "" && len(recoveryAnswer) >= 4 {
uc.RecoveryQuestion := &okta.RecoveryQuestionCredential{
Question: recoveryQuestion,
Answer: recoveryAnswer,
}
}
okta/resource_okta_user_test.go
Outdated
@@ -233,6 +234,17 @@ func TestAccOktaUser_updateAllAttributes(t *testing.T) { | |||
resource.TestCheckResourceAttr(resourceName, "email", email), | |||
), | |||
}, | |||
{ | |||
Config: minimalConfigWithCredentials, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we add the ForceNew
this will actually recreate this resource and test the create logic.
46fdc6e
to
cf8ef86
Compare
cf8ef86
to
4d300d4
Compare
okta/resource_okta_user.go
Outdated
Type: schema.TypeString, | ||
Optional: true, | ||
Sensitive: true, | ||
ValidateFunc: validation.StringLenBetween(8, 1000), // Hope no one uses password > 1000 chars |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default okta password length is 8. Users can change their policy to 4 characters, but I think it's good to enforce the 8 character minimum limit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can just remove this validation imo. I definitely strongly recommend longer passwords, but if it is possible to have shorter or longer passwords in Okta, let's let them do that.
Sensitive: true, | ||
ValidateFunc: validation.StringLenBetween(4, 1000), | ||
Description: "User Password Recovery Answer", | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can either of these be updated? If so should we include them in the update logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, they can be updated. Let me include them in the update logic. Thanks for catching!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update. Just a few small comments/questions. Can you run make fmt
and commit the change?
9732d9d
to
6880f8e
Compare
RecoveryQuestion: rq, | ||
} | ||
|
||
_, _, err := client.User.ChangeRecoveryQuestion(d.Id(), *nuc) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@quantumew - The recovery credentials update doesn't seem to work in my test environment. Okta APIs don't throw an error but the credentials are not updated in the user account. (Password is updated, but recovery question/answer is not). Trying to debug the issue. Don't merge this yet.
@quantumew - N00b question: Where can I see the statements printed using |
@vijetm I recommend delve with breakpoints but if you are not feeling like you need that, then just |
@quantumew - After some debugging, I see that the call to change recovery credentials isn't being routed to okta. I also notice that you're still using |
@vijetm That version might be misleading. Notice the replace directive at the bottom. Our fork should be up to date with the latest SDK, maybe one patch version behind. If you set |
@quantumew - I see the call being made now. A previous password change test was failing which caused the next call to not execute. |
6880f8e
to
6270b93
Compare
examples/okta_user/all_attributes.tf
Outdated
@@ -31,4 +31,5 @@ resource "okta_user" "test" { | |||
title = "Director" | |||
user_type = "Employee" | |||
zip_code = "11111" | |||
password = "Abcd1234" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had to add the password
variable to all setup files in examples/okta_user
directory, as update tests would fail.
This is because in the update test, the user should have a previous password to update the current password. If not, okta api returns an error. I don't know if you prefer this, but another way is to probably have a separate method/test to check for password update. I thought this was easier, not sure if cleaner though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we keep this test case separate? Just create another password specific test case? That way we can keep all of these existing test cases as is. I want to be sure all of the old tests pass as is (no passwords changed or set) while also testing the new functionality.
@quantumew - Did you get a chance to run the acceptance tests? Let me know if you want me to run them locally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.