Security & Authentication

Security & Authentication

Oracle Certificate Import for OIDC Authentication

Problem

Oracle APEX applications using OpenID Connect (OIDC) for authentication must validate SSL/TLS certificates when making HTTPS requests to identity providers. Missing or incorrectly configured certificates cause authentication failures with "ORA-29024: Certificate validation failure" or similar errors, blocking all user logins.

Solution

Import the complete certificate chain for the OIDC provider into an Oracle Wallet and configure APEX to use it for HTTPS connections. Download root and intermediate certificates. Use orapki to create the wallet and import certificates. Configure sqlnet.ora and update APEX instance settings to use the wallet for outbound HTTPS connections.

Implementation

-- Download certificate chain via OpenSSL
openssl s_client -connect auth.provider.com:443 -showcerts

-- Create wallet
orapki wallet create -wallet /path/to/wallet -auto_login -pwd WalletPassword123

-- Add certificates
orapki wallet add -wallet /path/to/wallet -trusted_cert -cert root_ca.pem -pwd WalletPassword123
orapki wallet add -wallet /path/to/wallet -trusted_cert -cert intermediate_ca.pem -pwd WalletPassword123

-- Verify
orapki wallet display -wallet /path/to/wallet

Configure APEX for Wallet:

BEGIN
    APEX_INSTANCE_ADMIN.SET_PARAMETER(
        p_parameter => 'WALLET_PATH',
        p_value     => 'file:/path/to/wallet'
    );
    COMMIT;
END;

Trust Store Configuration (sqlnet.ora) for Certificate Validation

Problem

Oracle database connections using SSL/TLS require proper trust store configuration to validate server certificates. When sqlnet.ora is misconfigured or missing trust store parameters, applications relying on UTL_HTTP or database links for external HTTPS calls fail with certificate validation errors.

Solution

Configure sqlnet.ora with proper WALLET_LOCATION, SSL_CLIENT_AUTHENTICATION, and SSL_SERVER_DN_MATCH parameters. Enable server certificate validation and hostname verification.

Implementation

WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /u01/app/oracle/admin/wallet)
    )
  )

SSL_CLIENT_AUTHENTICATION = FALSE
SSL_SERVER_DN_MATCH = TRUE
SSL_VERSION = 1.2

SSL_CIPHER_SUITES =
  (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)

Common Configuration Issues:

• Incorrect DIRECTORY path in WALLET_LOCATION
• Missing cwallet.sso file in wallet directory
• SSL_SERVER_DN_MATCH=TRUE with certificate CN mismatch
• Expired or incomplete certificate chain in wallet
• File permissions preventing Oracle process from reading wallet

Custom Authentication Schemes in APEX

Problem

Default APEX authentication schemes don't integrate with enterprise identity management systems or support custom authentication workflows. Organizations using LDAP, Active Directory, SAML, or custom authentication APIs cannot authenticate users without building custom integration logic.

Solution

Create custom authentication schemes in APEX that integrate with external identity providers through PL/SQL authentication functions. Implement the authentication function interface that APEX expects, including credential validation, session establishment, and logout handling.

Implementation

CREATE OR REPLACE FUNCTION custom_auth_function (
    p_username IN VARCHAR2,
    p_password IN VARCHAR2
) RETURN BOOLEAN
IS
    l_valid BOOLEAN := FALSE;
    l_response CLOB;
BEGIN
    l_response := APEX_WEB_SERVICE.MAKE_REST_REQUEST(
        p_url => 'https://auth.company.com/validate',
        p_http_method => 'POST',
        p_body => JSON_OBJECT(
            'username' VALUE p_username,
            'password' VALUE p_password
        )
    );

    IF JSON_VALUE(l_response, '$.authenticated') = 'true' THEN
        l_valid := TRUE;
        APEX_UTIL.SET_SESSION_STATE('USER_EMAIL', JSON_VALUE(l_response, '$.email'));
        APEX_UTIL.SET_SESSION_STATE('USER_ROLE', JSON_VALUE(l_response, '$.role'));
    END IF;

    RETURN l_valid;
EXCEPTION
    WHEN OTHERS THEN
        APEX_DEBUG.ERROR('Authentication error: ' || SQLERRM);
        RETURN FALSE;
END custom_auth_function;

Web Application Security Headers Configuration

Problem

Static HTML websites lack built-in security headers that protect against common web vulnerabilities. Without proper HTTP security headers, sites remain vulnerable to clickjacking, XSS, MIME type confusion, and other browser-based exploits. Security scanning tools flag missing headers as critical vulnerabilities.

Solution

Configure comprehensive HTTP security headers using Apache .htaccess. Implement X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, Permissions-Policy, Content-Security-Policy, and HSTS. Force HTTPS redirection for all traffic.

Implementation

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-XSS-Protection "1; mode=block"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'self';"
</IfModule>

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Verification:

# Test with curl
curl -I https://yourdomain.com

# Online scanners
# https://securityheaders.com  (target grade: A+)
# https://www.ssllabs.com/ssltest/  (target grade: A+)
# https://observatory.mozilla.org  (target score: 90+)