Skip Headers
Oracle® Fusion Middleware Installation Guide for Oracle Mobile Security Suite
Release 3.0.1
Part Number E51930-03
Go to Documentation Home
Home		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us
Go to previous page
Previous
PDF · Mobi · ePub

A Advanced Configuration Options

This appendix describes advanced configuration options for Oracle Mobile Security Suite.

The Mobile Security Access Server supports a number of advanced configuration options that can be modified after installation. Although these options are described below, it is strongly recommended that customers engage Oracle professional services to set up these advanced configurations.

The instructions in this chapter refer to file system paths on Microsoft Windows. The paths on Oracle Linux are slightly different. For example, the /gateway directory on Windows corresponds to the /msas directory on Linux and the /acp directory on Windows corresponds to the /msac directory on Linux.

This appendix contains the following sections:

A.1 Oracle Access Manager Configuration

In order for the Mobile Security Access Server to authenticate users against Oracle Access Manager and retrieve Oracle Access Manager and OAuth tokens for integrated single sign on, the Mobile Security Access Server must be registered as an OAuth Confidential Client with the Oracle Access Manager OAuth Service. This registration can be performed using the following steps:

  1. Log in to the Oracle Access Manager Console, for example: http://oamhost.example.com:7001/oamconsole.

  2. Select Launch Pad -> Mobile and Social -> OAuth Service.

  3. Open Default Domain from the list of OAuth Identity Domains.

  4. Select OAuth Client -> OAuth Web Clients.

  5. Create a new OAuth client profile for the Mobile Security Access Server, for example:

    • Name: Mobile Security Access Server

    • Client ID: 8ec37bb7afa84d9eade6253a57d22f99 (this can be any value you choose)

    • Client Secret: 2Ni4yUJnFdFgLzdpuxMM (this can be any value you choose)

  6. Under Privileges, select Allow access to all scopes.

  7. Under Privileges-> Grant Types, select all grant types.

  8. Click Create.

During installation of the Mobile Security Access Server, you are prompted to enter the Client UID and Client Password. These must be the same values you just configured as the Client ID and Client Secret.

A.2 Oracle Unified Directory Configuration

To get optimal performance for LDAP sync with Oracle Unified Directory, it is recommended that all the entries and groups be in the OUD database cache and all the groups be in the OUD entry cache.

As a reference, for a deployment with 100k users (of size 1-4KB per entry) containing approximately 5k moderately large static groups, a reasonable value is to reserve 6GB for the OUD heap size.

The steps for configuring the desired heap size are different for OpenJDK than for Oracle Java Hotspog. Follow the approrpriate steps to configure the desired heap size.

OpenJDK

  1. Edit OUD_INSTANCE/OUD/config/java.properties and set the following:

    start-ds.java-args=-Xmn1g -Xms6g -Xmx6g -d64 -server

  2. Launch: OUD_INSTANCE/OUD/bin/dsjavaproperties

  3. Restart the OUD instance:

    OUD_INSTANCE/OUD/bin/stop-ds; OUD_INSTANCE/OUD/bin/start-ds

Oracle Java HotSpot

In addition, it is recommended that you enable the entry cache to store the static groups and increase its capacity from 20 to 30 percent, as follows:

dsconfig set-entry-cache-prop \
          --cache-name Group\ Cache \
          --set enabled:true \
          --set max-memory-percent:30 \
          --hostname localhost \
          --port 4444 \
          --trustAll \
          --bindDN cn=directory\ manager \
          --bindPasswordFile <pwdFile> \
          --no-prompt

For more details about tuning Oracle Unified Directory, see "Tuning Performance" in Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory.

A.3 Additional Active Directory Domains

To add additional Active Directory forests and domains, edit the Kerberos configuration file found at installation_directory/gateway/conf/krb5.conf. The following syntax is required. When opening the file, you will notice that the default domain was populated by the installer. Only domains for additional forests or domains that do not have transitive trust need to be added for application servers that will be accessed by Mobile Security Access Server and mobile devices.

[domain_realm] 
 .<domain_name> = <KRB_REALM_NAME>

For example:

[domain_realm] 
 .bitzermobile.dev = BITZERMOBILE.DEV
 .bitzermobile.prod = BITZERMOBILE.PROD

A.4 Pointing to Specific Domain Controllers

By default, after installation Mobile Security Access Server is configured to find the domain controllers for a specific domain by doing a DNS looking. The entries for each domain in the installation_directory/gateway/conf/krb5.conf file will look something like the following:

BITZERMOBILE.DEV = {
  kdc = bitzermobile.dev
  default_domain = bitzermobile.dev
}

It is possible to configure Mobile Security Access Server to point to specific domain controllers for a given domain, for example:

BITZERMOBILE.DEV = {
  kdc = dc1.bitzermobile.dev
  kdc = dc2.bitzermobile.dev
  random_fallback = true
  default_domain = bitzermobile.dev
}

There should be a separate kdc line for each domain controller. By default when there are multiple domain controllers configured Mobile Security Access Server will try each of them in order. It is possible to configure Mobile Security Access Server to try the individual domain controllers in random order by adding the statement random_fallback = true to the realm configuration. For example:

BITZERMOBILE.DEV = {
  kdc = dc1.bitzermobile.dev
  kdc = dc2.bitzermobile.dev
  random_fallback = true
  default_domain = bitzermobile.dev
}

A.5 Environments with Alternate UPN Suffixes

An alternate UPN suffix occurs when the domain in the UPN after the @ symbol is different than the Windows domain where the user resides, or any other Windows domain that can refer authentication requests to the user's domain.

For environments using accounts with alternate UPN suffixes and Windows password (KINIT) it is necessary to configure Mobile Security Access Server to perform Kerberos authentication using what are known as Enterprise Accounts. To turn on support for alternate UPN suffixes, edit the Kerberos configuration file found at installation-directory/gateway/conf/krb5.conf. Add the following configuration line after the existing lines in the libdefaults section:

[libdefaults] 
   enterprise = true

When using this flag it is important to set the default_realm parameter in the libdefaults section to point to the root domain that is below all sub-domains that contain users that need to authenticate.

A.6 Configuring Mobile Security Access Server Load Balancing

This section contains the following topics:

A.6.1 Mobile Security Access Server Load Balancing Support

The Mobile Security Access Server server supports load balancing across a cluster of multiple Mobile Security Access Servers. This clustering functionality allows multiple Mobile Security Access Servers to share authentication state such that any Mobile Security Access Server is able to verify a secure token generated by another Mobile Security Access Server (at the conclusion of the Kerberos authentication process).

A.6.2 Configuring Active-Active Load Balancing

Follow these steps to configure active-active load balancing:

  1. For multiple Mobile Security Access Servers to serve the same authenticated requests they must share the same secure token PKI certificate. By default during installation the secure token PKI certificate is set to be the same as the SSL certificate. However, it is possible to configure each Mobile Security Access Server to use a different PKI certificate for the secure token function from that used for SSL. The secure token PKI certificate should have key usage enabled for both signature and encryption, but does not have any specific requirements of subject alternative names, etc. For multiple Mobile Security Access Servers to share the same secure token PKI certificate two options are possible:

    • Option 1: Provision a separate PKI certificate specifically for use as the shared secure token PKI certificate.

    • Option 2: Use the existing SSL certificate from one of the Mobile Security Access Servers in the cluster as the shared secure token PKI certificate.

  2. Ensure that all Mobile Security Access Servers in the cluster are able to communicate to each other at their IP addresses over SSL (port 443 by default).

  3. If using PEM files, copy the certificate and key files of the chosen shared secure token PKI certificate to the \BMAX\gateway\conf\ssl\ directory of all Mobile Security Access Servers in the cluster. If using CAPI, import the chosen shared secure token PKI certificate into the appropriate Microsoft cryptographic store of all Mobile Security Access Servers in the cluster.

  4. Edit the Mobile Security Access Server httpd.conf file on all Mobile Security Access Servers in the cluster to update the AuthBMAXSSLCertificateKeyFile configuration directive to point to the key file or CAPI cryptographic store of the chosen secure token PKI certificate.

  5. Restart the Mobile Security Access Server on all Mobile Security Access Servers in the cluster.

A.6.3 Load Balancing Configuration Requirements

The following requirements apply:

  • Load balancing across multiple Mobile Security Access Servers requires that source or SSL session stickiness be configured on the load balancer such that all client requests during the authentication process hit the same Mobile Security Access Server instance. Following the authentication process, subsequent requests can hit any Mobile Security Access Server instance.

  • The load balancer must pass through SSL connections such that the Mobile Security Access Servers terminate the SSL communication.

  • All load balancing algorithms (round-robin, least busy, etc.) are supported.

A.6.4 Known Issue with Older F5 BIG-IP Firmware

There is a known issue with older F5 BIG-IP firmware that did not support newer cryptographic algorithms such as AES, resulting in SSL negotiation failures. This issue will only occur if the F5 is terminating SSL communication on behalf of a back-end HTTPS web site, and is independent of any load balancing or clustering configuration. If this issue is experienced, it is recommended to upgrade the F5 BIG-IP to the latest firmware with support for new cryptographic algorithms. A short-term workaround is to disable newer cryptographic algorithms in Mobile Security Access Server by updating the Mobile Security Access Server httpd.conf file with the configuration line SSLProxyCipherSuite RC4:3DES:DES.

A.7 Installing Mobile Security Access Server Behind a Reverse Proxy

The Mobile Security Access Server can be deployed behind a reverse proxy. In this deployment configuration, the reverse proxy terminates the original SSL connections coming from the client devices, and initiates new SSL connections to the Mobile Security Access Server.

When deployed in this manner the Mobile Security Access Server must be installed with a host name and certificate that matches the public host name that resolves to the reverse proxy.

For KINIT authentication there is no special configuration required on the Mobile Security Access Server itself. For PKINIT authentication the httpd.conf file must be edited to make client-SSL enforcement by Mobile Security Access Server optional. In the httpd.conf file, change the configuration directive SSLVerifyClient required to SSLVerifyClient optional, save the file, and restart the Mobile Security Windows service.

This section contains the following topics:

A.7.1 Example Apache httpd Reverse Proxy Configuration for KINIT

<VirtualHost *:80>

   ProxyPreserveHost on
   ProxyPass / http://bmax.domain.com:80/

</VirtualHost>

<VirtualHost *:443>

   SSLEngine On
   SSLVerifyDepth 10
   SSLOptions +StrictRequire

   SSLCertificateFile "conf/ssl/bmax.cer"
   SSLCertificateKeyFile "conf/ssl/bmax.key"
   SSLCACertificateFile "conf/ssl/bmax-cachain.pem"

   SSLProxyEngine On
   SSLProxyVerify none
   SSLProxyCheckPeerCN off
   SSLProxyCheckPeerExpire off

   ProxyPreserveHost off
   ProxyPass / https://bmax.domain.com:443/

</VirtualHost>

A.7.2 Example Apache httpd Reverse Proxy Configuration for PKINIT

Since PKINIT authentication behind a reverse proxy involves moving client-SSL enforcement from the Mobile Security Access Server to the reverse proxy, it is necessary for the reverse proxy to additionally pass some custom headers to the Mobile Security Access Server providing it with information on the successful client-SSL authentication. The following is an example of an Apache httpd reverse proxy configuration:

<VirtualHost *:80>

   ProxyPreserveHost off
   ProxyPass / http://bmax.domain.com:80/

</VirtualHost>

<VirtualHost *:443>

   SSLEngine On
   SSLVerifyDepth 10
   SSLOptions +StrictRequire

   SSLCertificateFile "conf/ssl/bmax.cer"
   SSLCertificateKeyFile "conf/ssl/bmax.key"
   SSLCACertificateFile "conf/ssl/bmax-cachain.pem"

  SSLProxyEngine On
   SSLProxyVerify none
   SSLProxyCheckPeerCN off
   SSLProxyCheckPeerExpire off

   <Location /AUTHN_BMAX_PKINIT_HEIMDAL>
      SSLVerifyClient require
          RequestHeader set X-SSL-CLIENT-CERT "%{SSL_CLIENT_CERT}s"
          RequestHeader set X-SSL-CLIENT-M-SERIAL "%{SSL_CLIENT_M_SERIAL}s"
          RequestHeader set X-SSL-CLIENT-I-DN "%{SSL_CLIENT_I_DN}s"
   </Location>

   ProxyPreserveHost off
   ProxyPass / https://bmax.domain.com:443/

</VirtualHost>

A.8 Certificate Revocation List and Online Certificate Status Protocol

Mobile Security Access Server Certificate Revocation List (CRL) checking and Online Certificate Status Protocol (OCSP) for verifying client certificates on devices when connecting to the Mobile Security Access Server. The configuration options for this support are in the httpd.conf file and are:

For more information, see http://httpd.apache.org.

This section contains the following topics:

A.8.1 Configuration

The following settings are required for both CRL and OSCP certificate verification. These settings are configured against the primary proxy authentication section; the default is port 443.

SSLCARevocationFile conf/ssl/PEM-ALL.crl

This file should contain CRLs for all the CAs in the Mobile Security Access Server certificate chain. The certificate file is in PEM format, and the PEM files for each CA should simply be concatenated together. Also specify the type of CRL check (either leaf or chain):

SSLCARevocationCheck leaf

For OCSP support, only the following options are required:

SSLOCSPEnable on
SSLOCSPDefaultResponder http://ocspresp.domain.name/ocsp

If the certificate was issued with the OCSP extension, the address of the default responder will be included in the certificate. Typically, CA certificates are issued prior to the OCSP server's configuration, so they may not include the OCSP extension. This is why the Default Responder is required. Otherwise, any certificates that don't have the OCSP extension will be rejected, including CAs in the chain.

A.8.2 CRL Tips for the Microsoft CA

When using a Microsoft CA, the CRL files can be found in:

C:\Windows\System32\certsrv\CertEnroll

Note that these are CER files and that they must be converted to PEM for the Mobile Security Access Server to parse them. The openssl tool can be used to accomplish this:

# openssl crl -inform DER -outform PEM -in DEV-CA1.crl -out PEM-DEV-CA1.crl
# openssl crl -inform DER -outform PEM -in DEV-CA2.crl -out PEM-DEV-CA2.crl
# cat PEM-DEV-CA1.crl PEM-DEV-CA2.crl  > PEM_ALL.crl

All the CRLs for the entire CA chain must be present in the file. When revoking certificates using the Microsoft CA manager, be sure to publish the new CRL; otherwise, you will have to wait until the next publishing cycle. Right click on Revoked Certificates -> All Tasks -> Publish.

A.8.3 OCSP Tips for the Microsoft CA

The process for setting up a Windows OCSP responder is documented in the Online Responder Installation, Configuration, and Troubleshooting Guide on http://technet.microsoft.com.

You must have Windows 2008 Enterprise or Data Center edition. In addition, be sure to enable the NONCE extension for each responder configuration. The easiest way to test the OCSP responder is to use the Microsoft certutil utility. For example:

certutil -url DEV-CA2.cer

A.9 Administrative Console Installation on Internet Information Services

The Mobile Security Administrative Console can be installed using Internet Information Services as a web server, and can then use Active Directory groups to leverage existing domain accounts for authentication and authorization to the Mobile Security Administrative Console console using Windows SSO. The following procedure is used to configure Internet Information Services after running the Mobile Security Access Server installation program.

This section contains the following topics:

A.9.1 Requirements

  • Windows 2008 R2

  • Internet Information Services 7.5 and above

  • Latest service pack and security updates

  • 4 GB memory

  • 2.2 GHZ processor

  • 30GB hard drive

A.9.2 Summary

  1. Add the webserver role using Windows server manager with the following features:

    • Application Development

      • CGI

    • Security

      • Basic Authentication

      • Windows Authentication

    • Management Tools

      • IIS Management Scripts and Tools

      • IIS 6 Metabase Compatibility

      • IIS 6 WMI Compatibility

      • IIS 6 Scripting Tools

  2. Run Mobile Security Access Server and Administrative Console installation Program.

  3. Configure port 443 and Install the web server certificate at the IIS web site level.

  4. Application virual directory test will fail unless Basic Settings are set to the app pool id.

A.10 Configuring Certificates for Service Accounts

This section describes how to install a certificate into the Windows certificate store (CAPI) for a particular Windows service account.

The service account must be defined in Active Directory or as a local account on the Mobile Security Access Server, as follows:

  1. Open command line

  2. Execute runas command to open a new command line window under the service account: runas /env /user:yourserviceaccount@ct.com cmd

  3. Open Microsoft Management Console mmc.

  4. Choose Certificate snapin and choose MY certificate store.

  5. Import certificate or request a certificate from the store depending on your process.

Go to previous page
Previous
Go to Documentation Home
Home		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us