Skip to content

Open Metadata Security

Open Metadata Security is optional. When it is activated, it provides fine-grained authorization services for open metadata services, types and instances. Since each organization will have different security requirements, the security support is implemented through connectors. Egeria defines the interfaces and when it will call the connector. You define the behavior the connector implements, and Egeria acts on the returned decision.

Open Metadata Security Connectors

The connectors that support the security of the open metadata ecosystem are:

Secrets Stores

Secrets stores externalize secrets such as passwords, tokens and certificates so they do not need to be stored in either the configuration document or open metadata repositories.

Metadata security connectors

The metadata-security module defines the base classes and interfaces for the open metadata security connectors as well as the server implementation to host and call them.

There are two types of connector:

  • Platform metadata security connector - secures access to the administration and platform services. This includes the services to create new servers, the ability to start and stop servers as well as the ability to query whether a server is running, and if it is, what services are active.

  • Server metadata security connector - secures access to the specific services of an OMAG server. This includes access to the server's configuration document, starting and stopping the specific server, calling specific services, then within the server, access to specific Assets, Glossaries and Connections managed by the server, and finally the types and instances stored in the local repository.

The 2 types of connectors are shown in Figure 1:

Figure 1

Figure 1: positioning of the security connectors

Within an OMAG Server Platform there is one instance of the platform metadata security connector. This connector is configured either through the application.properties file before the platform is started, or using a REST API call once the platform is running.

Once it is in place, any call to the administration services or platform services results in a check to the platform metadata security connector.

The open metadata server security connector is optionally configured for each OMAG server, to allow for each server to have a different implementation.

The admin services command to configure a security connector for a server adds a connection for the server metadata security connector to the server's configuration document.

The platform and server metadata security connectors operate independently, depending on which service is called. However there is a hand-off whenever the server's configuration document is read, either as part of a configuration request, or a request to start the server.

As the request is received, the platform connector checks that the user has access to the platform. Assuming that is ok, the configuration document is read. If the configuration document contains the server metadata security connection, the connector is initiated using the connection. The server connector is then called to check that the calling user has permission to access the server.

This means that whenever the configuration document is called, the calling user has to have permission to access both the platform and the server. If the request is an administration service request, the user has to have administration access to the platform and server. If the request is to start the server, the user has to have operator access.

Figure 2

Figure 2: Calls to access a server's configuration document.

During a metadata and governance (OMAG) service call to a server, the security implementation in the server potentially invokes the server security connector multiple times as the request (shown as dotted white arrow) is handled by the server code. Figure 3 shows the different layers of checks. Each layer is optional and so the server security connector can be implemented to support the most appropriate granularity of security for the situation. Details of the implementation choices are given in the security connector API.

Figure 3

Figure 3: layers of security checks within the server

The security connectors are optional. If they are not defined then there are no additional authorization checks performed inside the OMAG Server Platform nor the OMAG Servers hosted on the platform. As such, it is important that the open metadata platform security connector is configured as soon as the platform is started, and the server security connector is configured before the server is started for the first time.

Open Metadata Security Connectors in Egeria

Egeria has a single metadata security connector that implements both interfaces:

Metadata security APIs

  • OpenMetadataUserSecurity - support user authentication requests and management of user accounts.
  • OpenMetadataPlatformSecurity - secure requests to the OMAG Server Platform. Specifically the platform-services, admin-services, and server-operations.
  • OpenMetadataServerSecurity - secure any request to an OMAG Server.
  • OpenMetadataServiceSecurity - secure requests to specific OMAG Server's services.
  • OpenMetadataElementSecurity - secure requests to specific open metadata elements depending on their type, the requested operation, who created the element and the settings of their classifications such as Governance Zones or Ownership.
  • OpenMetadataRepositorySecurity - secure all requests to the open metadata repositories. This allows a repository to redact sensitive properties for specific users.
  • OpenMetadataEventsSecurity - secure sending and receiving of instance events between the open metadata repositories connected via an open metadata repository cohort. This allows a repository to withold sensitive instances from the rest of the cohort, or prevent local caching of specific instances.

Below is a description of the API of the two Open Metadata Security Connectors.

Open metadata platform security connector interface

The connector that plugs into the platform implements the following interface.

  • OpenMetadataPlatformSecurity - provides the interface for a plugin connector that validates whether a calling user can access any service on an OMAG Server Platform. It is called within the context of a specific OMAG Server Platform request. Each OMAG Server Platform can define its own plugin connector implementation and will have its own instance of the connector.

    • validateUserForPlatform - Check that the calling user is authorized to issue a (any) request to the OMAG Server Platform.
    • validateUserAsAdminForPlatform - Check that the calling user is authorized to issue administration requests to the OMAG Server Platform.
    • validateUserAsOperatorForPlatform - Check that the calling user is authorized to issue operator requests to the OMAG Server Platform such as starting and stopping servers.
    • validateUserAsInvestigatorForPlatform - Check that the calling user is authorized to issue requests for information to the OMAG Server Platform. For example, to validate a connector or request lists of registered services.

Open metadata server security connector interface

The connector that can be defined for an OMAG Server offers a series of layers of security checks. An organization can choose which layers to make use of and which to allow all requests to pass. Figure 2 shows the layers. Each layer is implemented in a separate interface and the connector can choose which interfaces to implement. Below are the interfaces and methods for the different layers:

OpenMetadataServerSecurity

OpenMetadataServerSecurity provides the root interface for a connector that validates access to Open Metadata services and instances for a specific user. There are other optional interfaces that define which actions should be validated.

  • validateUserForServer - Checks that the calling user is authorized to issue a (any) request to the OMAG Server.
  • validateUserAsServerAdmin - Checks that the calling user is authorized to update the configuration for a server.
  • validateUserAsServerOperator - Checks that the calling user is authorized to issue operator requests to the OMAG Server.
  • validateUserAsServerInvestigator - Checks that the calling user is authorized to issue operator requests to the OMAG Server.

OpenMetadataServiceSecurity

OpenMetadataServiceSecurity provides the interface for a plugin connector that validates whether a calling user can access a specific metadata service. It is called within the context of a specific OMAG Server. Each OMAG Server can define its own plugin connector implementation and will have its own instance of the connector. However, the server name is supplied so a single connector can use it for logging error messages and locating the valid user list for the server.

  • validateUserForService - Checks that the calling user is authorized to issue this request.
  • validateUserForServiceOperation - Checks that the calling user is authorized to issue this specific request.

OpenMetadataElementSecurity

OpenMetadataElementSecurity implements security rules based on the elements being accessed. It is the interface that decides what a user may do with a particular metadata element, taking account of the element's type, the operation requested, who created it, and the settings of its classifications - such as its governance zones or ownership.

The checks divide into three groups.

The first group covers operations on an element in its own right:

  • validateUserForElementCreate - Can the user create this element?
  • validateUserForElementRead - Can the user have read access to this element and its contents?
  • validateUserForElementDetailUpdate - Can the user update the properties of this element?
  • validateUserForElementStatusUpdate - Can the user update the status of this element?
  • validateUserForElementAttach - Can the user link unanchored elements to this element?
  • validateUserForElementDetach - Can the user remove those links?
  • validateUserForElementAddFeedback - Can the user attach feedback - comments, ratings, tags and likes - to this element?
  • validateUserForElementDeleteFeedback - Can the user remove that feedback?
  • validateUserForElementClassify - Can the user add or update a classification on this element?
  • validateUserForElementDeclassify - Can the user remove a classification from this element?
  • validateUserForElementDelete - Can the user delete this element and all of its contents?

The second group covers elements that are anchored to another element - the terms and categories of a glossary, or the schema and connections attached to an asset - where the authority to act comes from the anchor rather than the member:

  • validateUserForAnchorMemberCreate - Can the user create new elements as members of this anchor?
  • validateUserForAnchorMemberAdd - Can the user add an element as a member of this anchor?
  • validateUserForAnchorMemberRead - Can the user have read access to a member of this anchor?
  • validateUserForAnchorMemberUpdate - Can the user update elements attached directly to this anchor, such as its glossary terms or attached assets?
  • validateUserForAnchorMemberStatusUpdate - Can the user update the status of a member?
  • validateUserForAnchorMemberDelete - Can the user delete a member and all of its contents?
  • validateUserForAnchorAttach - Can the user link unanchored elements to this anchor?
  • validateUserForAnchorDetach - Can the user remove those links?
  • validateUserForAnchorAddFeedback - Can the user attach feedback to this anchor or one of its members?
  • validateUserForAnchorDeleteFeedback - Can the user remove that feedback?
  • validateUserForAnchorClassify - Can the user add or update a classification on this anchor or one of its members?
  • validateUserForAnchorDeclassify - Can the user remove a classification from this anchor or one of its members?

The third is a single method that makes a choice rather than a yes/no decision:

  • selectConnection - Chooses which connection should be supplied to the requesting user from those available. A connection may carry credentials that grant far more access to the resource than the requesting user is approved for, which is why the choice is made by the security connector rather than by the service returning it.

OpenMetadataRepositorySecurity

OpenMetadataRepositorySecurity defines security checks for accessing and maintaining open metadata types and instances in the local repository. An instance is an entity or a relationship. There is also a special method for changing classifications added to an entity.

  • validateUserForTypeCreate - Tests for whether a specific user should have the right to create a typeDef within a repository.
  • validateUserForTypeRead - Tests for whether a specific user should have read access to a specific typeDef within a repository.
  • validateUserForTypeUpdate - Tests for whether a specific user should have the right to update a typeDef within a repository.
  • validateUserForTypeDelete - Tests for whether a specific user should have the right to delete a typeDef within a repository.
  • validateUserForEntityCreate - Tests for whether a specific user should have the right to create an instance within a repository.
  • validateUserForEntityRead - Tests for whether a specific user should have read access to a specific instance within a repository. May also remove content from the entity before it is passed to caller.
  • validateUserForEntitySummaryRead - Tests for whether a specific user should have read access to a specific instance within a repository.
  • validateUserForEntityProxyRead - Tests for whether a specific user should have read access to a specific instance within a repository.
  • validateUserForEntityUpdate - Tests for whether a specific user should have the right to update an instance within a repository.
  • validateUserForEntityClassificationUpdate - Tests for whether a specific user should have the right to update the classification for an entity instance within a repository.
  • validateUserForEntityDelete - Tests for whether a specific user should have the right to delete an instance within a repository.
  • validateUserForRelationshipCreate - Tests for whether a specific user should have the right to create an instance within a repository.
  • validateUserForRelationshipRead - Tests for whether a specific user should have read access to a specific instance within a repository. May also remove content from the relationship before it is passed to caller.
  • validateUserForRelationshipUpdate - Tests for whether a specific user should have the right to update an instance within a repository.
  • validateUserForRelationshipDelete - Tests for whether a specific user should have the right to delete an instance within a repository.
  • validateEntityReferenceCopySave - Tests for whether a reference copy should be saved to the repository.
  • validateRelationshipReferenceCopySave - Tests for whether a reference copy should be saved to the repository.

OpenMetadataEventsSecurity

OpenMetadataEventsSecurity defines security checks for sending and receiving events on the open metadata repository cohorts. Implementing this interface means the security connector is called every time an event is about to be sent to, or has just been received from, a cohort topic. Both methods are given the name of the cohort and the contents of the event, and each has three possible outcomes: return the event unchanged, return a modified event with sensitive content removed, or return null to filter the event out entirely.

  • validateInboundEvent - Validates whether an event received from another member of the cohort should be processed by this server. May also remove content from the event before it is processed by the server.
  • validateOutboundEvent - Validates whether an event should be sent to the other members of the cohort by this server. May also remove content from the event before it is sent to the cohort.

This is what allows a repository to withhold sensitive instances from the rest of the cohort, or to prevent instances it receives from being cached locally.

Sample connectors

Implementations of the security connectors are supplied in the metadata-security-connectors module

Raise an issue or comment below