IdentityNow Role Mining for Unconnected Source?

Lifecycle & Governance
1

I am a new SailPoint IdN support professional (demo environment access & first IdN cert passed), working for a client setting up RBAC (no RBAC framework exists currently).  They are in the process of moving over to SailPoint IdN from another, older solution, and not all applications are integrated with IdN yet.

I need to do role mining for several of these unintegrated apps - is there a way to upload a CSV file into IdN and perform role analysis, without a connected source system needed?  The CSV file would be an account export from a given unconnected app, and would have the users identity data and their permissions (entitlements) within the app.  Just trying to avoid more manual process if possible.

I have reviewed Access Insights and that seems to take already existing entitlements (and across the IdN environment, not per source?) and suggest roles.  I also found a general flat file system for uploading identities, but that also seems to require a connected source first?

2

@MichaelAAskins  would it make sense to use your sandbox tenant for this? Perhaps you could create sources and import a csv file of each source’s entitlements.

Unless you’re already using your sandbox tenant to emulate a smaler version of your production tenant, and it can’t be modified otherwise.

3

Can the sandbox tenant do role mining without connected sources?  That’s my issue - the sources will not be integrated prior to needing to perform an RBAC discovery and role mining, in dev or test.  Or can I create a source that is a ‘dummy’ with the same entitlements as the real one, then import the CSV/flat file of identities from the source and perform role/access insight workflows that way?

4

@MichaelAAskins , yes the sandbox tenant can do role mining with non-connected sources - it shouldn’t matter whether the source is connected or not for the role mining process, the entitlements just have to get into IdentityNow to be processed. You should be able to port over the mined roles using the Configuration Hub.

Regarding imorting a CSV/flat file of identities, that’s not something IdentityNow can do, since identities are created from accounts on sources that are authoritative (those that have and access profile asigned to them).

If any of my colleagues would like to add to this or explain differently, please feel free to chime in!

5

@paul_patti  , thank you for the response.  I have an additional question - can Access Insights work on a specific source and/or group of entitlements; or does it only go through the whole tenant?

Since we’d need to upload a flat file of users and entitlements, we’d like IdN to do the role mining JUST for that source, as the tenant and other identities are quite large/numerous.  But it sounds like we cannot import those users via file, so there’s no automatic way to take identity info (their job code, department, service area, title) into IdN and use?  So we cannot role mine at all?  Because I don’t see how we can role mine with just source entitlements listed.  That’s only half the equation.  Sounds like we’d have to manually create identities for that unconnected source that we uploaded per the first comment.

6

Hi  @MichaelAAskins  Paul is out of office this week, so I can reply.

To clarify, Access Insights is our AI-Driven analytics component. It provides data around Access History (a timeline of each identity’s assigned access over time), Outliers (identities with dissimilar access), and the Access Intelligence Center for creating charts and graphs around certifications, access requests, and identities. Access Insights doesn’t actually do role Mining.

Access Modeling is the AI-driven component that offers a role mining feature: discovery of new roles and suggested entitlement updates to existing roles. I think this is what you are looking at and hoping to leverage.

If you haven’t seen this already, I invite you to watch a 1-hour webinar on AI Access Modeling. You may see some additional info in there that will benefit your implementation. That free recording can be found here:  https://community.sailpoint.com/t5/Webinars/Technical-Bootcamp-AI-Access-Modeling/ev-p/254783

In summary, you can role mine (aka “Role Discovery”) as long as the tenant has identities + some entitlements:

  • Tenants can include ‘disconnected’ sources. Typically we use the “delimited file” source type.
  • Role discovery (role mining) can be automatic or manual, once identities + entitlements are available in the tenant.
  • Role discovery, whether automatic or manual, potentially considers all entitlements available in the tenant. To eliminate certain entitlements form the role composition, simply check the box next to all the ones you want to remove/exclude and click the “exclude” button. The Role Discovery topic has more details.
  • Prior to the release of the AI Access Modeling component, our best practice was to upload entitlements for non-authoritative sources prior to the user accounts, so that we could do our own manual access modeling. This is still a practice today, but the AI-based Access Modeling makes this WAY more efficient!

Explanation:
In theory, you could create a “delimited file” source. It is a disconnected source type, it can accept a csv as the source of data, and you can manually upload the data to a tenant. In the uploaded csv, you would include account names of the identities, entitlements/group membership, and any other relevant fields/attributes.

*For best results, the tenant should already have an authoritative source defined, and identities pre-existing. Otherwise, this new list of user accounts/entitlements become uncorrelated accounts, as you suspected.

Also, Potential Roles rely on identities and their already assigned entitlements. This style of role mining uses a peer group analysis algorithm, looking at the similarity of entitlements held by identities that have 3 identity attributes in common, typically department, jobTitle, and location.  This is why you must have identities defined in the tenant first, before role mining with the AI-based Access Modeling component.

Potential Caveats:

  1. If this delimited file source is just a placeholder for a connected source to be added later, what happens when the long-term (connected) source type is introduced to the tenant?
    --Ans: Users may have “duplicate” accounts and you may end up with duplicate entitlement names in the tenant’s entitlement catalog, if both sources are allowed to coexist (you can’t actually “convert” sources from 1 type to another. You must create a new source.)
  2. Also, if you remove the delimited file version of the source because the connected source with its entitlement catalog is the “winner” and this disconnected source is no longer needed, the entitlements associated with the disconnected version will also be removed, and the roles many not work as originally defined, because they containing missing entitlements. That will have to be resolved as well. So you may end up creating “duplicate” roles later OR updating all the membership criteria to point to different criteria, a task you are probably hoping to prevent.

Just some things to consider. Again, there is no harm in manually creating roles outside the AI Role Discovery. But a good practice is to design them outside of ISC first.

Also, perhaps you may decide it is best to wait until this source can be properly and fully introduced into the tenant, in its “final” state. This will prevent duplicate work or issues from occurring later, but you would need to wait before role mining against that source -- trade-offs. I do hope some of these thoughts help you in the customer implementation.

7

Thank you very much @amy_shillinglaw  , yes I believe I was using the wrong terminology being new to IdN; you are correct I meant Access Modeling!

So to confirm my understanding - the delimited file source we create would include accounts (identities) within it, along with their entitlements.  Then I can perform Access Modelling, which is exactly what we are looking for.  Sadly the sources will not be connected prior to needing to understand RBAC for the source (cart before the horse has to happen).  But I think the two caveats can be dealt with:

For 1, we would definitely remove the disconnected version of the source before connecting the actual source.  It sounds like we’d need to clean up the user accounts afterwards prior to integrating the actual source.
For 2, we expect the implementation part to go quickly, so the connected vs. unconnected versions of the source should be 1:1.  My hope is since we discovered & documented the roles previously in the ‘test’ source, we can then quickly re-create and should be 1:1 match.

Let me know if I am getting it correctly, and if so we should be good to go!  I’ll also watch that video, thank you very much for sharing.

8

Hi  @MichaelAAskins  Excellent, I’m glad I understood correctly - want you to do and exactly which component you were working with.

So, all of this was a theory, because I don’t have any knowledge of the rest of the environment, requirements, or other components in the tenant. But yes, I believe, from a high level, this SHOULD work. Definitely proceed with eyes and mind open. Look for other caveats I may have missed and conditions or complexities I may not have known about.

In fact, in one of our instructor-led training classes for ISC, we deploy a delimited file, NON-authoritative source that has user accounts and entitlements. Then we practice manually creating access profiles and roles with combinations of entitlements from this and other sources. If the manual process and Search queries can find the entitlements, then the AI Role Discovery process will as well. This was the ‘inspiration’ for my suggestions.

A couple of additional tips:

  • If you want to use the Automatic Role discovery, you will need to wait until the next day. The process for automatic role discovery of new roles + suggestions of entitlements to include in existing roles happens after 1 am. But you should see suggestions in Role Insights by the time you log in “tomorrow”.
  • The tenant’s “Configuration Hub”  feature allows you to take a backup of objects such as roles, rules, source definitions, etc. Then, you can export the objects you saved. Using the Tenant Connections option within Configuration Hub, you can import the roles to a different tenant in the same data center, and save yourself from having to recreate them anew in the other tenant. Just a thought to reduce some duplication of efforts.

Happy mining!

9

For sure, I know the environment will have an effect on any advice, but I also believe this is the path at a high level - I’ll just have to smooth out the bumps along the way!  And in the end, if we have to do manual profiles/roles (if AI doesn’t work for X reason), having it within IdN will still be very beneficial as opposed to manual Excel sheet work.  Thanks for the additional tips, noting it all down for when we begin shortly.  Thank you both again so much for the help!

10

Hello again  @amy_shillinglaw  ; let me know if this question should be a new thread, wasn’t sure since it related to our previous conversation.

I’ve found out that our IdN demo environment has a limit of 5k users.  I was asked that, after we use this to perform the role mining via and backup our discovered objects the next day - what does the cleanup process entail, since we have to remove anything created via the delimited file.  I believe you mentioned removing the source would remove the roles entitlements and related objects, is that a correct understanding?  For the user accounts created from the source file, those are a manual cleanup to delete them?