While investigating the impressive native access history feature in IIQ 8.4, it came to my attention that the capability does not appear to take authorized scopes into account. To illustrate, if a user possessing access history capability is authorized for scope x, the access history should ideally only show users from that specific scope. I’m curious to understand the rationale behind this design decision or I am missing something here?
Out of curiosity, how would you expect it to behave if a user historically moved into or out of a scope over time?
Or, for that matter, an entitlement or role?
Hello Devin, I appreciate your question. What I anticipate is the ability to view the user’s access history within the context of their current scope. Suppose a user transitions from Scope X to Scope Y and subsequently to Scope Z. In that case, my expectation is that only administrators of Scope Z should have access to the user’s access history, not administrators of Scope X and Scope Y. Regarding roles and entitlements, my expectation is that administrators of Scope Z should have the ability to view everything, including roles and entitlements from Scope X and Y. This is necessary to ensure a comprehensive view of the access history. I understand that this can become complex, so I’d love to hear your thoughts on this matter.
The problem is that the scope of any object can change over time. A role that was part of Scope X when the user was in Scope X is now in Scope Y, while the user is in Scope Z.
There’s also the 8.3 addition of classification, which ought to hide the existence of certain items from certain categories of users… which can itself also change over time (both the items and the users).
I’d think that your “current scope” model would be doable, assuming that the Identity still exists at all. (History necessarily includes deleted Identities too.) But from there, it gets wild. Some organizations would want access history partitioned the same way other items are partitioned by scope/classification. Other organizations would want an admin in Scope X to be able to see the access history from the time when the user was in Scope X, but not the later history. Maybe a “transitioned out of scope” message.
Either way, if they’re going to make the change, they’d better do it immediately, because if the access history isn’t tracking this information at the start, it’s much harder to add later.
Thanks for sharing your insights and consideration. I agree that implementing a “current scope” model seems like a practical starting point, especially if Identity preservation is a priority, including historical information. However, as you rightly pointed out, it can become quite intricate when dealing with organizations that have varying requirements for partitioning access history. In any case, the change has to be done proactively.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.