SSO, IDN and Sources -- Apps that require an entitlement from more than one source

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Like most companies we have SSO setup for many 3rd party SaaS apps. Our SSO is setup using Azure Active Directory.

Most of our SSO setups with these 3rd party apps require a group to be created in AAD representing the ability to utilize SSO for that app.

At the same time, many of these apps don’t support any sort of automated provisioning, leaving us to set these 3rd party SaaS apps up as Service Desk Integrations (ticket based manual provisioning activities).

So, we then have a ‘two source process’ to setup a user for one of these apps.

  1. Create an account within the app.
  2. put the user in that Apps AAD SSO group.

That’s feasible. We have a S.O.P book our access control team uses; and in that apps section of the book, we include that additional “put the user in AAD Group X also”; (Or remove them on a deprovisioning)

It gets messier as we try to optimize. For example, Apps that natively have SailPoint connectors, or support the generic mechanisms (scim, webservice, etc.).

SailPoint can replace that Service Desk Ticket… but… what is the best way to handle that additional “put the user in AAD Group X also” step?

We do have requestable access, so have been using requestable access profiles (and Request Center Applications to organize them).

We have heard that we could switch to exclusively using Roles, as Roles can contain entitlements from multiple sources. But we are unsure if losing the application-based organization or our requestable access would have too much impact.

We have thought about possibly using workflows, but we have about 40 apps that are SSO enabled today and are continuously trying to convert all of our apps whenever possible. This would mean a decent amount of workflows/workflow complexity.

There might be a Provisioning Rule based way to do this also? (I am not familiar with these)

How are people handling SSO enabled third party SaaS apps. (Apps that require entitlements from multiple sources)?

2

I usually use roles for SSO apps. Set up a role that looks for an active account on the application, and if the user has it - add them to the SSO group for that app.

1 Like
3

Hi Chad,
What I would recommend is take a subset of applications and try to use Role wherever possible and see the impact. This will ensure that the impact is not higher and you are smoothly migrating the apps from disconnected → connected.

Thank
Rakesh Bhati

4

Same here for use.
We have created roles with automated attribition and a specific naming convetion ([AUTO] in the name of the role, so that we can exclude them from our certification campaigns).

User experience is good with this, even if it is adding lot of roles in the identity interface for us. But i think the new interface will enhance this with the tab bar :wink:

++

1 Like
5

I like the idea of using [AUTO] in the name of the role to exclude it from cert campaigns! Will keep that in my back pocket for future use.

1 Like
6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.