3 Authentication and Authorization

The MA security and authorization model declares and defines how communication security (confidentiality and Integrity) and Authorization (authentication and permissions) are configured and implemented.

All the security and authorization 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.

The MA defines a model and infrastructure for building service-aware applications. This model is not a generalized model, but one targeted at the current and future Oracle GoldenGate products that need to operate and integrate into global, cloud-based deployment environments. Oracle GoldenGate server programs are implemented using the MA infrastructure. All security and configuration implementations provided by the MA are common services.

Parent topic: Securing the Microservices Architecture

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 passphrase 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. The following illustration depicts the relationship between the user, application, server, and database.

Relationship Between a User, Application, Server, and Database

The following types of certificates are used for authentication:

  • 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.

  • 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.

  • 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. MA Server database actions 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
    MA server database authentication This configuration sets the MA 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
    MA server database 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.

Oracle UTL_HTTP Authentication

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_HTTP Oracle Database package may need to configure the client database security environment to enable the use of Client-side certificates for authentication in UTL_HTTP.

To enable UTL_HTTP to use client-side certificates:

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

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

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.

Parent topic: Authentication and Authorization

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 mode is set when configuring an Oracle GoldenGate MA deployment.
Authorization Mode ID Notes
server_only Only validate Server certificates. The Server certificates are required. The Client certificates are ignored.
client_server Validate both Client and Server certificates. Both certificates are required.
clientOptional_server This is the default. 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
User Allows information-only service requests, which do not alter or effect the operation of either the MA. Examples of Query/Read-Only information include performance metric information and resource status and monitoring information.
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.
Administrator Grants full access to the user, including the ability to alter general, non-security related operational parameters and profiles of the server.
Security Grants administration of security related objects and invoke security related service requests. This role has full privileges.

Note:

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

Parent topic: Authentication and Authorization

3.3 Authorization for WebSockets

Learn how you can use WebSocket authorization.

REST API calls are made using standard HTTP request and take advantage of the authorization mechanism described in 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 HTTP authorization mechanism.

Native HTTP Authorization

The native HTTP authorization includes a header in the initial WebSocket establishment request. 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 Example

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

Parent topic: Authentication and Authorization

3.4 Error Codes

Review the MA HTTP error codes.

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

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 privileges 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 at:

https://tools.ietf.org/html/rfc7231

Parent topic: Authentication and Authorization

3.5 Cross Site Request Forgery

Learn how to avoid client-side attacks.

Cross Site Request Forgery (CSRF) is a client-side attack where a malicious or unauthorized website attempts to cause the client browser to perform or issue a compromising action or request against a protected server-side resource using a valid user or client authorization object. The attack is limited to the actions and resources published by the attacked website.

Mode of Attack

A general mode of attack is for a malicious agent to cause a user’s browser to be redirected to a malicious website. The malicious resource at this malicious site causes the user’s browser to download a client-side script (JavaScript). This downloas causes the user’s browser to issue a compromised request against a protected website that the user has obtained prior authorization. The browser issues the compromised request delivering both the malicious script’s request payload along with any authorization cookies that are automatically conveyed with the request.

For example, the malicious website’s script instructs the user’s browser to request the addition of a new user with a high security clearance. The request is issued to the protected website along with current browser user’s current authorization cookie. This cookie is delivered automatically and transparently with the malicious request. The request with the valid user authorization is forged by a script that is retrieved from different redirected malicious site and issues a malicious request under the authorization context of the current browser user.

Taking Defensive Measures

In response to the CSRF threats, the compliant browsers implement a mechanism so that cross-site information is limited and additional information regarding the requesting browsers environment is included.

When scripts are executed that have been retrieved from a site other than the script’s request is targeting, then the browser only allows the following allowed methods to be explicitly defined:

GET
HEAD
POST

Other than the HTTP headers that are automatically set by the browser, the only HTTP headers allowed to be explicitly set are the CORS-safelisted request-header (simple header):

Accept
Accept-Language
Content-Language
Content-Type
Last-Event-ID
DPR
Save-Data
Viewport-Width
Width

The Content-Type header is only allowed to declare the following:

application/x-www-form-urlencoded
multipart/form-data
text/plain

No event listeners can be registered with a XMLHttpRequestUpload object nor are any ReadableStream instances allowed or used in the request.

CSRF Mitigation Strategy

Requests issued from scripts are not retried from the same site as the current target request includes one or more of the following:

Origin HTTP header – Always included in cross-site script requests.

Referer HTTP header – Included if the request is from a referred parent page. (Note that Referer is misspelled in the Remote Function Call).

If a proxy or reverse proxy is between the requesting client and the target website, then the proxy or reverse proxy must be configured to include the following extended HTTP headers:

X-Forwarded-Host – The original hostname the request to which the request was targeted (the proxy or reverse proxy host). The X-Forwarded-Host should replace the Origin header on propagated requests, but contain the same information.

X-Forwarded-Server – The hostname of the proxy or reverse proxy server.

This is the strategy in order of evaluation:

  1. If the Origin HTTP header exists, then verify that the Origin hostname matches the origin server’s hostname.

  2. If the Referer HTTP header exists, then verify that the Origin HTTP header also exists and that the hostname value for both the Origin and Referer HTTP headers match.

  3. If the X-Forwarded-Host HTTP header exists, then verify that the X-Forwarded-Server HTTP header also exists and that the hostname value for both the X-Forwarded-Host and X-Forwarded-Server HTTP headers match.

  4. If neither the Origin header nor the X-Forwarded-Host HTTP headers exist, the request is presumed not to be originating as a Cross Site Request. This places a reliance on the compliance of the browser to support Cross Site Scripting (XSS) policies.

    Note:

    Because of the reliance on the XSS policy support in the client, malicious CSRF requests from general purpose non-browser clients (like cURL, Wget, Python, Perl, and eNetcat) can not be protected against.

Parent topic: Authentication and Authorization