3 Authentication and Authorization

The MA security defines the communication authorization and authentication. Authentication includes tasks such as configuring the credential store and aliases for scripts in the AdminClient. Authorization includes tasks for network and server configuration.

All the security configurations and services are common to MA-based servers. These servers authenticate, authorize, and secure access to command and control, monitoring, data conveyance, and information service interfaces for the MA.

Oracle GoldenGate Microservices define an infrastructure for building service-aware applications to operate and integrate into global, cloud-based deployment environments. Oracle GoldenGate server programs are implemented using the microservices infrastructure. All security and configuration implementations provided by MA are common services.

• Authentication
  Learn how you can use identity authentication.
• Authorization
  Learn how you can use authorization modes.
• Authentication and Authorization for WebSockets
  Learn how you can use WebSocket authentication and authorization.
• Response Status Codes
  A few of the MA HTTPS authentication and authorization error codes are:

3.1 Authentication

Learn how you can use identity authentication.

The goal of the authenticated identity design is to establish identity authentication between users, an MA server or application, and an MA server. The authentication design relies on either the validity of a certificate or of a user credential (username and password pair).

The MA servers publish REST service interfaces that enable users and applications to request services including operational control over one or more MA deployments, service administration, status, and performance monitoring.

Description of the illustration ggcon_ap_001.png

The following types of certificates are used for authentication:

• User Certificate: A User Certificate is a certificate issued to a specific user. Oracle GoldenGate client applications store the User Certificate in a user Oracle Wallet. The default location of the user Oracle Wallet is under the user's home directory. Service requests issued with User Certificates include the user name and group information acquired from the host environment. This information identifies the real user executing the application.

• Application Certificate: An Application Certificate is a certificate issued to a specific application. The Application Certificate is stored by the application. Oracle GoldenGate client applications store the Application Certificate in an application Oracle Wallet designated by the Application configuration. The default location of the application Oracle Wallet is in the $OGG_SSL_HOME directory.

• Server Certificate: A Server Certificate is a certificate issued to a specific MA server. The Server Certificate is stored by the MA server in the server's Oracle Wallet. The default location of the server Oracle Wallet is under the server's installation directory. An MA server is authenticated to applications as the identity described in the Server Certificate.

• User’s or Application’s Database Authentication: MA servers support Service Interface request whose fulfillment requires logging into a source or target database. Database actions from an MA Server are limited to specific operations required to fulfill service request requirements. The following table describes the type of authentication that are supported by MA servers:

  Type of Authentication	Description
  OS Authentication	This configuration sets the OS server to establish connections to the database using its own credentials as the only authenticated user. All service requests requiring database access use the MA server database session. Database operations are logged as originating from the MA
  OS authentication with database proxy support	This type sets the MA server to establish connections to the database using its own credentials but support proxy user sessions, through an MA server authenticated connection. Proxy support is configured using: User Name or Distinguished Name.
  Pass-thru database authentication	This configuration sets the MA server to establish a session or connection to the database using the client provided user name and password.
  User-alias database authentication	This configuration sets the MA server to establish a session or connection to the database using a client provided alias ID that is mapped to a credential, held by the MA server, to establish a session or connection to the database.

Example: Using Oracle UTL_HTTPS Authentication as a Client

In database sharding, the user and application authentication model also applies to database packages that support issuing REST Server Interface requests to MA servers. Depending on the security configuration of the MA server, packages or procedures that use the UTL_HTTPS Oracle Database package may need to configure the client database security environment to enable the use of Client-side certificates for authentication in UTL_HTTPS. Self-written applications can similarily use UTL_HTTPS for the authentication as a client.

To enable UTL_HTTPS to use client-side certificates:

1. Configure the database client Oracle Wallet, see Creating the Wallet and Adding a Master Key.

2. Configure UTL_HTTPS with TLS (SSL) for client-side authentication, see Using UTL_HTTPS.

Certificate Revocation List Authentication Support

MA servers supports Certificate Revocation List (CRL) checks as part of the authentication process. Although MA servers do not automatically query for updated CRLs, the MA infrastructure supports updating server CRL information at runtime without requiring the MA servers to restart, see TLS Certificate Revocation List Handling.

3.2 Authorization

Learn how you can use authorization modes.

Security Authentication Modes

The following is the list of supported security authentication modes that establish the authenticity of the entity presenting the authorization information. These are the available values that may be used when setting the /config/securityDetails/network/common/authMode security setting. This configurattion is available from the REST APIs to the metadata catalog. This mode is set when configuring an Oracle GoldenGate MA deployment.

See the Update Service Properties in the Oracle GoldenGate REST API guide.

Authorization Mode ID	Notes
server_only	Only validate Server certificates. The Server certificates are required. The Client certificates are ignored.
client_server	This is the default. Validate both Client and Server certificates. Both certificates are required.
clientOptional_server	Validate the client certificate if it is present, as it is optional. Validate the server certificate (it’s mandatory).

User Privileges

You can configure these security roles for users from the Administration Server, see Setting Up Secure or Non-Secure Deployments.

Role ID	Privilege Level
Security	Grants administration of security related objects and invoke security related service requests. This role has full privileges.
Administrator	Grants full access to the user, including the ability to alter general, non-security related operational parameters and profiles of the server.
Operator	Allows users to perform only operational actions, like starting and stopping resources. Operators cannot alter the operational parameters or profiles of the MA server.
User	Allows information-only service requests, which do not alter or affect the operation of either the MA. Examples of query and read-only information include performance metric information and resource status and monitoring information.

Note:

These are authorization privileges and are not directly related to authentication.

3.3 Authentication and Authorization for WebSockets

Learn how you can use WebSocket authentication and authorization.

REST API calls are made using standard HTTPS request and take advantage of the authorization mechanism described in the Hypertext Transfer Protocol (RFC2616). The WebSocket protocol (RFC6455) is different because it is a streaming-like interface so does not need authorization or require special handling. WebSockets can be governed with the standard HTTPS authentication and authorization mechanism.

Native HTTPS Authorization

The WebSocket handshake uses the HTTP upgrade header to change from the HTTP protocol to the WebSocket protocol. The MA server checks the authorization header to approve or deny the request based on whether the role associated with the requesting user is equal to or greater than the role assigned for WebSockets establishment requests.

Example 3-1

GET /chat HTTPS/1.1
Host: myserver.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: HTTPS://myserver.com
Sec-WebSocket-Protocol: ogg
Sec-WebSocket-Version: 13
Authorization: Basic xgfDE24sDwrasdbliop875ty=

3.4 Response Status Codes

A few of the MA HTTPS authentication and authorization error codes are:

The following response status codes are used:

• 1xx: Informal

• 2xx: Success

• 3xx: Redirect

• 4xx: Client Error

• 5xx: Server Error

The 4xx client response status is described as follows:

401 Unauthorized

Returned in all cases when the presented credential is poorly formed or missing when required. This includes incorrectly spelled or unregistered user names when presented as part of an authorization credential. It does not apply to authorization resources (404 errors).

403 Forbidden

Returned in all cases when the presented credential is well-formed, but is invalid or does not have sufficient authorization (permissions) to grant access to the underlying resource.

404 Not Found

Returned in cases where the presented credential is well-formed, but the server-side resource cannot be located.

For example, when attempting to retrieve user information using /services/v2/authorizations/all/james and the user james is not a registered user. Without a proper registration, no james resource exists so this error code is returned.

The full list is found in the Internet Engineering Task Force RFC 7231 standard.