A Registry Server is intended to represent one physical or logical server referenced by the CO. While various Registry configuration objects reference Server objects, they need not be (and so the Server Registry can be used to track endpoints of interest to the CO, whether or not they are used by COmanage Registry specifically).

On this page



See also


How Registry Servers Work

Registry Servers hold configuration information for how to connect to other systems. When configured for COmanage Registry's use, these servers contain instructions on how Registry Objects (like Sources or Provisioners) connect to other systems to interact. There are several supported types of servers in Registry as shown to the left.

Establishing Servers in Registry

To add or edit servers, an administrator must navigate to the 'Servers' selection in the left menu of COmanage Registry for your CO. Click the "Add a New Server" link above the servers list on the right side to add a new server, or click the "Edit" or "Configure" button next to an existing server to edit it.

Each Registry Server includes the following metadata fields. These fields may be edited by using the "Edit" button next to the server name.

  • Description — Usually used for the name of the server configuration.
  • Status — Servers may either be active or suspended. Suspended serves maintain the saved configuration, but are not available for use by other objects within the Registry
  • Type — Servers may be one of several different types. A list of supported types can be found to the left.


Once a new Server has been added, Server Type-specific configurations need to be set. Please see each server type on the right for more information about the specific set up information configured for each type.

Server Types

There are several types of servers that may be configured in COmanage Registry. Configurations may be edited by clicking the "Configure" button next to the server name. The "Configure" button is available after the Server metadata has been saved (the server has been established).

HTTP

HTTP server types may be used for general API calls. It includes the following configuration values

  • Server URL *  — The HTTP URL to be used
  • User Name — User name to be used when accessing this resource, if applicable
  • Password or Token — the password of token to be used when accessing this resource, if applicable
  • HTTP Authentication Type * — May be Basic, Bearer, or None
  • Require certificate verification? — This this value is normally checked (true) to enable certificate verification, it may need to be disabled for self-signed certificates
  • Require name verification? — Enables verification when using this server. If checked (true), the name in the certificate must match the requested hostname.

Kafka

KDC

The KDC server configuration (added in v4.4.0) allows for connecting to a Kerberos key distribution center (KDC). This type of server is used with the KdcProvisioner Plugin (CO-515). The configuration values include:

  • Hostname: The hostname for the server.
  • Admin Server Hostname: The kadmin server hostname if different than KDC hostname.
  • Admin Server Port: The kadmin server port if different than the default port 749.
  • Realm: The Kerberos realm.
  • Principal: The principal used to connect to the admin server.
  • Keytab File Path: The path to the keytab file, which must be readable by the web server user.

Match

See the Integrating with Match ID for more details.

Match server types are used for connecting COmanage Registry to COmanage Match. It includes the following configuration values:

  • Server URL: The URL prefix for Match request. This should look something like https://match.university.edu/match/api/3/v1.
  • Username and Password: As configured.
  • SOR Label: As defined on the Match server, and in accordance with the model selected above. If the SOR per Source model is chosen, then a Match Server will need to be defined for each SOR Label. (Registry v4.0.x only)



In addition to the Match Server configuration, administrators will also configure the Match Attributes that will be exchanged between Match and Registry: 

OAuth2

The OAuth 2.0 server configuration allows for OAuth2-style connections. This type of server is used with the ORCID Source Plugin, and can be use with other OAuth2 connections. The configuration values include: 

  • Redirect URI: A value defined by Registry. This value should be included as one of the OAuth redirects when defining your client credentials for your OAuth 2 client.
  • Server URL * : The base URL for OAuth calls
  • Proxy: If OAuth calls are being exchanged through a proxy, you may need to include your proxy host in this configuration.
  • Client ID * : The Client ID provided for the OAuth client application
  • Client Secret * : The Client Secret provided for the OAuth client application
  • Access Token Grant Type * : This type may be Client Credentials to obtain an access token outside of the context of a user, or Authorization Code which is often used when seeks an authorization code for a specific user transaction.
  • Scope: the OAuth scope desired for the access token.

SQL


  • No labels