Skip to content

Add support for Okta as SCIM provider

Drew Blessing requested to merge dblessing_okta_scim into master

Fixes

What does this MR do?

Makes minor adjustments to SCIM to support Okta. There are some slight differences between Azure and Okta's payloads.

With these changes, GitLab passes the Okta Runscope tests - both the spec and the CRUD tests.

Any remaining failures in the above tests are just because the test was not as dynamic as Okta itself. Some places where Okta allows an option, the tests are static. This isn't a problem.

The Okta and Azure payloads different when removing/deactivating a user. Namely, Azure uses the path key while Okta does not. RFC7644 Section 3.5.2 "Modifying with PATCH" indicates that path is optional for 'add' and 'replace' operations. So both are compliant with the spec it seems. Here are examples:

Azure:

{
    "Operations": [
        {
            "op": "Replace",
            "path": "active",
            "value": false
        }
    ],
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ]
}

Okta:

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{
        "op": "replace",
        "value": {
            "active": false
        }
    }]
}

Screenshots

Okta Name ID format and username

Screen_Shot_2020-02-20_at_4.49.26_PM

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Drew Blessing

Merge request reports