I think, we need to have a fallback. Facility like ESS, would n't have unique_id returned from our OAuth server. In this case, it would be undefined here.

Could you handle this in safe way?

I tested it with and without mapping unique_id from the Auth Server and it works safely.

@gnyiri Hi Thanks for this PR. I have few fundamental questions and more curious about the answers.

1. What Authentication provider are you using, that returns the value unique_id?
2. Is this the standard field(like oidc_sub) from a particular Authentication provider, that other facility can use? How does it differ from the existing oidc_sub?
3. How are you planning to use this new field in the future? - If this field is not very critical w.r.t business logic and just for auditing purpose, we would recommend going for a JSON column in the users table, where we could dump the OAuth userinfo and use it for auditing purpose.

1. unique_id is a custom field created by our registration service (developed by ELI). It is immutable and unique and is assigned to the registered user upon registration. The Auth service (which is not the same as the registration service) will map this field in UserInfo if the user logs in.
2. oidc_sub is a standard field in Oauth2 providers but we do not want to rely on it (due to technical reasons)
3. we are simply using this field so that we can "join" the UOS users table with the users table in the registration service. Currently we are matching the users through email address but this is not ideal as the email addresses can be changed by the user and the email address will not be updated in UOS unless the user logs in into UOS.

I am OK with the JSON approach that could store all auxiliary, locally needed fields in the future.

With JSON will it be possible to enforce database constrains, l am okay with an approach we we may have a generic id that can be used as oidc_sub also.

Thanks for the clarification.

Just curious about the "join" you have mentioned. Is it some DB join that you are doing on outside UOS?

We are currently in the process of cleaning up the users table(PR) and its column to keep it optimised. Hence, any new column should be carefully discussed and evaluated.

I am trying to evaluate the alternative approaches, as I am only a bit concerned about the impact of the new column(unique_id), that could potentially slow down the table(Not on grand scale, but still significant) due to unique indexing.

As i understand, Since you are not going to use oidc_sub, is it possible for you to use the same column for your use case. If so, we can rename the column oidc_sub to something like auth_identifier and use it according to facility's need. I know this would result in writing your own Authentication like STFC, but that should be fine, as you already now have your special use case. Let me know your thoughts about this.

@mutambaraf Agreed. Json is not a fit-in solution here. Thanks.

@yoganandaness : not a real join rather a matching. We have a DB that is a "fusion" of multiple DB-s (UOS, registration, experiments, .etc..). We use this DB for generating reports to the MGMT, e.g. reports showing proposals per affiliation and so on. This unique_id would be needed to be able to match UOS users with the registration DB where the real user data is stored.

In fact, our original idea was to misuse the oidc_sub column for storing our unique_id but not sure if we can force the auth service to encode the unique_id as oidc_sub in user info (and if so what is the side effect). What else we can do is to encode both unique_id and oidc_sub and change UOS code for ELI to store unique_id instead of oidc_sub.

@yoganandaness: renaming oidc_sub to auth_identifier is a good idea. I think that we can move that way.

Thanks for the clarification.

Just curious about the "join" you have mentioned. Is it some DB join that you are doing on outside UOS?

We are currently in the process of cleaning up the users table(PR) and its column to keep it optimised. Hence, any new column should be carefully discussed and evaluated.

I am trying to evaluate the alternative approaches, as I am only a bit concerned about the impact of the new column(unique_id), that could potentially slow down the table(Not on grand scale, but still significant) due to unique indexing.

As i understand, Since you are not going to use oidc_sub, is it possible for you to use the same column for your use case. If so, we can rename the column oidc_sub to something like auth_identifier and use it according to facility's need. I know this would result in writing your own Authentication like STFC, but that should be fine, as you already now have your special use case. Let me know your thoughts about this.