Do the SCIM userName and email properties have to match when adding a user in Okta?

[uncvrd]

Hi again! Been looking in to integrating Directory Sync and ran in to an issue testing SCIM with Okta...

I ran through the tutorial guide in the documentation and did the following:

1. Created a user

The user was inserted in to my application and jackson_store

2. Removed a user

The user was marked as active: false in jackson_store per the Okta docs, and was removed from my application correctly. So far so good.

3. I tried to re-add the same user

This is where things get weird... It looks like Okta (or Boxy) first initiates a GET search() to find any existing users in jackson_index with a db filter set to userName = [USERNAME] which should find my existing user but instead returns an empty list.

Which then means Okta (or Boxy) sends a POST request to create a new user. However I get a 409 "User already exists" error since the user was already in my database of course...but the search failed to find my user causing the POST to run.

What I discovered in the source code was that when Boxy first inserts a user it creates a unique hash using a combined value separated by a colon of directoryId:email that is used in jackson_store/index key column like dsync:users:1:foundry:b67e40ffad3c33ea2eee36c686124f0159c32707...BUT the search() listed above queries on directoryId:userName. So my key instead looks like this dsync:users:1:foundry:3942666b062c6ac16e2142c5fd24a5b4101a3d80 Which means that if your userName and email are different then when that search is run to find existing users it will fail since the hash digest will be different.

---

So my question is, do these properties need to be the same value to work or should the create/search methods be updated to query/create a digest on the same property?

I don't know if I hit an edge case using Okta because when I registered for an account it created a user that I've been testing with that has a different userName than email.

Here's where the digest is generated from the email when creating a user

jackson/npm/src/directory-sync/scim/Users.ts

Line 51 in 8bba503

value: keyFromParts(directoryId, email),

Here is where the digest is generated from the userName when searching for a user

jackson/npm/src/directory-sync/scim/DirectoryUsers.ts

Line 148 in 8bba503

const { data } = await this.users.search(filter.split('eq ')[1].replace(/['"]+/g, ''), directoryId);

Which is used when we have a request that looks like:

@foundrydev/trpc-web:dev: {
@foundrydev/trpc-web:dev:   method: 'GET',
@foundrydev/trpc-web:dev:   body: undefined,
@foundrydev/trpc-web:dev:   directoryId: '032100e6-5db6-48de-88a9-87a2348b7849',
@foundrydev/trpc-web:dev:   resourceId: undefined,
@foundrydev/trpc-web:dev:   resourceType: 'users',
@foundrydev/trpc-web:dev:   apiSecret: 'REDACTED',
@foundrydev/trpc-web:dev:   query: {
@foundrydev/trpc-web:dev:     count: 100,
@foundrydev/trpc-web:dev:     startIndex: 1,
@foundrydev/trpc-web:dev:     filter: 'userName eq "uncvrd@github.oktaidp"' <------- THE IMPORTANT BIT
@foundrydev/trpc-web:dev:   }
@foundrydev/trpc-web:dev: }

Hopefully this question makes sense, let me know if I can provide any more information!

[deepakprabhakara]

@uncvrd Thanks for reporting this. Let me check, I think we only allow getting a record by email and not userName.

[deepakprabhakara]

@uncvrd If you use email instead of userName in the filter then this should avoid the mismatch. The reason we chose to use email over userName internally as the identifier is because there is a big mismatch in the way different providers handle the userName. Also the userName doesn't match up with SSO and email is the only sane bridge across the two. We will update documentation to reflect this. If you absolutely need the userName we will have to look at indexing the users with this info, please let me know.

[uncvrd]

@deepakprabhakara Totally understand that...my question is, I dont think I have control over that HTTP GET request that creates that filter request, do I?

For example I receive an HTTP request with a filter parameter already populated, which I create a DSync request object from:

    const request: DirectorySyncRequest = {
        method: method as string,
        body: body ? JSON.parse(body) : undefined,
        directoryId: params.directoryId,
        resourceId: params.resourceId,
        resourceType: params.resourceType.toLowerCase(),
        apiSecret: extractAuthToken(headers),
        query: {
            count: query.count ? parseInt(query.count) : undefined,
            startIndex: query.startIndex ? parseInt(query.startIndex) : undefined,
            filter: query.filter, // <---- this is pulled from the query params of a GET request from my registered DSync endpoint
        },
    };

Which results in something like this:

@foundrydev/trpc-web:dev: {
@foundrydev/trpc-web:dev:   method: 'GET',
@foundrydev/trpc-web:dev:   body: undefined,
@foundrydev/trpc-web:dev:   directoryId: '032100e6-5db6-48de-88a9-87a2348b7849',
@foundrydev/trpc-web:dev:   resourceId: undefined,
@foundrydev/trpc-web:dev:   resourceType: 'users',
@foundrydev/trpc-web:dev:   apiSecret: 'REDACTED',
@foundrydev/trpc-web:dev:   query: {
@foundrydev/trpc-web:dev:     count: 100,
@foundrydev/trpc-web:dev:     startIndex: 1,
@foundrydev/trpc-web:dev:     filter: 'userName eq "uncvrd@github.oktaidp"' 
@foundrydev/trpc-web:dev:   }
@foundrydev/trpc-web:dev: }

For context, here is my whole endpoint for GET/POST/PUT /scim/v2.0 in Fastify

    fastify.all("/:directoryId/:resourceType/:resourceId?", async function (request, reply) {

        const { directorySync } = await jackson();

        // Handle the SCIM API requests
        const dsyncRequest: DirectorySyncRequest = {
            method: request.method as string,
            body: request.body ? JSON.parse(request.body) : undefined,
            directoryId: request.params.directoryId,
            resourceId: request.params.resourceId,
            resourceType: request.params.resourceType.toLowerCase(),
            apiSecret: extractAuthToken(request.headers),
            query: {
                count: request.query.count ? parseInt(request.query.count) : undefined,
                startIndex: request.query.startIndex ? parseInt(request.query.startIndex) : undefined,
                filter: request.query.filter,
            },
        };

        const { status, data } = await directorySync.requests.handle(dsyncRequest, handleEvents);

        return reply.status(200).send(data);
    });

Okta is only sending one GET request for userName before attempting to POST a new user. The issue is that the new user's hash digest is created from their email (which is totally fine)....but the only query that is sent before creating a user is using the digest from the userName so the user is not found if the user's email is different than their username

[devkiran]

By default Okta checks that the User object exists on the SCIM server through a GET method request with the filter=userName eq "${userName}" query parameter.

You can choose which attribute to use as the unique identifier:

• Go to your SCIM app in Okta.
• Click "Sign On"
• Update "Application username format" to "Email"

Then the query parameter to determine if the user exists becomes filter=userName eq "${email}".

The filter must check an attribute that is unique to all users in the profile.

Please check if this works for you.

[uncvrd]

@devkiran hey! yes i was just messing around with this and was going to share that you can change the username format to use "Email" instead. This does work. so I guess the only thing that would need an update is to clarify this in docs like Deepak had mentioned doing. Thanks guys for the guidance!

[deepakprabhakara]

Thanks @uncvrd