Add externalized user directory to secrets connector

[mandy-chessell]

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 the metadata-security module called OpenMetadataSecurityConnector. 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 the loading-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 in coco-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.

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.