Registration | Company Name Change Not Reflecting Consistently

[dhiren-singh-007]

Current Behavior

When inviting a Business Partner in CX Admin, the initial Company Name (e.g., ABC) was specified. However, during the company registration process via the access link provided in the invite email, the Company Name was changed to (e.g., XYZ). Despite the change being reflected correctly on the Business Partner invite page within CX Admin, it does not update uniformly on the company user side, where the original Company Name (ABC) remains visible when accessed through the user icon.

Additionally, the Company Name remains unchanged on the Catena-X Home Page.

Expected Behavior

The Company Name displayed on the company user side should reflect the latest change made during the registration process. In this case, it should display "XYZ" after the Business Partner updates it during registration.

Steps To Reproduce

1. Log in to CX Admin and initiate an invite for a Business Partner.
2. Specify Company Name as "ABC" during the initial invite setup.
3. Send the invite email containing access details to the Business Partner.
4. Business Partner accesses the registration link from the email and changes the Company Name to "XYZ" during the registration process.
5. Verify on the CX Admin side:
6. Check the Business Partner invite page in CX Admin. Note that the Company Name displayed reflects the change to "XYZ".
7. Verify on the company user side:
8. Click on the user icon associated with the invited Business Partner.
9. Observe that the Company Name displayed remains "ABC", instead of updating to "XYZ" as expected.
10. Verify on Catena-X Home Page.

Example screenshots:

1. Company invited as Neha -Email Template

2. On submit registration company name changed to Müller as shown

3. Now when company go to select company name in login screen , Central idp is still showing old company name

4. Now company admin logged and open User icon as shown , it is still showing old company name

RCA : Old Company name is coming from display name and Organization mapper attribute which is part of IDP of that specific company.

[dhiren-singh-007]

Hi @ntruchsess @Phil91 if you have any idea or suggestion for this fix , please share.

My idea is to get the Id provider and changes the display name and then update it again. and same thing with Organization mapper in IDP . And then i will call this code only if there is any deviation in Invitation name and user input for Organization name in Submit api during registration.

[Phil91]

@dhiren-singh-007 in my opinion adding the calls to update the organisation for the users of the company and a call to update the org name on the shared idp should be fine, since they are only updates, if it fails while updating retriggering the api is just fine.

[dhiren-singh-007]

@dhiren-singh-007 in my opinion adding the calls to update the organisation for the users of the company and a call to update the org name on the shared idp should be fine, since they are only updates, if it fails while updating retriggering the api is just fine.

Thanks @Phil91 , I am not sure if i understood your point completely. But i think this data is coming from Central IDP On login page company name is showing from the Display name as shown

And in Portal This is showing from token attribute "Organisation" which is defined via Mapper attribute in Identity provider for specific company as shown

Eg: Lets say one user changed the company name and saved the address during registration and didn't continue further . Now when user will come again then that user will still see the old company name on login page. Because of this this i am thinking that we have to make this call on central IDP in this api POST: application/{applicationId}/companyDetailsWithAddress So that user will always see updated data.

I am thinking something like this for company name and same way for attribute mapper (most probably in this method only). And then call this in the above api. I am not sure which file i should add this code but i am still analyzing.

    public async Task UpdateCompanyNameIdentityProviders(string aliasName, string organisationName, CancellationToken cancellationToken)
    {
        var keycloak = _keycloakFactory.CreateKeycloakClient("central");
        try
        {
            var identityProvider = await keycloak.GetIdentityProviderAsync(_settings.CentralRealm, aliasName, cancellationToken).ConfigureAwait(ConfigureAwaitOptions.None);

            identityProvider!.DisplayName = organisationName;
            await keycloak.UpdateIdentityProviderAsync(_settings.CentralRealm, identityProvider!.Alias, identityProvider, cancellationToken).ConfigureAwait(ConfigureAwaitOptions.None);
        }
        catch (Exception ex)
        {
           throw ex;
        }
    }

Please share your thoughts

[dhiren-singh-007]

adding @MaximilianHauer

[Phil91]

@dhiren-singh-007 in my opinion adding the calls to update the organisation for the users of the company and a call to update the org name on the shared idp should be fine, since they are only updates, if it fails while updating retriggering the api is just fine.

Thanks @Phil91 , I am not sure if i understood your point completely. But i think this data is coming from Central IDP On login page company name is showing from the Display name as shown

And in Portal This is showing from token attribute "Organisation" which is defined via Mapper attribute in Identity provider for specific company as shown

Eg: Lets say one user changed the company name and saved the address during registration and didn't continue further . Now when user will come again then that user will still see the old company name on login page. Because of this this i am thinking that we have to make this call on central IDP in this api POST: application/{applicationId}/companyDetailsWithAddress So that user will always see updated data.

I am thinking something like this for company name and same way for attribute mapper (most probably in this method only). And then call this in the above api. I am not sure which file i should add this code but i am still analyzing.

    public async Task UpdateCompanyNameIdentityProviders(string aliasName, string organisationName, CancellationToken cancellationToken)
    {
        var keycloak = _keycloakFactory.CreateKeycloakClient("central");
        try
        {
            var identityProvider = await keycloak.GetIdentityProviderAsync(_settings.CentralRealm, aliasName, cancellationToken).ConfigureAwait(ConfigureAwaitOptions.None);

            identityProvider!.DisplayName = organisationName;
            await keycloak.UpdateIdentityProviderAsync(_settings.CentralRealm, identityProvider!.Alias, identityProvider, cancellationToken).ConfigureAwait(ConfigureAwaitOptions.None);
        }
        catch (Exception ex)
        {
           throw ex;
        }
    }

Please share your thoughts

@dhiren-singh-007 you're right, the proposed method looks good for me. what is still missing in my opinion is a method to change the user attribute for all users that are assigned to the company:

[MaximilianHauer]

adding @oyo

[oyo]

Currently in the rename process only the DB records are updated not the Keycloak realm and display name. On frontend side we are showing the user data from the Keycloak token which contains the original company name. We could trigger another call to the backend after each login but it would be way more efficient to fix the data in the one rename API call with one Keycloak API call from BE to BE instead of one additional call from FE to BE in every user session.

[dhiren-singh-007]

@dhiren-singh-007 you're right, the proposed method looks good for me. what is still missing in my opinion is a method to change the user attribute for all users that are assigned to the company:

yes , i missed that point . Thanks for highlighting it. Yes then i think high level there would be three function as follows:

1. Call to update display name of IDP in Central Idp .
2. Call to update Organization Attribute of IDP in Central Idp.
3. Call to update all user's Organization attribute in Central IDP.

Now i will start working on this.

[dhiren-singh-007]

Hi @Phil91 , While implementing the solution, I found that the 3rd point is not needed. This is because when the Organization attribute of an Identity Provider (IDP) is updated in the central IDP, Keycloak triggers an internal event whenever a user associated with that IDP logs in. This event automatically updates the user’s attributes, including the Organization attribute, after their login.

[Phil91]

Hi @Phil91 , While implementing the solution, I found that the 3rd point is not needed. This is because when the Organization attribute of an Identity Provider (IDP) is updated in the central IDP, Keycloak triggers an internal event whenever a user associated with that IDP logs in. This event automatically updates the user’s attributes, including the Organization attribute, after their login.

@dhiren-singh-007 do you know if this is a specific keycloak configuration or if this is a base setup?

@evegufy what's your opinion on that, should we rely on the fact that keycloak might be configured to handle this or do it in the code?

[dhiren-singh-007]

@Phil91 : yeah i just checked and i think this is the configuration . IMO we can keep this always in force because if number of users are large then portal BE will have lot of network calls to update user attribute. Also i am not sure if this is the basic setup or not . @evegufy might know it.