Hi All,
I need to generate the PAT for service account but I don’t have the access to this account to login to the tenant.
Is there any way to get this? It is possible to generate the PAT ID without user invite?
Thanks,
Shantha Kumar
2 Likes
Did there any way to create Service account in sailpoint?
1 Like
Hello Shantha,
Please check this page: Service Accounts
I believe you do need to invite the service account and create the PAT from the SA itself.
Is there way to get it without inviting the Service account??
1 Like
I don’t think that is possible currently.
I don’t think they need to be invited but you will need to login and create the PAT for use in the usual authentication flow
1 Like
I don’t think this is possible .
I think ISC should have given the better option for managing these token especially for the internal HTTP calls .( calls within the ISC system itself).
1 Like
Agree. It’s time consuming when it comes to the configuration to create that internal / same tenant / loopback HTTP call step, and the PAT management / reporting / certification(lack of?) capability is far from ideal.
I agree it time consuming setting up the PAT but it does help when things go wrong to narrow down the service account in use etc.
It sounds like you would get a couple of votes if you create this on the Ideas Portal!
1 Like
2 Likes
The whole purpose of PAT is to authenticate a user and carry out operations based on access/rights specific to the PAT.
If you are able to create a PAT for an account that you don’t have access to then you will be defeating the purpose of PATs
Totally understand ,
if you want to perform some HTTP call from workflow itself i see no point of adding actor as individual identity despite it should say system or some service account . now how to create these service account PAT and how to manage those .
thats why i think Sailpoint should give some better option to handle this and i think this would be common for many other clients and users .
If you are referring to any of the OOTB actions in workflow, such actions are carried out using PAT of the identity that is assigned as owner of the workflow. In my opinion, this is also not a good approach as you can assign any identity as the owner, and send GRANT_ACCESS requests from inside the workflow. (only relief is that the workflows can be created or modified by ORG_ADMINs only which means there is some kind of ownership)
But, submitting a HTTP Request in Workflow is identical to submitting an API request from any API client (like Postman, etc) and allowing to do so using someone else’s PAT should be a total NO NO according to my opinion
Cheers!!
Yes we shouldn’t allow someones else PAT to be used by others . the whole point which need to be solved is that how to manage the PAT custom call made inside the workflow .
I don’t see points of using PAT for HR identity to be used to HTTP calls inside workflow . it should be the service account PAT , now then question is if you use SA PAT how to manage the credentials ? This need to be solved and i think this would be problem for each and every client.
1 Like
Yes I managing PAT tokens are a challenge, we generally restrict this in our workflow creation to only using certain accounts (service accounts) to do this and store the credentials in our PAM solution.
What we are missing is the ability to cycle the credentials, which is achievable if you are using certain PAM solutions, an OOTB way to manage these that is independent of PAM vendors would be nice.
Just to clarify: I’m not saying you should get rid of PATs. You still need AM on APIs for sure. The focus of the issue is the management of and specifying the PATs in workflows. It’s like you have to specify the same PATs multiple times ; once in each step.
Instead, there should be some kind of a PAT reference, to a Workflow PAT wallet (or some credential store / PAM store). Such that at the HTTP action step, I just need to specify Use PAT “xyz” from wallet / PAM store “workflow creds store 123”. The kicker here, is that, well, ISC is the caller and PAT authentication service party…it’s a loopback. From a configuration perspective, ISC is its own cred store. I should, ideally, just need to specify which existing PAT to use from the HTTP Action step configuration form, select from a drop down.
i.e. ISC’s PAT store is a PAM store for itself. Add some PAT reference scoping (e.g. if I’m not an admin, I shouldn’t be able to reference / select other people’s PAT, for example).
This would be a nice option, fully agree - I suppose the issue with this would be ownership of the store but doable.
Yes this will be an nice option if it comes into live.
1 Like