[MGNLRESTCL-113] Hide sensitive information from the rest call definiton query parameters / headers / etc. Created: 03/Dec/19  Updated: 19/Feb/20  Resolved: 21/Jan/20

Status: Closed
Project: REST Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0

Type: Improvement Priority: Neutral
Reporter: Jaroslav Simak Assignee: Jaroslav Simak
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 0d
Time Spent: 7.5h
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLRESTCL-114 Removing redundancy from configuratio... Closed
supersession
supersedes MGNLRESTCL-89 Securely store API key Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: Declarative REST clients
Sprint: Declarative REST 14, Declarative REST 15
Story Points: 3

 Description   

As a developer, I want to use values stored in the Password Manager in my REST calls, so that I can connect to APIs but not expose my API keys or secrets.

Acceptance criteria

  • I can use values from the password manager 
  • In a header, parameter, path or body of REST call

Context

Many API's expect a text API key (sometimes called a secret or an API token) to be provided somewhere in the REST call. 

For example: 
http://api.openweathermap.org/data/2.5/forecast?q=London,us&APPID=11c86e6e92231833a10604185a855418

Notes

While working on the DRC presentation, i had configured api tokens in the rest call's headers - this might be a security issue for some users.
I suggest to add an improvement, that would use password manager to hide the sensitive information. We could use a placeholder with password: prefix to denote that the value should be read from password manager and replaced with the password.

Example:

baseUrl: https://example.com
restCalls:
  foo:
    headers:
      api_key: {@password:<UUID>}


 Comments   
Comment by Christopher Zimmermann [ 07/Jan/20 ]

jsimak Please review story and AC from related/superceded ticket and let me know if this ticket will not cover all of them - https://jira.magnolia-cms.com/browse/MGNLRESTCL-89

Comment by Jaroslav Simak [ 07/Jan/20 ]

This ticket will cover all cases in MGNLRESTCL-89 - this one is a duplicate (my bad, i should have known that there is already such ticket).

Comment by Jaroslav Simak [ 07/Jan/20 ]

Also, there is a proposal from thien.quach to use {@password:<uuid>} instead of {password:<uuid>} to denote that the password prefix is something special.

Comment by Christopher Zimmermann [ 07/Jan/20 ]

Great - looks good. @password sounds good to me too.

Comment by Christopher Zimmermann [ 04/Feb/20 ]

Please add a comment describing how to use this feature, or what was done.

Comment by Jaroslav Simak [ 04/Feb/20 ]

Implemented as described in description - password template ({@password:<passwordIdentifier}) can be now used in path, queryParameters, headers, cookiesbody and in basic security scheme (for username and password).

Generated at Mon Feb 12 10:43:21 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.