Setting up groups and membership

Configure the management agent to import and manage Okta groups and their membership.

Only OKTA_GROUP groups can be written to. BUILT_IN and APP_GROUP groups belong to Okta or to another application, and the management agent will only ever read them.

Step 1: Decide between import-only and management access

With OAuth, grant the service app one of:

• okta.groups.read to import groups and membership without exporting anything

• okta.groups.manage to import, create, update, and delete groups and manage their membership

Membership exports touch both objects, so the admin role needs the group membership permission and the user group-membership permission. Creating the OAuth service app lists them.

Retrieve the MIM schema again after any scope change.

With an API token, MIM always shows the full group schema. Select only what the token's account is permitted to perform.

Step 2: Choose which group types to import

OKTA_GROUP groups are always imported when the group object type is selected.

On the Global Parameters page, add the read-only types if your solution needs them as reference data:

• Include built-in groups imports BUILT_IN groups.

• Include app groups imports APP_GROUP groups, which are created by application and directory integrations.

Both settings change what a full import returns, so run a Full Import and Full Synchronization after changing either.

Step 3: Select the object type and attributes

Select the group object type. id is mandatory. Add name and description if you need the group profile, and type if your connector filters need to tell the group types apart.

Select member only if MIM needs membership. It adds a membership query for every imported group, which on a large tenant dominates the import time.

Step 4: Configure joins and projections

The anchor is the Okta group id, and so is the DN on import.

When MIM provisions a group it supplies its own DN. Use any unique value, such as a GUID. The export returns the Okta id as the anchor and the confirming import replaces the temporary DN with it.

Step 5: Configure outbound attribute flows

MIM can export name, description, and member on OKTA_GROUP groups.

Each member value is the Okta id of a user connector, so the user objects have to be joined or projected before membership will export cleanly. Membership is exported one member at a time, so a large initial membership load is a large number of API calls.

Use connector filters and outbound flow scoping so that BUILT_IN and APP_GROUP groups can never receive an export. Okta will reject the write, and the export will report an error for every affected object.

Step 6: Configure deprovisioning

Stage a connector delete when an OKTA_GROUP group should be removed. Group deletion in Okta is permanent and there is no deactivated state, so only a full import confirms it.

Scope deletion so it can never reach a BUILT_IN or APP_GROUP group.

Step 7: Test

1. Run Full Import and Full Synchronization, and confirm the group types you expected are present.

2. Confirm membership if you selected member.

3. Test group creation and a profile update.

4. Test adding and removing a member.

5. Test deletion last, and only once the connector filters and deprovisioning scoping have been reviewed.

6. Run a confirming import after every export.

If a create reports an error, check Okta before you retry. Exports are not transactional, so the group may have been created even though a later membership assignment failed.