Add externalized user directory to secrets connector #8421
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR extends the secrets store connectors to support a user directory. This user directory can support user authentication and issuing of a bearer token for use on view server requests. It replaces the "demo" authentication that used a yaml file of coco users that was baked into the platform build.
The environment variable secrets store connector does not support the user directory. This is because it would be ridiculous to setup a separate environment variable for each user property. However, the YAML Secrets Store Connector has been updated to support the user directory.
There is a new sample metadata security connector that covers authorization for the platform and the server called
CocoPharmaSecretsSecurityConnector
. It uses a new base class from themetadata-security
module calledOpenMetadataSecurityConnector
. Together they work with an embedded secrets connector.The
application.properties
files have been updated to use this new authentication method for the platform.CocoPharmaSecretsSecurityConnector
is configured as the platform security connector, along with a simple user directory for gary geeke, peter profile and erin overview, which is found in theloading-bay/secrets/demo-user-directory.omsecrets
file.The default servers have not yet been updated to use the new security connectors.
The base class for connectors,
ConnectorBase
, has new methods for logging that log to the audit log for connectors running in a server, and to stdout for connectors running outside of the server environment where there is no audit log. This simplifies the code for connectors which may be running both inside a server and outside (like in the platform, or an external client). It is being used by the security connectors described above. Over time, all of the resource connectors will use the new methods as well.Related Issue(s)
There is still a problem with extracting securityRoles and securityGroups from the YAML. If their values are supplied there is a YAML parsing error. As such there are currently two user directories installed in the platform distribution. In addition to
demo-user-directory.omsecrets
, there is a fuller list of coco users incoco-user-directory.omsecrets
which exhibits the loading error.Testing
Manual testing with the coco user directory. This initial PR has been raised so that the basic function can be tested in the
egeria-workspaces
container environments.Release Notes & Documentation
Updates need to be made to the YAML secrets connector description and the metadata security connectors description to cover the new capability.
In addition this change is part of a wider update the Egeria's security support which will be reflected in the docs ...
Additional notes
This work is the final stage in consolidating the security plug-in support into two connectors:
The secrets store connector for user information and secrets. The YAML implementation is for demos and testing since it is easy to modify the user information in the
egeria-workspaces
environment. We will soon build new versions for LDAP and keycloak. Other implementations may come later.The metadata security connectors for authorization of access to open metadata resource. Initially there were separate connectors for platform and for the servers. This was assuming that the platform was run by a cloud service provider and the servers were for different cloud tenants. The new consolidated security connector is for organizations that are running their own platforms/servers. It uses information from the secrets store. In later PRs, we will add support for built in policies around metadata authorization to allow this function to be configured rather than coded.
The broad aim of the consolidation is to simplify the design of security for an egeria deployment. For many organizations, the supplied implementations may be sufficient. However, if they need to create their own connector implementations, it can be implemented from a single coherent design.
Spring security
Spring security is still in use as the framework to call these connectors for authentication in the platform. However, the spring security plugins for LDAP etc are no longer needed. The enablement for these plugins is still in the code but no longer advertised in
application.properties
. This is because the spring security implementation made it hard to link the authentication behaviour with the authorization behaviour. Once we are sure of the new connector structure, support for the spring security plug-ins will be removed.