To make Privileged Task Automation (PTA) easier to adopt, Parameter Storage introduces a built-in, secure store within Identity Security Cloud. It removes the need for external vaults and lets credentials and configurations be entered once and reused across PTA actions—simplifying setup, enhancing security, and lowering barriers to adoption.
Privileged Task Automation (PTA) relies on Credential Providers to supply credentials for PTA Actions. This setup requires both a Credential Provider license within Identity Security Cloud (ISC) and an external Vault or Privileged Access Management (PAM) system.
While the Credential Provider license now comes bundled with PTA, customers still need access to a parameter store or vault to securely manage credentials. For those without an existing vault, this creates a challenge and represents a barrier for PTA adoption. In this case, their options are limited to:
Partnering internally: locating another team already using a vault and negotiating shared access, which can be slow, uncertain and comes with political barriers as vaults are protected by territorial boundaries.
Purchasing a vault: typically from a PAM vendor, which may be too complex or costly for their needs.
Parameter Storage will remove this barrier by providing a built-in, secure store within ISC for PTA credentials. Additionally, Parameter Storage allows customers to store a repeated configuration item so that it does not have to be entered by the customer multiple times. The use of Parameter Storage will allow a single entry that can be referenced multiple times. This native solution simplifies setup, enhances security, and enables customers to adopt PTA without the complexity of external vault infrastructure.
Problem
PTA requires the use of Credential Providers to supply PTA Actions with credentials. This requires both a Credential Provider license in ISC and an external Vault system/PAM of some kind.
Solution
The Identity Security Cloud Parameter Storage offers a native, secure store for SailPoint credentials and other parameters directly within ISC. This tool enhances security and simplifies management by allowing credentials, configurations and other parameters to be entered once and referenced multiple times, eliminating the need for repeated manual entry. Parameter Storage enables smoother adoption of Privileged Task Automation without the complexity or expense of external vault infrastructure, making it an ideal choice for customers looking to streamline their privileged access management.
For existing PTA admins/users: Review your current PTA Workflows to identify opportunities where repeatedly used credentials or connection configuration could be moved into Parameter Storage.
For new implementations: Configure credentials and connection configuration in Parameter Storage, prior to configuring new Workflows containing PTA actions.
Is there any plans to roll this out for sources as well? It would be nifty to be able to store the parameter in the username/password fields for example with Active Directory sources and the like.
Especially in the cases when you have to switch clusters which is a pain due to the clearing of passwords/usernames.
@KevP Thank you for the detailed explanation. I’ve observed that the feature is available in my Sandbox environment as “Parameter Storage” under Global Settings.
I was wondering if there are any plans to expand this functionality to support connection settings for direct connector sources and workflows as well. This would be a highly impactful enhancement, as managing credentials separately for each source and workflow can be quite time-consuming. Consolidating this process would make the module even more powerful and efficient. Also, I completely agree with @Crimson3708 here.
Yes absolutely. We have built Parameter Storage to be a platform wide service that, in time, other aspects of ISC will integrate with and allow the current parameter types, and more in the future, to be stored.
We’ve released with Workflow PTA Actions first but others will follow.
The credentials stored in Parameter Storage can be selected in the configuration of the Workflow actions that support Parameter Storage. Currently the Active Directory, Azure and Windows Server actions support Parameter Storage. More will follow, including the HTTP Action.
Out initial release of Parameter Storage is to support Workflow PTA actions, but we have built Parameter Storage as a platform service so other parts of ISC will start to support it over time.
This is great to hear! I second the comments that being able to use stored parameters in Sources and Workflows will be a boon.
As you see it today, will there be announcements as more and more Workflow actions and other parts start to support Parameter Storage? Or will they be mentioned in Release Notes only?
I read the title and thought this was about Pass-Through Authentication (PTA). It would have been nice if SailPoint is using different acronyms for different concepts.
I agree with the others saying that the main hassle is configuring credentials to workflows, especially for HTTP actions to call ISC API’s itself. After all, workflows is being used way more than the PTA bit. It is strange that for in-build actions like “Get Identity” no credentials are required, while calling any ISC API would require them. I think dedicated actions like “Call internal ISC API” and “Trigger child workflow” that don’t require credentials like “HTTP Request”, but would work in a different more elegant way could perhaps resolve this issue better. But perhaps this parameter storage could be a nice workaround in the meantime.
This Parameter Storage functionality is not complying to the Zero Trust paradigm right? I would be interested to see a SailPoint whitepaper demonstrating why we can deduce that this functionality is secure, or if we should just trust it to work in a secure manner. Where is it stored, how and where is it encrypted using which keys and where does it go in transit?
I see screenshots of this parameter storage, but I am missing screenshots showing how to use those and I am missing a documentation.sailpoint.com link to this functionality.
Announcements will be made as more actions support Parameter Storage. In time this will grow to include HTTP Actions and other product areas like Sources, NERM, DAS etc.
Just curious: does it include variable storage for HTTP actions (e.g., client_id, secret, and endpoint URL) so we can reuse them across multiple workflows?
@rahulks88 we are preparing an informal Early Access starting Feb 01. Can you contact me directly to let me know if your organization is interested in participating?
@tburt@KevP Could you please clarify whether the rollout of parameter storage for use in HTTP workflow actions has been released across all ISC tenants (Sandbox and Production)?
We’ve noticed this feature is available for exploration and configuration in DevRel demo tenants under “OAuth 2.0 Parameter“ section, but it does not appear in our client’s environment.
As we have a production deployment approaching soon, it would be very helpful to know if this option will be made available shortly, or if you could share a tentative timeline for its release in client Sandbox & Prod tenants so we can plan accordingly.
This is a limited early access. Customers will begin to see this in staging/dev environments early March with Production segments enabled by end of march.
To make Privileged Task Automation (PTA) easier to adopt, Parameter Storage introduces a built-in, secure store within Identity Security Cloud. It removes the need for external vaults and lets credentials and configurations be entered once and reused across PTA actions—simplifying setup, enhancing security, and lowering barriers to adoption.
