Logiplex replacement in ISC

SailPoint Human Fabric (SHF) SHF Discussion and Questions
1

Hello Experts,

We are currently migrating from SailPoint IdentityIQ (IIQ) to Identity Security Cloud (ISC) and are evaluating options to replace our existing LogiPlex.

In IIQ, LogiPlex is used to manage application-specific access by combining Active Directory groups and application entitlements

As part of the migration, we are considering the following approaches:

  1. Active Directory Source + Roles (AD Plus Model)
  2. Active Directory Source + Application Access Model
  3. Any alternative ISC-native design patterns recommended by the community

Has anyone successfully replaced a LogiPlex-style implementation in ISC? If so:

  • What architecture did you adopt?
  • What were the advantages and challenges?
  • Would you recommend Roles, Application Access, or a hybrid approach?
  • How did you handle singleton entitlement enforcement and remove-before-add requirements?

Any implementation experiences, lessons learned, or reference architectures would be greatly appreciated.

2

Hi @tharanika_k_bala

For this use case, better and cleaner approach would be Hybrid implementation using Access Profile and Role Model.

You could setup Applications as well for the access profile bundle that you will be creating.

I have not implemented this usecase but as per the experience it would be the better approach that I could think of. If you find any better way to implement this, let me know as well.

Thanks
Manish Singh

3

Hi @tharanika_k_bala

This is a common hurdle during IIQ to ISC migrations. Since LogiPlex isn’t supported in ISC, the recommended native approach is to model your AD groups as entitlements, group them into Access Profiles, and assign them via Roles or Applications.

The native AD connector handles standard provisioning and deprovisioning (including membership removals) out of the box, so you won’t need a direct LogiPlex equivalent. If you run into complex sequencing or remove-before-add requirements, you can handle those using the Services Standard Before Provisioning rule on the AD connector.

As a best practice, I generally avoid relying too heavily on Access Profiles since they aren’t sticky and often behave differently than people expect. However, they are great for logically grouping AD entitlements into individual Applications that users can request. This provides a clean user experience because the requester only sees the friendly application name rather than the underlying Active Directory connector details.

4

Thanks for your quick response. We currently manage around 500 sub applications as child, and this number is expected to grow over time. Considering scalability, maintainability, and future growth, would you recommend adopting the Application Access Model as the preferred replacement for LogiPlex in ISC?

We are looking for an approach that can scale efficiently while minimizing administrative overhead and customization.

5

Many organizations use this approach and I believe SailPoint will continue to increase limits to support this architecture. There are other ways to handle this, but they aren’t OOTB and supported by SailPoint. So with that in mind, I think the application access model is the safest long term bet.

There are some soft limits on the amount of roles/access profiles, but this is something that can be increased from SailPoint if you request it. There’s a recent discussion on this here if you want to take a look.

6

As @trettkowski mentioned, I also recommended the same approach. There are some limitations on the number of access profiles and roles, but that can be increased by SailPoint if you request.