Is this how the backend is configured of OOB Connectors like Slack, Okta, etc?
While we’re unable to look under the hood for HTTP operations within OOB connectors, it’s clear that they’re performing some magic behind this scenes.
For example, the Okta API responses for /users
and /groups
are decoupled in that the users response does not return group memberships. Despite this constraint the OOB connector for Okta has Groups in the account schema
and omits members from the entitlement schema
Similarly our legacy internal tools solved for this by aggregating both object collections and correlated the memberships like the following python example.
def aggregate_teams(self):
users = self.get_users()
teams = self.get_teams()
# Use enumerate function to keep track index (ex. x[0] index, x[1] iter.item)
for x in enumerate(users):
# Creates Dict Key \ List in user object
users[x[0]]['attributes'].update({'teams':[]})
# Loop through teams
for team in teams:
# Check if member of team
if x[1]['id'] in team['attributes']['members']:
# Append team to user object if True
users[x[0]]['attributes']['teams'].append(team['id'])
There are plenty of SaaS Apps that decouple memberships from the user object, thus we’re trying to find an elegant solution to mapping entitlements.
Otherwise seems like a common use-case that could be solved within IdentityNow having a feature that functions like so:
Flag for disjointed entitlements: True
Logic \ Requirements
- Aggregate Users
- Aggregate Entitlements
- Import > Entitlement Correlation* ← processes \ correlate existing entitlement data
a. entitlement type: team
entitlement attribute: members
> operation: contains
> identity attribute: uid
b. entitlement type: group
entitlement attribute: members
> operation: contains
> identity attribute: uid
c. entitlement type: role
entitlement attribute: members
> operation: contains
> identity attribute: uid
This would effectively reduce the high technical barrier of entry for most teams and provide sufficient tools \ minor steps to achieve the same goal.