[
https://issues.apache.org/jira/browse/KNOX-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17274259#comment-17274259
]
Mark Egloff commented on KNOX-2534:
-----------------------------------
I strongly agree to this request that the "client secret" have to be protected
at the storage layer.. The OAuth Standard writes about this as follows
[Extracted from the url below]
[https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/#:~:text=Client%20Secret,of%20the%20server%20generating%20it].
*Client Secret*
The client_secret is a secret known only to the application and the
authorization server. It must be sufficiently random to not be guessable, which
means you should avoid using common UUID libraries which often take into
account the timestamp or MAC address of the server generating it. A great way
to generate a secure secret is to use a cryptographically-secure library to
generate a 256-bit value and converting it to a hexadecimal representation.
*Storing and Displaying the Client ID and Secret*
For each registered application, you’ll need to store the public client_id and
the private client_secret. Because these are essentially equivalent to a
username and password, *you should not store the secret in plain text, instead
only store an encrypted or hashed version*, to help reduce the likelihood of
the secret leaking. [...]
> Allow alias to be used in pac4j topology block
> ----------------------------------------------
>
> Key: KNOX-2534
> URL: https://issues.apache.org/jira/browse/KNOX-2534
> Project: Apache Knox
> Issue Type: Improvement
> Components: KnoxSSO
> Reporter: Michael Boulter
> Priority: Minor
>
> We currently use Knox to authenticate users with Microsoft via pac4j
> federation config.
> We have an OIDC client secret (oidc.stored) stored in plaintext in the
> topology file but we'd like to obfuscate and not have the plaintext value in
> the topology XML.
>
> This is because OAuth strongly recommends to have the "client secret"
> protected.
>
> The alias service currently only seems to work for LDAP, it would be good if
> we could use it inside our pac4j block too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
