Hi, Cedric. >we do not want the application to be aware of the username of our users (for confidentiality reasons) in any way (neither in the token nor anywhere else - we will be using OIDC). >Is there any way to do that? Yes, this can be done by employing [dynamic scopes](https://gluu.org/docs/ce/admin-guide/custom-script/#dynamic-scopes). You can write a script which will decide which claims to release for this scope on per user basis. >In the 'Manage Authentication' page, it seems we can only specify one primary key. Or maybe it's in the cache refresh config? (it looks like we can add more than one key attribute) Didn't get how this is related to the first part. Could you elaborate, perhaps?

``` username attribute and another subset of users with another attribute that is NOT the username. ``` I think they are going to have to use a custom script. The scopes would only help after the person has been authenticated. What about this [basic-multi_login script](https://github.com/GluuFederation/oxAuth/tree/master/Server/integrations/basic.multi_login) It's an unofficial script, but it probably will give an idea how to go about it.

> I think they are going to have to use a custom script. The scopes would only help after the person has been authenticated. Indeed, that was my first guess. We will look into this script. Thanks !

The Michael is correct, if your goal is to prevent leakage of those usernames even to Gluu Server itself, the only way is to customize some authentication script. I first thought you need only to prevent their leakage to some 3rd-party app accessing Gluu Server via OIDC. Answering your previous question: >In the 'Manage Authentication' page, it seems we can only specify one primary key. Or maybe it's in the cache refresh config? (it looks like we can add more than one key attribute). You can only specify one primary key, this is correct. The only way to use several different attributes for authentication is a script like Michael referenced before. You also will need to make sure a corresponding user entry exists at Gluu, still, as it's requirement posed by its design. If it won't be able to find such entry, authentication will fail, even if credentials' check against backend will be successful. Thus you'll need to configure Cache Refresh in such way it will only pull attributes you are ready to reveal into Gluu Server. This most likely will mean you'll need to write a CR custom script, or add an enrolment/user attributes' update procedures to the script itself. Just one thing you should be aware of, if you can't tolerate usernames of those users to even reach your Gluu instance. If it's some instance you've already used for some time, and even have CR running there, it's very likely those users are already made it to Gluu's inernal user cache, so you may need to do some clean up, and then review your CR configuration. Btw, this ticket is of "Public" type and thus it's visible to everybody. I see 2 slightly different company names associated with Ville de Montreal's tickets, one related to "Community" (non-customer) tickets, the other one to private customer's ticket. You probably need to get in contact with a person on your team who will be able to enlist you as a member of the proper organisation here, on Support portal. This will allow you to create private tickets as well.

> if your goal is to prevent leakage of those usernames even to Gluu Server itself Actually the goal was to prevent leakage only to the RP, we are ok with the Gluu server being aware of the usernames.

Hi, Cedric. I've corrected my previous post a bit (the part about answering your question), I got wrong idea of what you are asking about, sorry. >the goal was to prevent leakage only to the RP, we are ok with the Gluu server being aware of the usernames. Understood. If I got you right, you have one specific RP talking via OIDC to Gluu Server, and, generally, you would like to release a "username" claim to it, but for a certain group of users you want it to be omitted? My usual answer for such case would be filtering with a dynamic scope script (unless there are some other caveats I may not be aware of) Let's wait for Michael's response, I guess, as I may not understand the whole context of it.

> If I got you right, you have one specific RP talking via OIDC to Gluu Server, and, generally, you would like to release a "username" claim to it, but for a certain group of users you want it to be omitted? Yes that's exactly right. I will also correct my 1st post and say that we don't mind the certain group of users to authenticate to the Gluu server with their username as long as this username is not passed in any way to the RP. I thought a way to achieve this would be to use another attribute to authenticate those users but that is not the actual requirement, the real requirement is to not have the username present anywhere in the RP app. Thanks

> I thought a way to achieve this would be to use another attribute to authenticate those users but that is not the actual requirement, the real requirement is to not have the username present anywhere in the RP app. Authentication process is a bit more complex than that with Gluu. First caveat is that it implies that a corresponding local user entry exists as well at Gluu Server. It's achieved by either running CR, or by auto-enrolling users in an authentication script. Then, authentication is separated from the process of serving actual request from RP/SP. Authentication determines which user it is (and sometimes creates/updates its local user entry), but user's attributes are then harvested from LDAP server, according to list of approved scopes/attributes. In such case if you want some attribute "attr1" not be sent to RP, you need to ensure that for this user "attr1" is not present in the first place. This is where authentication script or CR scripts comes into play, if you choose this approach. The other approach is to filter and change on the fly what's actually is being sent to RP - this is done with dynamic scopes. This way you can don't care much about what is saved to Gluu's LDAP and don't need to change your authentication settings.

Hi, Cedric. What other questions do you still have? Can we close this ticket?

Yes you can. Thanks