🔐 Secure your cluster with TLS, numerous authentication backends, data masking, audit logging as well as role-based access control on indices, documents, and fields
I'm currently working on an app that uses OpenSearch and we're looking into supporting multiple login options including allowing the user to configure several OpenID providers, much like you can do in the OpenSearch Security config by providing the openid configuration URL. The issue that I've seen is that the username is taken from whichever claim is specified in the config, however there are a couple of issues there:
None of the claims by themselves are globally unique, the recommendation is to use iss + sub combined, but as far as I can tell you can only use one key to set the username
There's no distinction between the users connected through OpenID and those connected through other methods
I know that using a roles claim would be ideal here, but it's not a mandatory part of the spec. For example the Google OpenID implementation doesn't let you assign roles. In these cases (or in general if we wish to assign a permission from our app rather than the ID provider) we need to create a role mapping using the username collected from the claim.
For me the ideal solution would be some kind of format string to customize username generation. For example:
username_format: openid-{iss}-{sub} in the place of subject_key
would allow you to identify a user as being connected through OpenID using a specific provider and ID
[Triage] Hi @sebovzeoueb, thanks for filing this issue. Going to mark as triaged. Feel free to open a PR with an implementation of your requested feature for review.
I'm currently working on an app that uses OpenSearch and we're looking into supporting multiple login options including allowing the user to configure several OpenID providers, much like you can do in the OpenSearch Security config by providing the openid configuration URL. The issue that I've seen is that the username is taken from whichever claim is specified in the config, however there are a couple of issues there:
iss
+sub
combined, but as far as I can tell you can only use one key to set the usernameI know that using a roles claim would be ideal here, but it's not a mandatory part of the spec. For example the Google OpenID implementation doesn't let you assign roles. In these cases (or in general if we wish to assign a permission from our app rather than the ID provider) we need to create a role mapping using the username collected from the claim.
For me the ideal solution would be some kind of format string to customize username generation. For example:
username_format: openid-{iss}-{sub}
in the place ofsubject_key
would allow you to identify a user as being connected through OpenID using a specific provider and ID