This component lets Azure AD (Microsoft Entra) provision users to OutSystems ODC using SCIM 2.0. There’s no UI — it works behind the scenes and listens for SCIM requests from Azure to create, update, or deactivate users.

Here’s how to set it up:

1. Install the Component

• Publish the Azure SCIM Server module to your ODC environment.

• Make sure your app is accessible publicly. You’ll need the full HTTPS URL (e.g., https://.outsystems.app) for Azure provisioning.

2. Set Up Site Properties🛠 Get Your ODC API Client ID and Secret

1. In ODC, go to your Users API application (or wherever you're calling /api/identity/v1/users).

2. Under the Service Center > API Clients section, create a new API Client.

3. Copy the generated Client ID and Client Secret — you'll need both for authentication.

Make sure your API Client has permission to call the OutSystems Identity API.
Official API docs here: ODC REST APIs

🔐 Configure Site Properties

Go to Service Center and update these values:

Azure will pass this token as a Bearer token in the Authorization header for all requests. This is how the component verifies requests are from Azure.

3. Create the Enterprise App in Azure AD

1. In Azure AD, go to Enterprise Applications > + New application.

2. Choose “Non-gallery application”.

3. Name it (e.g., ODC SCIM Provisioning) and create the app.

4. Enable SCIM Provisioning

1. Inside the app, go to Provisioning.

2. Set Provisioning Mode to Automatic.

3. Use this as the Tenant URL:

   rubyCopyEdit
   https://.outsystems.app/api/scim/v2
   

4. Use the same value you set in SCIMToken as the Secret Token.

5. Test Connection

Click Test Connection in Azure.

This sends a GET request to /ServiceProviderConfig. If everything is configured correctly, you’ll see a success message.

6. Configure Attribute Mappings

Azure sends these attributes by default:

• userName

• name.givenName

• name.familyName

• emails[type eq "work"].value

• active

These map directly to the UserExtension entity in the component. Unless you have custom needs, the defaults will work out-of-the-box.

7. Start Provisioning

1. Go to Users and Groups in your Enterprise App.

2. Assign a test user.

3. Navigate to Provisioning > Provision on demand.

4. Search for the user and click Provision to trigger a manual sync.

This will send a POST or PATCH request to your /Users endpoint. Once verified, you can let Azure handle auto-provisioning for assigned users.

✅ What This Component Does

• Exposes the following SCIM endpoints:

  • POST /Users (create)

  • PATCH /Users/{id} (update/deactivate)

  • GET /ServiceProviderConfig (for Azure connection testing)

• Validates SCIMToken in the Authorization header for every request.

• Uses UserExtension to store user details and check if a user exists locally — reducing the need to re-query ODC.

• Calls the ODC Users API (via /api/identity/v1/users) to create or update accounts.

• Uses the OpenIdToken entity to store the access token from ODC so we don't request a new one on every call.

• Includes auto-refresh logic: it checks if the token is about to expire, and only then does it call the ODC Token API again. This keeps things secure and efficient.

⚠️ Limitations

• This version only supports the /Users endpoint. Group provisioning (/Groups) is not included because my Azure account (free tier) doesn’t support it yet — but it’s on the roadmap.

• Only core SCIM functionality is implemented. Extensions like /Schemas, /Me, and bulk operations are not part of this release.

🧪 Testing

To help with testing, I’ve shared a ready-to-use Postman collection here:
👉 https://github.com/michaeldeguzman/ODC

It’s important to test with Postman (or something similar) because users created or updated through SCIM don’t show up in the ODC Portal’s Users screen.

You can validate them by checking the UserExtension entity or calling the ODC Identity API directly.