Announcement: Personal Access Tokens Expiration Policy

Announcements Product News
,
6

Yes, I agree with the others on that this is a bad idea. Please view the my arguments why below. I hope this will get rolled-back quickly.

  1. This functionality limitation was not announced in advance. I discovered this in production before the announcement and already explained to my team members in what ways this breaks our current processes.
  2. This functionality limitation is not mentioned in the release notes.
  3. This was also not covered in an in-discovery announcement, allowing us to raise our concerns on how this would negatively impact our way of working before SailPoint would even started building this.
  4. Our CSM did also not warn us on this breaking change. Were they informed on this?
  5. I haven’t seen this in non-production before I saw it in production. Meaning there was no or too little time between for partners/customers to raise the noticed issues when discovering in non-production.
  6. We can’t modify the hardcoded max of 6 months, or even disable this functionality. We have build specific workflows to govern Personal Access Tokens. Think of things like only allowing those in a governance group to have them, deleting if not used for a long time. Those were our choices based on our policies. One could have chosen to build a workflow to delete PATs older than 6 months, but one could have chosen not to do this. With this functionality limitation, this flexibility has been removed.
  7. The documentation now mentions that SailPoint recommends using the API Client method for long-term or Production integration use, but this is undesired for several reasons:
    7.A. API Client Credentials can’t call the same APIs that you can call with a Personal Access Tokens, limiting what you can do with it. Many APIs don’t support calling with API Client Credentials.
    7.B. API Client Credentials are not associated to an identity (human or Service Account) in the way Personal Access Tokens do, meaning it is more difficult to apply life-cycle management on it, which we can and are doing for Personal Access Tokens. In fact we want to only have API Client Credentials for cases where we absolutely have to due to out of the box SailPoint functionality (VA management and workflows with external triggers) and have a workflow automatically detect notify and delete different API Client credentials. Any other API Client Credential can’t be governed as securely as PATs.
    7.C. API Client Credentials can only be limited on what they can do based on scope of the credentials. Personal Access Tokens allow more flexibility as on top of scope you can apply concepts like segmentation, user levels and governance group membership to determine what you can do with those credentials. We lose all of this if we choose to go with SailPoint’s recommendation.
  8. Some security standards argue that having to rotate certain credentials every 6 months can even increase the risk of compromised credentials instead of solving it as you need to replace the secrets more often, and they suggest to only rotate those credentials if there is a suspicion of a compromised secret. By putting this functionality limitation in here, The choice of the customers is taken away and one opinionated decision is enforced.
  9. Note that frequent recreating of PATs is extra insecure due to the fact that ISC shows the secrets in plain-text. If you search in the idea portal on Personal Access Tokens and sort by popularity, you will find this idea to fix this security vulnerability.
  10. SailPoint Workflows require us to give the secret for every HTTP operation we use to ISC API’s, meaning that we have to update these credentials in a lot of places every time it gets expired for our workflows to keep functioning.
  11. I might now cling on my current PATs that are still there without expiration date and will be more hesitant to replace them, knowing it will cause an enforced expiration. We should be able to recreate them ourselves when we think the PAT has been compromised without having to get badly effected on it.

So in summary this is a too late announced change, that enforces a questionable control that we can’t undo, and that will disrupt our way of working, while the recommended SailPoint approach is not feasible, limits flexibility and would break the security controls we currently have in place.

Please roll-back this functionality quickly. If you want you can consider the following:
Have a global configuration setting allowing customers to choose to have a max expiration day (and if so, what the max days should be, 6 months, 2 years? etc). In this way you add functionality for those tenants who requested it without enforcing this hard-coded limit on other tenants as well.

And please for the next time involve this community with breaking changes like these. We could have explained up front why this would not be ideal and why the alternative suggestion of using API credentials is not feasible and not the best practice.

Kind regards,
Angelo

28 Likes