IG 3.7.3 Off-Cloud Database Maintenance Best Practices / Lessons Learned

Dear Community,

I have some questions regarding your experience with IG DB cleanup / maintenance / housekeeping / archiving etc.

We are currently trying to enable customers to switch from IDM based permission requests to IG Access Request to provide a single, consistent interface for end users/business users (and hopefully this means much less need for customisation than is required in IDM).

Another benefit is that reporting information is centrally available and easier to manage than the DCS / Sentinel / Auditing 'construct' in IDM.

However, with end users working with Access Request, their need to check current requests, approvals and also historical ones comes into play. The same is true for Admins / Delegated Admins.

So, if a customer wants to give end users the ability to check completed requests a year back (which is perfectly feasible) in the Access Request module, we would need to keep the data for that period of time in OPS DB, I would guess.

However, do we also need to keep (user/permission) snapshots?
Or can we purge these?
What happens if we archive the data to an archive DB, can this "archived" DB then only be accessed via Reporting (as a data source) and not from the application itself?

There is hardly any hepful information about this in the documentation...

How do you deal with this, are there any "best practices" to share?

Many thanks and kind regards,
Philipp

Parents
  • 0  

    In the maintenance dialog, you can customize which entities you want to keep, and for how long. There is a 'snapshot' choice there and I can tell you that it will remove data from the following tables:

    • account_change
    • application_summary
    • entity_change
    • perm_change_changed_ext_attrs
    • permission_change
    • snapshot

    What I don't know is if any of these tables contain the data that you want to keep - the historical requests and changes of users.   You could possibly take a look at those and see if they hold what you need.

    I'm a fan of having a separate archival database that is used solely for reporting, if you have a need to keep things longer than the life of a review.   That is to say, I'm a fan of keeping the operational database as small as possible, pruning very aggressively to ensure peak performance, but I'm also used to LOTS of applciation data and accounts/permissions, so keeping it lean is important.   With archiving, you could setup a separate data source in reporting (or even an entirely new reporting instance that just points at the archive)  and use that archive DB just for historical reasons, but you cannot point the interface at the archive.   That means if you want users to leverage the out of box interface to see their historical data, you need to keep it all in the operations database.   Once you move anything over to archive, its now useless in the UI.

    --Jim

Reply
  • 0  

    In the maintenance dialog, you can customize which entities you want to keep, and for how long. There is a 'snapshot' choice there and I can tell you that it will remove data from the following tables:

    • account_change
    • application_summary
    • entity_change
    • perm_change_changed_ext_attrs
    • permission_change
    • snapshot

    What I don't know is if any of these tables contain the data that you want to keep - the historical requests and changes of users.   You could possibly take a look at those and see if they hold what you need.

    I'm a fan of having a separate archival database that is used solely for reporting, if you have a need to keep things longer than the life of a review.   That is to say, I'm a fan of keeping the operational database as small as possible, pruning very aggressively to ensure peak performance, but I'm also used to LOTS of applciation data and accounts/permissions, so keeping it lean is important.   With archiving, you could setup a separate data source in reporting (or even an entirely new reporting instance that just points at the archive)  and use that archive DB just for historical reasons, but you cannot point the interface at the archive.   That means if you want users to leverage the out of box interface to see their historical data, you need to keep it all in the operations database.   Once you move anything over to archive, its now useless in the UI.

    --Jim

Children
  • 0   in reply to   

    Hi Jimbot,

    Sorry for the late reply, I was on holiday for a few weeks...

    Thanks for the detailed feedback! It somewhat confirms the "worries" I had.

    I will have to take a look at the tables you mentioned, play with the maintenance configuration/setup and see if/how the data changes after the cleanup/archivation.

    It is very unfortunate that it seems to be quite complex to provide users with historical data (changes). I mean, we are talking about identity "governance" here, so these should be very basic features/configurations one should think. But that is another topic...

    Anyway, thanks again for your help! will share the information once I come up with a setup that works for us.

    Regards,
    Philipp