Upgrade to 13.0.2 causes updateUser API to fail from attribute being mastered by a different system

[tiffanykawailee]

Describe the bug?

We did an SDK upgrade from version 8.2.1 to 13.0.2 recently. Everything looked fine in our QA environments, until it reached production where some of API calls to the updateUser started to fail. The call is for users who are managed by an external IdP, but the field is owned by Okta.

https://developer.okta.com/okta-sdk-java/apidocs/com/okta/sdk/resource/api/UserApi.html#updateUser(java.lang.String,com.okta.sdk.resource.model.UpdateUserRequest,java.lang.Boolean)

It fails with the following error:
com.okta.sdk.resource.client.ApiException: {"errorCode":"E0000023","errorSummary":"Operation failed because user profile is mastered under another system","errorLink":"E0000023","errorId":"oaeNsYuWPZ3R5OmTscHI874sQ","errorCauses":[]}

However, the field is actually managed by Okta, as confirmed by support. It seems as if all of the fields are being sent, including null and empty fields, which causes an attempted update for a field we don't want.

But, to make matters a bit more complicated, this only happens in our production environment and we were unable to reproduce this in non-prod.

What is expected to happen?

The update is expected to go through for an Okta managed field, instead of failing with the managed error. This should be consistent in all of our environment (our code is the same).

What is the actual behavior?

It fails with
com.okta.sdk.resource.client.ApiException: {"errorCode":"E0000023","errorSummary":"Operation failed because user profile is mastered under another system","errorLink":"E0000023","errorId":"oaeNsYuWPZ3R5OmTscHI874sQ","errorCauses":[]}

Reproduction Steps?

Here's our code. The request is sent to a user managed by an external IdP. I have a support case open if you need additional information about our IdPs and settings.

  public void setNeedsPasswordVerification(
      final String pUsername, final boolean pNeedsPasswordVerification) throws SvcException {
    final UpdateUserRequest updateUserRequest = new UpdateUserRequest();
    final UserProfile userProfile = new UserProfile();
    userProfile
        .getAdditionalProperties()
        .put(NEEDS_PASSWORD_VERIFICATION, pNeedsPasswordVerification);
    updateUserRequest.setProfile(userProfile);
    updateUser(updateUserRequest, pUsername);
  }

  private User updateUser(final UpdateUserRequest pUserUpdateRequest, final String pUsername)
      throws SvcException {
    final User oktaUser =
        getUserByUsername(pUsername)
            .orElseThrow(() -> new SvcException(OktaErrorCode.USERNAME_NOT_FOUND));
    return updateUser(pUserUpdateRequest, oktaUser);
  }

  private User updateUser(final UpdateUserRequest pUpdateUserRequest, final User pOktaUser)
      throws SvcException {
    try {
      return _userApi.updateUser(pOktaUser.getId(), pUpdateUserRequest, false);
    } catch (final ApiException e) {
      throw new SvcException(OktaErrorCode.getSvcErrorCode(e), e);
    }
    }

Additional Information?

the case i'm referring to is Case 01947956

Java Version

openjdk 17.0.9 2023-10-17
OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode)

SDK Version

13.0.2

OS version

Darwin M-QP32XFY4LN 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000 arm64

[arvindkrishnakumar-okta]

@tiffanykawailee Thanks for submitting this!

This sounds more like an environment related issue to me from initial analysis.

Sounds like the user is imported from or assigned to an app with "profile mastering" enabled (app feature), and is thus read-only. The UI will tell you if a user is Okta sourced or if it's mastered by an app - see https://support.okta.com/help/s/article/How-to-determine-if-a-user-is-profile-mastered-by-Okta?language=en_US

[tiffanykawailee]

Hello! The users have profile mastering, but the thing is that the field isn't mastered by that profile, which means it should be updated.

This update worked in previous versions, but not our current one. Additionally, other users mastered by another profile worked just fine for the update, which to me indicates some sort of bug with the SDK for a certain edge case. Is it possible for you to investigate it? We'd been holding off this update, and okta support sent me here for the SDK team to investigate this further.

[arvindkrishnakumar-okta]

My only concern is that if its a SDK bug, it should affect all your environments and not just the PROD. You mentioned this SDK upgrade worked in your non-PROD environments right? I can investigate this on SDK side from my end, sure but it'd be hard for me to know/reproduce what kind of org settings and feature flags your orgs have and the app settings related to "profile mastering" are configured in your org. Also note that this error is returned by the Okta backend and all the SDK does is to relay it to the user.

[tiffanykawailee]

Is it possible to get the information from Support on Okta (they have our information there)? The reason why we suspect something happening with the SDK is because this only happened post-upgrade, which means some kind of regression happened with the updateUser and possibly more fields were passed along. Again, not sure why it was only observed in prod, which does point to an environment issue, but Okta support told me to open an issue with you because they couldn't find a difference in our environments.

[arvindkrishnakumar-okta]

@tiffanykawailee Thanks, I've found the bug in code. Will fix it and release patch SDK version 14.0.1 soon. Would you be able to upgrade to the 'to-be-released' 14.0.1 version?

[tiffanykawailee]

We should be able to update to 14.0.1. thank you! Are you able to provide any details about why this was only observed in certain environments, or is that related to our configurations?

Additionally -- can you let me know what breaking changes exist from 13 to 14?

[arvindkrishnakumar-okta]

@tiffanykawailee I do not know enough about the environment differences on your end to explain why the behavior should be different in your PROD vs non-PROD environments. Good news is I was able to reproduce this issue in my environment and hence was able to debug this and merge the fix.

Breaking changes would come in to picture while upgrading from 13.x to 14.x (see release notes for the list of changes).

In order to minimize your effort now, I would release a patch version 13.0.2 shortly. You should be able to easily upgrade to 13.0.2 to get past this issue.

[arvindkrishnakumar-okta]

13.0.3 has just been released with the fix.

Please feel free to reopen issue if you have any followups.