-
Notifications
You must be signed in to change notification settings - Fork 325
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
Feature/ldap kerberos configuration #290
Feature/ldap kerberos configuration #290
Conversation
Looks good, 👍 Also great that you added docs! But before I approve, could you add/do following things:
|
It seems some of your tests are failing. |
They run locally with The actual reason was a copy paste error. |
Now it fails with some error that I do not know what it means: testing.go:640: Step 0 error: Missing newline after argument: On /tmp/tf-test872870681/main.tf line 35: An argument definition must end with a newline. |
Well these are tests that are ran against local keycloak. You should at least run the tests that test the logic you have changed. Looking at the error you posted above, it might have to do with test input format... |
use_kerberos_for_password_authentication = %t | ||
allow_kerberos_authentication = %t | ||
key_tab = %s | ||
kerberos_realm = %s |
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 the issue with the failing tests is that all of the string parameters aren't surrounded in quotes. Take a look at line 706 for an example.
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.
You are obviously right, sir! :)
LGTM code-wise. From a usability perspective, I'm wondering if it would make more sense to group the kerberos related attributes into its own block. This can help separate the kerberos config from the rest of the ldap federation config, and it can allow you to correctly set required attributes if you want to enable kerberos support. When you look in the GUI, there's a switch for enabling kerberos, and when it's enabled, the realm, server principal, and keytab are all required. So we want to make sure that when the user wants to enable kerberos, that those fields are required. However, we can't make them required in the schema because not everyone wants to use kerberos. So I think the solution should be to add So in HCL it might look like this: resource "keycloak_ldap_user_federation" "ldap_user_federation" {
// other config
kerberos { // by specifying this block, `allow_kerberos_authentication` is assumed to be true
server_principal = "HTTP/keycloak.local@FOO.LOCAL" // required
use_kerberos_for_password_authentication = false // optional
key_tab = "/etc/keycloak.keytab" // required
kerberos_realm = "FOO.LOCAL" // required
}
} What do you think about this? If you'd like to take a stab at refactoring this, here's an example of another resource that has a subschema like the one I was talking about: https://github.com/mrparkers/terraform-provider-keycloak/blob/master/provider/resource_keycloak_openid_client.go#L128-L151 |
That sounds reasonable. I will have a look at it this weekend. |
…rmind/terraform-provider-keycloak into feature/ldap_kerberos_configuration # Conflicts: # provider/resource_keycloak_ldap_user_federation_test.go
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.
looks good, nice work!
Hi,
I have added fields for kerberos authentication to the LDAP federation resource.
They were missing and we are using them in our scenario.
Please tell me if there are any problems with the code.
I also added docs for the new properties.
Kind Regards
Jochen