You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When ParticipantContexts are created via IH's Identity API, it automatically creates an STS account (if STS is embedded in IH).
In doing so, a client_secret is generated (using a pluggable StsClientSecretGenerator). However, there currently is no way
to influence the alias, under which the client_secret is stored in the Vault, instead, it is hard-coded to "<participant-id>-sts-client-secret".
This is obscure, and could theoretically cause collisions in the Vault.
Which Areas Would Be Affected?
ParticipantContext API
Why Is the Feature Desired?
Configurability, avoid collisions in the Vault
Solution Proposal
Add to the ParticipantManifest a map of extensible properties
The text was updated successfully, but these errors were encountered:
Feature Request
When
ParticipantContexts
are created via IH's Identity API, it automatically creates an STS account (if STS is embedded in IH).In doing so, a
client_secret
is generated (using a pluggableStsClientSecretGenerator
). However, there currently is no wayto influence the alias, under which the
client_secret
is stored in the Vault, instead, it is hard-coded to"<participant-id>-sts-client-secret"
.This is obscure, and could theoretically cause collisions in the Vault.
Which Areas Would Be Affected?
ParticipantContext API
Why Is the Feature Desired?
Configurability, avoid collisions in the Vault
Solution Proposal
Add to the
ParticipantManifest
a map of extensible propertiesThe text was updated successfully, but these errors were encountered: