-
Notifications
You must be signed in to change notification settings - Fork 329
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 Keycloak_openid_client_permission for admin_fine_grained_authz #364
Conversation
b71513d
to
7ad056d
Compare
@tomrutsaert could you take a look at this when you have a chance? I'm very unfamiliar with the permissions / policy features within Keycloak. |
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.
Better than what I created: resourceKeycloakIdentityProviderTokenExchangeScopePermission
By looking at this, mine does to many things automatically.
The policy should indeed be created in its own separate resource (and not implictly)
I do not recall why I did it like this....
Remarks:
- I would call the resource in plural: keycloak_openid_client_permissions as that is what it is called in the keycloak UI + it handles more then 1 permission
- I would remove the permission toggle on the keycloak openid client resource and let the fact you have a keycloak_openid_client_permission resource handle the enable/disable call.
- Perhaps add an extra test, to see that the policy was in fact set on the correct permission.
@jermarchand what do you think?
"github.com/mrparkers/terraform-provider-keycloak/keycloak" | ||
) | ||
|
||
func resourceKeycloakOpenidClientPermission() *schema.Resource { |
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.
Should this not plural resourceKeycloakOpenidClientPermissions instead of resourceKeycloakOpenidClientPermission?
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.
Yep, I'll rename this resource.
Type: schema.TypeBool, | ||
Optional: true, | ||
Default: false, | ||
}, |
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.
Is having a resourceKeycloakOpenidClientPermissions which refers the openid client not make this obsolete?
The resourceKeycloakOpenidClientPermissions can never exist when this is false...
I would let the resourceKeycloakOpenidClientPermissions handle the enable of disable of the permissions on the client, just by the fact it exist. You only have to be clearfull that you take this into account when destroying this resource....
Even in keycloak I think the permissions are located in the wrong location. It is really a resource in it own right
What do you think?
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 added permissions_enabled
in resourceKeycloakOpenidClient
to be able to enable / disable permissions independent of the permissions configuration themselves.
We can indeed consider that the presence of resourceKeycloakOpenidClientPermissions
activates the permissions on the client.
To be able to manage its deactivation, I will keep the enabled
parameter in resourceKeycloakOpenidClientPermissions
which with the value false
will delete the resource
return err | ||
} | ||
} | ||
} |
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.
If you agree this would be a part of resourceKeycloakOpenidClientPermissions create method
Type: schema.TypeBool, | ||
Optional: true, | ||
Default: true, | ||
}, |
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.
Does this not conflict with permission_enabled parameter on the keycloak_openid_client?
Perhaps both are even obsolete. Because this resource does not exist if it is disabled.
Steps: []resource.TestStep{ | ||
{ | ||
Config: testKeycloakOpenidClientPermission_basic(realmName, clientId), | ||
Check: testAccCheckKeycloakOpenidClientPermissionExists("keycloak_openid_client_permission.my_permission"), |
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.
Could you add a test that checks that the policy is actually set on the permission?
@tomrutsaert could you take a look at my updates ? |
Looks good to me. |
…eycloak#364) Co-authored-by: Jerome Marchand <prestataire.0121541@ouest-france.fr>
Add on
keycloak_openid_client
the optional optionpermissions_enabled
to enable Fine grained permissions on the client.Add resource
keycloak_openid_client_permission
to manage the policies to apply to each scopes.