<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D54z00009M85VQCAZOkta Identity EngineWorkflowsAnswered2025-10-27T09:00:35.000Z2023-06-19T15:51:54.000Z2023-07-17T21:16:10.000Z

dye4h (dye4h) asked a question.

Edited June 19, 2023 at 3:54 PM
Okta Workflow pass password value in Compose function

We have a requirement where we have to invoke SOAP API.

We are composing the XML input where we have put username and password values then doing the SOAP call by using API Connector Post, the problem is that password is visible in the workflow compose function that should be in password format.

So do we have any option to hide that password or can we pull that username and password from any global variable?

 

Image is not available

  • 7 answers
  • 856 views

  • TimL.58332 (Workflows)

    @dye4h (dye4h)​  - The short answer is: no

     

    Long Answer:

     

    Couple things to keep in mind.

     

    • Workflows console is only accessible by Super Admins which typically are already privy to information such as the user/pass.
    • When Workflows communicates to the third-party endpoint it is going to be done over HTTPS which means the plain text that is required in the flow is going to be encrypted prior to transmit.

     

    Currently, there is no means to not have the password in plain text at some point in the process. What you "can" do to limit exposure (Which can still be reversed but is a little more secure) is the following:

     

    1. Create a flow with the sole purpose of "encrypting" the login SOAP xml
    2. In your production flow set history to not be recorded
    3. Add a decrypt card containing the cipher text with the required "key/password"
    4. Set the output of the decrypt card to the compose card

     

    This way at a glance the "login" information is never stored in plain text. However, the "key" needed to decrypt the ciphertext will need to be in plain text. So someone with access (and a little understanding) could potentially use it to decrypt the value. But since the compose card only will show the variable for the output of the cipher text it won't be super obvious what the data is.

     

    Note: I haven't directly tested this but it theoretically should work.

     

    Expand Post
    Selected as Best

  • TimL.58332 (Workflows)

    @dye4h (dye4h)​  - The short answer is: no

     

    Long Answer:

     

    Couple things to keep in mind.

     

    • Workflows console is only accessible by Super Admins which typically are already privy to information such as the user/pass.
    • When Workflows communicates to the third-party endpoint it is going to be done over HTTPS which means the plain text that is required in the flow is going to be encrypted prior to transmit.

     

    Currently, there is no means to not have the password in plain text at some point in the process. What you "can" do to limit exposure (Which can still be reversed but is a little more secure) is the following:

     

    1. Create a flow with the sole purpose of "encrypting" the login SOAP xml
    2. In your production flow set history to not be recorded
    3. Add a decrypt card containing the cipher text with the required "key/password"
    4. Set the output of the decrypt card to the compose card

     

    This way at a glance the "login" information is never stored in plain text. However, the "key" needed to decrypt the ciphertext will need to be in plain text. So someone with access (and a little understanding) could potentially use it to decrypt the value. But since the compose card only will show the variable for the output of the cipher text it won't be super obvious what the data is.

     

    Note: I haven't directly tested this but it theoretically should work.

     

    Expand Post
    Selected as Best

    • TimL.58332 (Workflows)

      I did go ahead and test and as you can see the hashed value of the initial compose card and of the hashed value of the output of the decrypted ciphertext are equal:

       

      image

  • TimL.58332 (Workflows)

    Quick add - There is a "key vault" that has been on the roadmap for a time that may address many of these types of concerns. I am not sure how far along it is and there is no "release date" for it.

  • 75b93 (75b93)

    Another Option would be to use the "Connection Builder" to create your own "Connection" of sorts. From there you can create a "Connection" to it with your password that will be hidden.

  • TimL.58332 (Workflows)

    @75b93 (75b93)​ 

     

    Definitely can. It runs into the same issue however as it is still going to need to be saved in either plain text or ciphertext with a plaintext key for decryption somewhere in the process. Both connector builder and Workflows require an admin to Access. So "If" an admin can access it the value will be visible.

     

    The ONLY way I can think of to 100% not expose anything would actually be a Delegated flow with Flow History turned off. It would be manual executions and you would have to supply the password (or possibly user/pass) as part of Delegated Flow inputs.

    Expand Post

  • 75b93 (75b93)

    @TimL.58332 (Workflows)​ Interesting, are you saying that Admins have access to the Auth Parameters that are of type "Password"?

    Image is not available
    (I guess I'm also assuming the username and password are static for this SOAP API call)

    Expand Post

    • TimL.58332 (Workflows)

      @75b93 (75b93)​  -

       

      I guess I was misunderstanding what you were initially indicating. I thought you meant defining it statically in the flow structure of a connector builder connector. Then when you build the connector it is essentially "Wrapped" in Workflows but the values would still be visible if you accessed the connector builder.

       

      The method you defined may work for a standard auth challenge. Inputs as defined in that structure when you build the "Connection" would be invisible and would not be retrievable as they are dropped on a reauth.

       

      However, based on the initial screenshot I had assumed the value was a body structure being passed to the endpoint that is likely required with each payload. I've seen similar in both REST and SOAP endpoints. Auth+Content all required in the body of a POST/PUT.

      Expand Post
This question is closed.
Loading
Okta Workflow pass password value in Compose function