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
After it is possible to read an extension's configuration file and pass that information to the Security plugin, we will need to generate a password for the extension to then use for the creation of its auth header. The password will be used for basic authentication of the service account associated with the extension and should not be stored in the Security plugin. Instead, the password should be immediately hashed and the hash stored as part of the service account details. The password will then be sent back to core where it can be handed to the extension.
Completion of this issue will look like a PR which generates a password for an extension's service account, hashes it, and then stores the hash and sends the password back to core.
The text was updated successfully, but these errors were encountered:
[Update 4/11] I am working on this in tandem with the token generation issue here. I believe I have found a bearer auth based solution which will avoid requiring passwords for the service accounts. That being said, I am running into some trouble storing the token information for revocation. We don't want to store it in the security index since it is not a configuration file based map. I have not found any other examples in the security plugin which don't use the CType pattern, so working on it.
After it is possible to read an extension's configuration file and pass that information to the Security plugin, we will need to generate a password for the extension to then use for the creation of its auth header. The password will be used for basic authentication of the service account associated with the extension and should not be stored in the Security plugin. Instead, the password should be immediately hashed and the hash stored as part of the service account details. The password will then be sent back to core where it can be handed to the extension.
Completion of this issue will look like a PR which generates a password for an extension's service account, hashes it, and then stores the hash and sends the password back to core.
The text was updated successfully, but these errors were encountered: