I have integrated WorkspaceONE Access with Okta on test instances of both via SAML. When a user is first provisioned the login works fine, but the when the auth times out the user gets an error:
"Failed to create or update a JIT user."
The documentation says this may be because of a missing SAML assertion attribute. I do not believe anything is wrong with my SAML settings. As stated before, the first login when the user is provisioned in WorkspaceONE works fine. It is only when it comes time to re-auth that this error occurs.
Reconfigure IdP details in Service Provider and try again. Unable to process the Status Code received. There may be multiple reasons for this issue- Authentication failure in IdP or Time mismatch between IdP Server and SP Server. Mostly, Reconfigure the IdP and SP details in both IdP and SP should solve the issue.
I will try this, but nothing seems to be wrong in that regard with the IdP or SP settings. If I delete the JIT catalog being used in WorkspaceONE Access then the user is successfully logged in and the user is created in WorkspaceONE Access.
New users that have not been provisioned yet are able to login fine. It's only when their session times out and they need to re-auth that this issue occurs.
So at the same time an existing user is experiencing this problem, a new user is able to authenticate and be JIT provisioned in WorkspaceONE access without a problem.
This problem is only occurring when the user already exists in the directory.
Exactly the samen issue here but with AzureAD. We have setup a federation last week and things worked just fine. This week nothing but errors for existing users like: "Failed to create or update a JIT user"
Did you manage to figure out and fix the issue?
I have fixed this, but I’m not certain why. My fix was yet again deleting the attached JIT directory in WorkspaceOne to have the users recreated. It seems like the JIT user update may be brittle. It seems like this problem is caused by the SAML assertions being modified after the user has been created.
The error is not what I would expect to happen in this case. I would expect that as long as the field being used as the unique identifier is not changed that a change to the SAML assertion would update the user information upon next login. However, it appears that this has a high chance of breaking auth entirely.
So my recommendation to you would be to confirm one last time that your SAML assertions into W1 Access are correct, blow away the JIT directory, and have those users re-provisioned on login.
