1 Getting Started with Mobile Security Access Server

This chapter describes how to get started using Mobile Security Access Server, including key concepts and an overview of the high-level architecture, a description of the administration tools, and a road map for using the product.

1.1 Understanding Mobile Security Access Server

Mobile Security Access Server (MSAS), a component in the Oracle Mobile Security Suite, provides a central access point for securing traffic from mobile devices to intranet resources.

Mobile Security Access Server:

  • Can manage and secure both forward proxy and reverse proxy (virtual) web traffic.

  • Provides single sign-on to back-end resources using various supported authentication mechanisms.

  • Can be configured as an Oracle Access Manager (OAM) WebGate which is a web-server plug-in for Oracle Access Manager OAM that intercepts HTTP requests and protects resources by URL. For more information, see "Configuring an MSAS Instance as a WebGate".

For an overview of the Oracle Mobile Security Suite, see "Understanding Oracle Mobile Security Suite" in Administering Oracle Mobile Security Suite.

1.2 Understanding Key Concepts in Mobile Security Access Server

The following topics introduce key concepts in Mobile Security Access Server.

Logical and Physical MSAS Instances

MSAS supports the concept of logical and physical instances:

  • A physical MSAS instance represents the actual physical machine on which MSAS is running and listening to requests, and provides security for traffic going through that physical instance. The physical MSAS instances can be running on different hosts, or on the same host on different ports. A typical environment will include multiple physical instances to provide high availability, distribute load, and improve performance. For details about configuring MSAS in a high availability environment, see "Configuring High Availability for Oracle Mobile Security Access Server" in High Availability Guide.

  • A logical instance is an abstract concept to provide easy manageability of multiple physical instances that need to behave identically and have identical configuration. The MSM server hosts the definition of the logical MSAS instance so that the configuration common to all physical instances can be managed centrally (at the logical instance level) using the MSAS console or WLST commands.

Figure 1-1 illustrates the concept of logical and physical instances. In this figure, there is a logical instance named MSAS#1 running on two physical hosts, Physical Host#1 and Physical Host#2.

Figure 1-1 Relationship Between MSAS Physical and Logical Instances

Description of Figure 1-1 follows
Description of "Figure 1-1 Relationship Between MSAS Physical and Logical Instances "

MSAS Applications and URLs

MSAS applications are used to group related URLs to be proxied through the MSAS server. Each application contains the definition of one or more URLs (virtual or proxy) that you can secure using access policies and assertions. An MSAS application can be viewed as analogous to an EAR file, which is essentially a wrapper around modules and other files that can be deployed on an application server. An MSAS application serves as a wrapper of like URLs deployed on an MSAS instance, and can be exported and deployed on other MSAS instances.

The following types of applications are supported:

  • Virtual applications—Applications defined in the MSAS environment that provide the ability to specify new URLs for back-end URLs. These new MSAS URLs are also called virtual URLs. You can then provide the MSAS URLs to clients and completely hide the back-end URLs. In this model, MSAS behaves as a reverse proxy for the back-end URL. For virtual URLS, access polices and assertions are attached at the HTTP method level.

  • Proxy applications—Applications defined in the MSAS environment that specify back-end URLs that are proxied directly through the Mobile Security Access Server. In this case, the Mobile Security Access Server acts as a forward proxy. The back-end URLs are visible to the client but the requests are proxied through the Mobile Security Access Server. For forward proxy URLs, access policies and assertions are attached at the URL-level.

  • Blocked URL—Reserved application per MSAS instance that you can edit to specify URLs that are designated as inaccessible. This application is created by default when you create an MSAS instance.

  • Direct URL—Reserved application per MSAS instance that you can edit to specify URLs that can be directly accessed and are not intercepted by the Mobile Security Access Server. This application is created by default when you create an MSAS instance.

MSAS applications are hosted on MSAS instances, and an instance can host multiple MSAS applications.

For details about MSAS applications, see Chapter 3, "Managing Mobile Security Access Server Applications."

Access Policies and Assertions

You secure the traffic between mobile devices and intranet resources, which you define as proxy and virtual URLs inside MSAS applications, using access policies and assertions. Mobile Security Access Server provides a set of predefined access policies and assertion templates that are installed with the MSAS Management Server. These predefined policies and assertions are based on common best-practice policy patterns in customer deployments, and can be used to configure both authentication and authorization.

The predefined policies and assertions can be attached at three policy enforcement points: on request, when invoking the back-end application, and on response. The configuration properties included with the predefined policies allow you to override certain configuration settings, such as the CSF key used for storing the signature-key password. The scope for the configuration property override value is limited to the specific policy attachment.

Oracle recommends that you do not edit these predefined policies and assertions. If you wish to edit a predefined policy or assertion template, Oracle recommends that you clone the artifact and then edit it.

You can manage these policies from the MSAS console. For details about managing these policies and assertion templates, see "Managing Policies and Assertion Templates". For reference information, see Policy and Assertion Template Reference for Mobile Security Access Server.

Authentication Mechanisms

Mobile Security Access Server supports the following authentication mechanisms from mobile devices:

  • Kerberos Password Authentication (KINIT)—Authentication mechanism for Kerberos 5 used to obtain and cache a Ticket Granting Ticket (TGT) for a principal. A TGT is a ticket that the Kerberos Key Distribution Center grants to a client after authenticating it. KINIT processing is delegated to internal modules in MSAS that invoke the KDC server and authenticate the user.

  • Kerberos PKI-based Authentication (PKINIT) with initial registration using a time-limited passcode—Preauthentication mechanism for Kerberos 5 that uses X.509 certificates to authenticate the clients to the KDC. Similar to KINIT authentication, PKINIT processing is delegated to internal modules in MSAS that invoke the KDC server and authenticate the user.

  • OAuth Confidential Client—Client-server authentication mechanism in the Oracle Access Manager Mobile and Social (OAMMS) server where the client is an OAuth 2.0 client and the OAMMS server is an OAuth 2.0 implementation. In this type of authentication, the client is 2-legged. The confidential client can obtain JWT User Token (referred to as User Identity Assertion) using client id, secret, user id and password. The confidential client can obtain OAuth 2.0 Access Token using standard OAuth 2.0 JWT user assertion flow on behalf of the resource owner.

  • OAuth Mobile Client—Client-server authentication model where the client is a mobile application and the server is Oracle Access Manager Mobile and Social (OAMMS). In this authentication model, a workspace is dynamically registered with the OAMMS server through MSAS and the workspace obtains the JWT Client Token after successful workspace registration. The registered workspace can perform authentication against OAMMS through MSAS and MSAS can obtain JWT User Token after the successful authentication process.

The URL of these authentication endpoints is provided in the configuration JSON files that the Mobile Security Workspace app presents to the user during registration. The type of configuration JSON file selected determines the Workspace app authentication mechanism.You can edit the configuration of these authentication endpoints as described in "Configuring Authentication Endpoints".

1.3 Mobile Security Access Server Architecture Overview

Mobile Security Access Server consists of the following components:

  • Mobile Security Access Server (MSAS)—Run-time engine used for virtualizing and securing traffic. This component serves as the gateway between mobile devices and back-end resources. MSAS is hosted in its own server process, and runs in the demilitarized zone (DMZ), providing a first line of defense.

    The purpose of the DMZ is to add an additional layer of security to an organization's local area network (LAN). Using a DMZ, an external entity has direct access only to components in the DMZ, rather than any other parts of the network.

    MSAS server handles the single sign on to the back-end URLs using various supported authentication mechanism and enforces the security policies on request from the client, when invoking enterprise applications, and on response to the client.

  • Mobile Security Manager (MSM)—MSM contains a management component for MSAS that contains services used to manage MSAS. MSM is deployed on WebLogic Server, in the green zone.

  • Repository—Persistent store (database) that consists of an MDS store for access policies and assertion templates, and MSAS configurations including MSAS applications and URLs.

Figure 1-2 Mobile Security Access Server Architecture Diagram

Description of Figure 1-2 follows
Description of "Figure 1-2 Mobile Security Access Server Architecture Diagram"

1.4 Mobile Security Access Server Administration Tools

System administrators can use the tools described in Table 1-1 to configure and manage MSAS instances.

Table 1-1 Mobile Security Access Server Configuration Tools

Tool Description

configMSAS.sh

Configuration script installed with the MSAS run-time server. Use this script to create MSAS instances and register them with the MSAS Management Server.

idmConfigTool

Configuration script used to configure the identity store, keystore, and truststore used by MSAS. For MSAS configuration, this script must be used with the -configOMSS mode=OMSAS option.

MSAS console pages in the Oracle Access Management Console

Administration interface component of the Oracle Access Management console used for the administration of MSAS. The MSAS console pages, which are accessible from the Mobile Security Launch Pad, are installed with the Mobile Security Manager (MSM). Use these console pages to:

  • Register logical MSAS instances with the Management Server.

  • Configure identity store profiles.

  • Configure message security, including associating Keystore Service (KSS) stripes with MSAS instances, choosing encryption/signature keys and certificates, and specifying message security settings such as clock skew, expiration, and so on.

  • Configure trusted issuers (SAML and JWT).

  • Configure run-time settings such as proxy server and outbound message settings.

  • Configure MSAS endpoints for initial authentication—KINIT, PKINIT, OAuth2 Mobile Client, and OAuth2 Confidential Client.

  • Manage access policies and assertion templates.

  • Manage virtual and proxy applications (create, view, delete, search).

  • Add reverse proxy URLs to virtual applications and secure them by attaching access policies and assertions, and configuring policy property overrides.

  • Add forward proxy URLs to proxy applications and secure them by attaching access policies and assertion templates, and configuring policy property overrides.

  • Configure role-based authorization.

  • Manage diagnostic and message logs.

WLST

Command-line scripting environment provided with the Mobile Security Manager. Use the MSAS WLST commands to:

  • Configure identity store profiles.

  • Configure message security, including associating Keystore Service (KSS) stripes with MSAS instances, choosing encryption/signature keys and certificates, and specifying message security settings such as clock skew, expiration, and so on.

  • Configure trusted issuers (SAML and JWT).

  • Configure run-time settings such as proxy server and outbound message settings.

  • Configure MSAS endpoints for initial authentication—KINIT, PKINIT, OAuth2, and OAMMS.

  • Migrate MSAS application metadata between environments.

  • Manage diagnostic and message log levels.

1.5 Roadmap for Installing and Using Mobile Security Access Server

Table 1-2 provides a roadmap for installing and using Mobile Security Access Server.

Table 1-2 Roadmap for Installing and Using Mobile Security Access Server

Task More information

Review prerequisites for installing MSAS

"Prerequisites for Installing Mobile Security Access Server" in Installing Oracle Mobile Security Access Server.

Install MSAS

"Installing Mobile Security Access Server" in Installing Oracle Mobile Security Access Server

Create an MSAS instance using the configMSAS tool.

"Configuring an MSAS Instance" in Installing Oracle Mobile Security Access Server.

Note: You can also create a logical instance using the MSAS console as described in "Creating and Registering a Logical MSAS Instance". You can configure the instance using the console, then bind it to a physical instance using the configMSAS tool.

Configure identity store, keystore, and truststore for an MSAS instance using the idmConfig utility.

"Configuring the Identity Store and Keystores for the MSAS Instance" in Installing Oracle Mobile Security Access Server.

Start the MSAS server

"Starting and Stopping the MSAS Server" in Installing Oracle Mobile Security Access Server.

View MSAS instances in the MSAS console

"Viewing MSAS Instances in the Environment."

Manage the security configuration of an MSAS instance, including identity store profiles, keystores, trusted issuers, SSL, authentication endpoints, and system settings.

Chapter 6, "Configuring a Mobile Security Access Server Instance."

Create proxy and virtual applications and define URLs.

Secure URLs in virtual applications.

"Attaching Policies and Assertions to Virtual Applications."

Secure URLs in proxy applications.

"Attaching Policies and Assertions to Proxy Applications."

Configure web settings, such as direct and blocked URLs.

Chapter 4, "Configuring Web Settings in MSAS."

Configure role-based authorization

"Configuring Authorization in MSAS Applications."

Configure SSL keystores and truststores

Chapter 7, "Configuring the SSL Keystore and Truststore".

Manage the repository

Chapter 10, "Managing the MSAS Repository"