Best practice for managing entitlements in authoritative source applications?

IdentityIQ (IIQ) IIQ Discussion and Questions
, , ,
1

Which IIQ version are you inquiring about?

8.3p3

TLDR: Is there anything inherently wrong about using the same authoritative App definition to provision entitlements into that same app?

I have a business requirement to be able to add an entitlement to a application we are sourcing identities from.

In our particular case, we are using the same Okta tenant for both B2B users and internal users. For Internal users, Okta is a ‘downstream’ app and entitlements are managed like any other app. However, for the B2C users their Okta accounts are sourced from Okta via a ‘scoped’ authortative app (Okta B2B) so that they can be provisioned into other downstream apps. These Okta accounts are explictly scoped OUT of the downstream Okta app.

The concern here is that we now want to start adding these B2B users to groups in that tenant. Unfortunately, if we use the ‘downstream’ Okta app for the entitlements, IIQ will simply provision them ANOTHER Okta account in that tenant.

So my initial thought is to simply add the necessary entitlements via the ‘Okta B2B’ app, and add those entitlements to the proper roles. I’m just not sure if that’s a recommended pattern to have your authoritative app also be a downstream recipient of entitlement provisioning.

Thoughts? TIA!

2

Hi @josefismael,

In many enterprise implementations, workday is configured as

  1. An authoritative source for identity data (HR-driver joiner/mover/leaver events)
  2. A managed application for provisioning entitlements (eg security groups, roles)

Just like workday, your okta B2B app can serve as authoritative source for B2B identities.
the target for entitlement provisioning, as long as provisioning is scoped to entitlements (eg group memberships) and not full account creation/modification/deletion operations.

configuration needs to be carefully managed to avoid provisioning loops or duplicate accounts.

3

thanks so much @vinnysail :slight_smile: This is not one of the current patterns in our organization, but just wanted to make sure this wasn’t discouraged by the vendor or the community. Thanks again!