Ability to pick different claim for Jitsi Meet User Name

[Viajaz]

Is your feature request related to a problem? Please describe.
Cannot change the default Jitsi Meet meeting user name away from userInfo.preferred_username

Describe the solution you'd like
The ability to specify which claim, via environmental variable, to use as context.name besides userInfo.preferred_username, it might also be useful to change scope via environmental variable for this purpose too. I believe context.name is what it used as the default Jitsi Meet meeting user name? That is what I wish to change here.

Describe alternatives you've considered
Using a custom Keycloak client scope mapper to redefine preferred_username but I think this would be better done on the adapter side.

Additional context

[emrahcom]

Hi @Viajaz,

There are a lot of options for the token payload and it is not very flexible to cover all options by using environment variables in my opinion. Therefore I put this code block in a seperate file (context.ts) to allow customizations by editing its codes.

You may edit this file as you wish. If you run jitsi-keycloak-adapter in a container environment, you may mount your customized context.ts.

[Viajaz]

Well, the idea would be to specify the name of the claim in said environmental variable (eg: KEYCLOAK_NAME_CLAIM = name or preferred_username). By overriding context.ts manually the solution becomes harder to update the container automatically than it already is as we've basically forked it at that point.

Maybe something like:

config.ts

export const KEYCLOAK_NAME_CLAIM= Deno.env.get("KEYCLOAK_NAME_CLAIM") || "preferred_username";

context.ts

// appropriate imports for config
// ...
name: userInfo[KEYCLOAK_NAME_CLAIM] || "preferred_username"
// ...

[emrahcom]

Hi @Viajaz, I tested your suggestion and it works but I still want to keep context.ts as it is because this simple script is here to allow customizations. It's very important to keep it very simple and straightforward to help people update it easily.

Best regards

[Viajaz]

That's a shame to hear, optional features that can be ignored shouldn't add complexity for simple use-cases and, for those that do need this functionality, overriding context.ts creates more fragility and overhead which creates complexity. I would also think that using environment variables is more simple for simple-use cases than someone changing a TypeScript file.

If I have this setup with Watchtower or other autoupdate mechanism, and the core structure of context.ts changes in the future, it'll break the container, the use of environmental variables is a much nicer and cleaner interface between configuration and the app.