I can’t seem to generate a PAT for a service account through the API because the /personal-access-tokens endpoint only wants to create tokens for the owner of the current token. Is there a way around this? Having to log in interactively as a service account is not the simplest thing to do.
You should be able to create service account API Keys through: Admin > Global > Security Settings > API Management. Refer to the documentation for more details.
Let me know if that helps.
Yes, but that doesn’t create a token with the same permissions as a specific user.
In this particular example, I want to create a token that will be able to create accounts in a specific CSV source, and the documentation for that endpoint specifies a token with ORG_ADMIN is required. I’m not sure you can generate a token through API Management with those permissions
It indicates specifically in Step 5 of the documentation I referenced, that you can specify specific scopes. Please double check and let me know if that helps.
I generated a new app token and gave it sp:scopes:all, but I get a 403 when trying to hit the /access-request-status endpoint, which the docs say require a token with ORG_ADMIN. I am, however, able to update an account using the same token, which also says requires ORG_ADMIN, so I guess I’m a little confused as to why one works and one doesn’t
hmm, that is interesting. Unfortunately, I don’t have a tenant to test this out in.
I do know API Scopes were introduced recently, this year or late last year. Perhaps it’s some growing pains that need to be ironed out.
I wonder if this is because you are hitting the access-request API, they may have bared it off because there is no identity associated with the request. It wouldn’t be good to be able to submit an access request anonymously, would it? I understand you are requesting the status, but I suspect it lies in the same family of endpoints.
I would ask SailPoint directly if this is working as expected. If they believe it is, then they should be able to offer up another solution. I do feel we are headed down the right path as tying service account API keys to user identities would be bad practice. The only other option would be to create a service identity using the Identity Admins source. This isn’t a bad solution, just a bit more tedious.
We actually have identities for non-human accounts like AD service accounts or bots, so it was actually kinda straight-forward to provision it the correct access then generate a token for it.
You’re right though, we don’t necessarily want anonymous access requests being created externally, which is why we generated a PAT for our ServiceNow service account in AD.
I’ve had an issue specifically with this API endpoint permission because I wanted a token generated for PowerBI to be able to read access requests for other users. Since it can’t, I had to re-use my ServiceNow ORG_ADMIN credentials for Power BI
@bostelmann I know you’ve been losing sleep thinking about this, but I looked into the API docs and figured out how to see what scopes are required for a given API call, and notably missing are scopes for account activities and access requests… which are kind of a big deal
@colin_mckibben is there any guidance on generating PATs for non-human identities vs doing it through API management for these use cases?
It is preferable to create non-human identities for the purpose of creating access tokens for automations. I have documented a simple process for doing this here.
Thanks for the info. Correct me if I am wrong, but as admins, we do not have the ability to generate a PAT for another identity, right? It requires us to be logged in as that identity, correct?
Correct. You have to be logged in as the user to generate a token as them.
I assumed that was the case… please allow me to provide a bit of feedback on the steps I must go through for this process.
Note that we create identities for (AD) Service Accounts because we utilize ServiceNow and the IDN API to request and provision access for these accounts.
How I generate PATs for these accounts depends on whether or not I want to bypass SSO.
If I am logging in using SSO
-
If we are to log in using SSO for these accounts, we have to set up 2FA for that user in Okta. This is not ideal from our perspective because we don’t typically own these accounts. I mentioned in another thread how the deprecation of strong auth limits our ability to selectively deploy MFA to users, and this is such a case
-
If this is the first time this account is logged in, I’m required to set up security questions or alternate contact info for strong auth. Again, not ideal to do this for an account I do not own.
-
Once logged in, I can go and generate a PAT for that user
If I was to bypass SSO
-
First, I need to reset the password for that identity. This would be much more difficult if we had emails going directly to the user, but thankfully in our case, we have them all going to a single support mailbox. This would not be possible if we had emails going directly to users and the Service Account didn’t have a mailbox. Mail-enabled service accounts are in the minority in my org.
-
Once a new password is set, I attempt to log in with the new credentials I’ve chosen. Last time I tried to do this, I could not log in and kept getting “Authentication Failed” error messages, leading to me becoming so frustrated I just generated application client creds.
-
If this is the first time this account is logged in, I’m required to set up security questions or alternate contact info for strong auth. Again, not ideal to do this for an account I do not own.
-
Once logged in, I can go and generate a PAT for that user
In my opinion, this involves far more steps than it should, and I would hope that it’s possible to allow admins to generate PATs for another user.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.