I’m currently working on configuring our Okta setup and need some advice on a specific issue related to Universal Directory (UD) configurations for Single Sign-On (SSO) applications.
We’re aiming to set up separate UDs for each of our applications, such as RED and SEL that uses OKTA as SSO. The goal is to enable these applications to store their custom user attributes independently, without relying on a shared UD. This is important for us to keep attribute storage distinct and well-organized for each application.
I would appreciate any insights or recommendations on the best practices for achieving this within the Okta framework. Specifically, how can we efficiently set up independent UDs for each application (RED, SEL) that uses Okta as SSO?
FYI I teach for Okta education, so I am always encountering scenarios like this.
I’ll need some more information first. I’m guessing from your description that these two applications are not workforce identity but customer facing (CIAM, or customer identity access management). Is that correct? And if so, why did you settle on the Okta engine instead of the Auth0 engine where we steer folks for CIAM? (I work for the Auth0 side too, now it’s CIC, or customer identity cloud).
My second question is going to be, what attributes are you planing on saving? I say this because unless the attributes are specifically related to the customer’s identity, AND are shared across multiple applications, then they don’t really belong in the IAM database. Don’t treat the IAM as a place to stuff information in lieu of an application database. If RED and SEL are both environments with multiple applications that require SSO to move between them, then OK it may be appropriate.
The third question is, I read this as you want SSO across RED and SEL. Is that correct? I will say if true, then profile would be missing attributes when the user landed on one of those applications. That warrents more discussion
