An identity created several personal access tokens for themselves. We disabled the identity in ISC and then we enabled the identity in ISC again. The identity logs in through the UI and creates another personal access token.
The identity now observes that the new personal access token is working while the other two are not. Apparently disabling the account disables the personal access tokens, while enabling the identity does not re-enable the personal access tokens. This behavior is not clear and in addition one can not see (neither in the UI nor through the API) which personal access tokens are working or not working.
What is the correct behavior?
I think the best solution would be to have an enable/disable status/(swipe-)button on the personal access tokens for the end user to update in the UI. Then we can also see the status of them. Disabling the identity could trigger disabling the personal access tokens. After the identity is enabled again, they could then choose to enable/delete the old personal access tokens that have been disabled.
What product feature is this related to?
Authentication/Authorization
What are the steps to reproduce the issue?
Have a working PAT on an identity, let an admin disable the identity, then enable the identity again and check if the PAT works. then create a second PAT on the identity and check if that one works. Notice through UI and API that we can not distinguish the working PAT from the failing PAT.
I moved this to Idea Discussions since this is asking for an enhancement to how the PAT disablement is designed.
It used to be that identities that were disabled did not have their personal access tokens disabled at the same time, and any active bearer tokens that they had generated from the PATs remained valid until they expired, which is up to 12 hours. As a security precaution, when an identity is disabled their PATs are also disabled, immediately revoking any bearer tokens they had generated.
As you mentioned, this mechanism has room for improvement in the UI. It might be better if the PATs of a disabled identity are deleted so they don’t appear in the UI. Then there wouldn’t be any confusion as to which PATs are disabled. When an identity is enabled again, they would have no PATs and would then know they have to create new PATs. What are your thoughts on that?
Although I think that the best solution would be to enhance the current design and I agree with you that there is plenty to discuss on the best behavior, making this fall under idea-discussions, I would also argue that the current version would constitute as a bug, so both tags are needed.
An admin could accidentally disable your account, realize the mistake, enable it directly and continue on the work, but in the meantime, PATs have stopped working without a clear indication that they got disabled and/or why. It just says authentication failed, even though the user is able to log into the UI and see the PAT in their list. The end user will probably realize that calling the API is not working, spend time trying to figure out what has caused this, is unable to find the answer after which they would need to escalate to the customers helpdesk, which would escalate to SailPoint Support.
I do understand the security risk you mentioned, but I would describe the current behavior an urgent temporary fix and not a stable version of ISC.
I am not sure if the account disable operation should fully trigger the deletion of the PATs. The end user has created them and has spend time to pick a name and select the scope. It could take a lot of time to recreate the PATs in the same way and add them to the same locations again. If the PATs instead have an enabled/disabled toggle themselves, the end user could go to their list. See them still there but marked as disabled, and can toggle them on again without having to go through all the hassle of redefining the PATs and updating the system using the PAT. As a bonus, when trying to authenticate using a disabled PAT, the response could indicate that although the PAT id/secret matches, that the PAT is currently set as disabled, making it more clear for the end user what is going on.
If we disable an identity and enable it on the same day. This could be an indicator that disabling was a mistake and in that case I think that the PATs should work again without intervention form the end user.
If an identity was disabled for over a month and then enabled again. I think it makes sense that the PATs stay disabled until the end user manually enables them again. Perhaps they do not know of their existence anymore or do not need them anymore. Then it makes sense to specifically let the end user enable them again.
So I think the behavior might need to depend on how long the identity stayed disabled.
I’m talking with engineering, and they hinted at a possible enhancement where we re-enable PATs once the identity is enabled again. So if the identity is disabled, their PATs are disabled. Once the identity is enabled, their PATs are re-enabled and ready to use again. Does that work for your needs?
It would certainly work with the example of accidental disabling and quick re-enabling. It does not work when an account gets re-enabled after a long time and we would preferably have the PATs existing, but disabled. However in those cases we could use workflows to delete the PATs until we get functionality to disable them.
So the most crucial part would be fixed with the way you suggest and the long term less crucial part can be managed however we want. So it would be a good step forward. Nevertheless it is good to inform the customers about this well, such that they know to build something for long term.
Perhaps I leave the company, get disabled, hand in my laptop containing the PAT, which doesn’t matter as the PAT is disabled anyway, after which I get hired again and enabled again, get a new laptop, but the old PAT is suddenly active again. Perhaps not the best example, but I could see the risk of having old credentials activate as byproduct of another action
