Unblock/block users when they clock in/out

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

Hey guys!

We are currently implementing something for a customer.
I don’t know how the expression is used in english (I searched and it says about clock in or punch in), but we need to unblock an user when they start their shift, and block them again when their shift is finished.

This blocking/unblocking is made through an Azure group. When the user is added to this group, they can’t access other applications, and when the group is removed, their accesses are normalized.

We where thinking about using lifecycles states. One lcs where users are still active, but they are not on shift so the lifecycle state should add the azure group, and another lifecycle state where the user is active and on shift, so they should not have the group.

Do you guys have implemented something similar? Any suggestions for this need?
Thanks in advance

2

It is pretty straight forward there is no complexity here as you mentioned LCS. Using lcs we can easily implement this.
Only thing is we need to be clear what is attribute that defines active user(in shift) and inactive (not in shift), based on that attribute prepare cloudLifecycleState transform that push users to unblock and block. Remaining your choice want to with roles or access profiles

3 Likes
3

I am assuming some attribute on application side toggles when a user is clocked in/out (like clockedIn = true or false). With this assumption, if you like to implement the logic you have explained, the process would be something like this:

  1. When a user is clocked in, the updated attribute (clockedIn) will have have to be sent to ISC, which happens via Account Aggregation. This can be done via an API call to aggregate single account, provided the source is configured for single account aggregation. (This will probably need 2 API calls as you will not know the account ID that needs to be fetched using nativeIdentity) Also, the API call needs to be triggered by target application as ISC will not know if the attribute clockedIn has been changed for a specific user
  2. Based on this identity LCS needs to be changed, which can be done via another API call. But again, this API call needs to be triggered by target application within the same script that triggered Account Aggregation in the previous step.
  3. Once the LCS is updated, Azure group can be granted or revoked based on a role assignment criteria within ISC

Now the question is, if such a process is feasible when hundreds of users would be clocking in and out within a short period of time.

1 Like