Which attribute triggered a modify task?

[Former Member]

Dear Gurus.

I have following question: Is there any way to determine, change of which user attribute in Identity Store, has triggered a modify task?

Background:

I am thinking about implementing a functionality that would automatically handle inactive users.

I load last logon data from SAP back-ends, consolidate it accordingly and this gives me information on which users are active and which are not on individual SAP systems.

Now I need to invalidate them to spare licenses but allow quick roll back if needed ("Grace period") and after some time (like 45 days or so), remove all relevant business roles from them in order to completely delete them from SAP.

I was thinking about creating attribute like "Z_INACTIVE_<REP_NAME>" (one for each repository) that would hold a date when a specific user was identified as inactive on particular SAP system. This attribute would be updated by a job running daily based on last logon information from SAP.

Then I was thinking about assigning a specific modify task to all those "Z_INACTIVE_...." attributes. That modify task would then need to be able to distinguish, which particular attribute was changed in order to check its' value (was it set, or cleared) and then execute proper custom connector for a proper repository (extracted from attribute's name for example), which would, in result, invalidate user on specific SAP system.

In order for this to work, I would need to have a switch task in that modify task, that would be able to determine, change of which user attribute has triggered a modify.

Is that at all possible at run-time?

I did some investigation around Audit tables/views and I have found some promising results, but I'm not sure, if this is trustworthy and usable at run-time. For example field "userid" of view MXP_AUDIT seems to contain attribute number, along with information if it was inserted or deleted, provided I have AuditID, but this is a free text and I'm not sure if I can use it from switch task at run-time or is this data filled in after specific action task is executed.

I would probably also need to enhance standard modify task to avoid it from updating user's VALID to/Valid from in case it's marked as inactive on specific repository, for example during user's master data update, but this is a secondary topic.

Any thoughts on that topic would be highly appreciated.

Thank You in advance

Darek.

[jrondorf]

HI Darek,

how should a user reactivation be triggered, process wise?

cheers, Jannis

[Former Member]

Hello Jannis

Currently I am considering two "time periods" which would determine possibilities that user has:

1) within first 45 days of user inactivation - user can use self-service task that, within that "grace period" would immediate clear the relevant inactivity flag (Z_INACTIVE_<REP_NAME> Identity Store attribute), which would trigger a modify task and execute connectors that would:

          a) reset the valid to dates on related production systems

          b) (if I decide to use user groups to classify those inactive users on SAP backend) - remove the related user group from that user on related SAP systems

2) after 45 days since invalidation, since all business roles related to SAP platform ion question would have already been removed, user would need to follow the same onboarding process as any new SAP user.

Just to clarify one thing - since there are numerous systems that build SAP platforms  (ECC, CRM, SRM, APO , EWM etc.) I consolidate last logon date on "platform" level, which means - I check last logon dates from all the systems that are part of a particular SAP platform (for example - all productive SAP systems from that platform) and then pick the latest logon date as the one representative for the whole platform. Only if this latest logon date is "old enough" I consider this user as inactive on that particular SAP platform and invalidate it on all SAP systems related to that "platform".

Once 45 days pass, I will remove all the roles related to that platform from the user, that would delete user from related SAP systems. This can only work if You have business roles built in a way that they never are "cross-platform" (for eg - roles should not contain privileges from PROD and PRE-PROD systems), as otherwise You could remove user from systems, that he/she is still using (for example developers on development systems), just because he/she did not use PROD systems for some time, which we would not like to happen. Fortunately our Business Role authorization concept allows fulfills this requirement and all (99%) of our roles are only relating to a single SAP platform (for example - PROD systems only, or QA systems only, or DEV systems only etc.).

This would of course mean, that I would rather need to have this Z_INACTIVE_.... attribute created per SAP platform, and not per SAP Repository, but I deliberately simplified a topic a bit when describing it not to "draw attention away" from the main topic

One other open topic is how to get last logon data from JAVA AS - this is something I have not solved yet and I will probably need to find some workaround for it until I find a way to deal with it (for example exclude users that have at least one role related to a JAVA AS system form the whole process).

Let me know if You have further questions

Kind Regards,

Darek.

[former_member222441]

Hi Darek,

1. in the field UserID of mxp_audit you will find a value corresponding to the checksum field mxi_values.bCheckSum. We use the same technique for determinig the modified attribute.

2. I assume you have a different job for each repository for reading the last login time. Instead of connecting your logintime attribute with a modify task, you can in a second pass after importing the login time, select each user with an expired login time and call uProvision with your modifytask together with the repository information. Now, in your provision task you can take away all privileges of the repository.

Kindly,

Andreas

[jrondorf]

But you know the self service UI task, where thsee users are able to re-enable them selves, right?

why not programmatic all do in a action task inside this UI task the logic?

Changing the default core framework is not good (if not already done ), and using advanced "let's see which attribute was changed" logic could be avoided.

[Former Member]

Hi Andreas.

Thank You for Your suggestion.

However, what is the advantage of using bCheckSum over using the Atribute ID, which is also avaliable in the same field?

as to 2) - this would be an option, however I somehow feel, that it would be more 'correct' approach to use attribute for that purpose. In future I might need to check when was this particular user identified as inactive (attribute would hold a date), I could also adjust Modify ABAP User connector not to update Valid To dates for users, that were identified as inactive on specific systems in order to avoid ovewritting validity date when user updates some other master data. I feel that this kind of functionality would be difficult to implement if we only based on data from temporary tables. But probably possible.

Kind Regards,

Darek.

[Former Member]

Hi Jannis

You are right. this would also be an opotion (I will probably need to create separate UI self-service task for each SAP platform anyway).

I analyzed pros and cons and it was a "close call". I have, however, decided to go for using the UserID field and were able to succesfully determine which attribute change has triggered the modify task based on the Attribute ID provided there. Switch task works well and this setup appears to be very flexible and future proof.

I am not changing standard provisioning framework those action tasks executed after the Z_INACTIVE.... attribute change are custom action tasks and they are assigned directly to attribute as Add and Remove event tasks.

What I just might need to do is to customize "modify ABAP user" onnector so that it did not update VALID TO dates for users that are inactive on relevant systems, but since we have all connectors customized anyway, I'm not that concerned about it