1. Administering Oracle SOA Cloud Service
  2. Secure an Oracle SOA Cloud Service Instance
  3. About Authenticating Users

About Authenticating Users

Oracle SOA Cloud Service is comprised of multiple components, each with its own identity stores, authentication options and administrative tools.

Topics:

About Users in Oracle SOA Cloud Service

There are multiple types of users associated with Oracle SOA Cloud Service. Each has its own purpose and is found in a specific identity store.

Cloud Users

When an Oracle Cloud account is created that includes Oracle SOA Cloud Service, the default administrator is given the SOA Administrator role. Only Oracle Cloud users with this role can create and manage Oracle SOA Cloud Service instances with either the console, CLI or REST API. Users in your account who have the Identity Domain Administrator role can create additional cloud users and grant them the SOA Administrator role. Similar roles exist for the other services available in Oracle Cloud. For more information, refer to:

Oracle SOA Cloud Service stores backups of service instances in Oracle Cloud Infrastructure Object Storage Classic. Consequently, each service instance is also configured with the credentials for an Oracle Cloud user who has read/write access to Oracle Cloud Infrastructure Object Storage Classic. See About Backup and Restoration of Oracle SOA Cloud Service Instances.

WebLogic Server Administrators

An Oracle SOA Cloud Service instance includes an Oracle WebLogic Server domain, which is comprised of an Administration Server and one or more Managed Servers. A domain also defines a security realm that controls authentication, authorization, role mapping, credential mapping and security auditing across all of the servers in the domain. When you create a service instance you provide the credentials for the initial user in this WebLogic security realm. This user has the Administrator role and can perform all WebLogic Server administrative operations through either the WebLogic Server Administration Console, Fusion Middleware Control, WebLogic Scripting Tool (WLST) or WebLogic REST API. You can also use the default WebLogic administrator to create additional WebLogic administrators and assign them specific roles and privileges. For example, users with the Deployer role can deploy SOA applications to the domain.

By default, the domain in an Oracle SOA Cloud Service instance is configured to use the embedded LDAP identity store for WebLogic Server roles, users and policies. This embedded LDAP is hosted in the Administration Server and is replicated to all Managed Servers in the domain. If the default security configuration does not meet your requirements, you can modify the default security realm or create a new one with any combination of WebLogic and custom security providers. To learn more about WebLogic security, see Understanding Security for Oracle WebLogic Server (12.2.1.4 | 12.2.1.3 | 12.2.1.2 | 12.1.3).

Application Users

SOA applications deployed to the WebLogic Server domain in your Oracle SOA Cloud Service instance can have security policies that protect the applications against unauthorized access. WebLogic Server supports various security providers that assign an identity to the requesting user or software entity. For example, WebLogic Server can determine the identity of an application user by validating a user name and password.

By default, the domain in an Oracle SOA Cloud Service instance is configured to use the embedded LDAP identity store for both WebLogic administrators and application users. You can use standard WebLogic tools like the WebLogic Server Administration Console to manage users, groups, roles and policies in the embedded LDAP.

If the default security configuration does not meet your requirements, you can modify the default security realm or create a new one with any combination of WebLogic and custom security providers. For large production applications, Oracle recommends that you use a proper identity management system such as Oracle Identity Management instead of the embedded LDAP.

Database Users

An Oracle SOA Cloud Service instance requires access to at least one Oracle database. Oracle SOA Cloud Service provisions your chosen database with the Oracle Fusion Middleware (FMW) schema and also connects the WebLogic Server domain in your service instance to this database. When you create a service instance you provide appropriate credentials to access and update this FMW database.

You can also connect your service instance to additional relational databases by using standard WebLogic tools like the WebLogic Server Administration Console. Just as with the FMW database, you must provide the necessary credentials to connect to these application databases.

Note:

If your database is running Oracle Database 12c, users can be scoped to the container database (CDB) or a pluggable database (PDB). To connect to a specific PDB from WebLogic Server, be sure to specify user credentials in the target PDB and not the CDB.

To learn more about database connectivity in WebLogic Server see Administering JDBC Data Sources for Oracle WebLogic Server (12.2.1.4 | 12.2.1.3 | 12.2.1.2 | 12.1.3).

A component of your WebLogic Server domain is Oracle Platform Security Services (OPSS), which requires a connection to your service instance’s FMW database. The credentials for this database connection are stored in a separate file named jps-config.xml.

Load Balancer Administrators

Your Oracle SOA Cloud Service instance can optionally include a load balancer running Oracle Traffic Director. The load balancer distributes application traffic to the servers in the WebLogic Server domain. Traffic Director has an Administration/Managed server architecture similar to WebLogic Server, along with its own identity store. When you create a service instance, the same WebLogic Server administrator credentials that you provide are also used as the default Traffic Director credentials. This user has full administrative access to the Load Balancer console and other Traffic Director tools. You can also use the Load Balancer console to create additional Traffic Director administrators. See Control and Configure an Oracle Traffic Director Load Balancer for an Oracle SOA Cloud Service Instance.

VM OS Users

Each Oracle SOA Cloud Service instance is associated with a Secure Shell (SSH) public key. Using the matching private key, you can SSH to the underlying virtual machines (VMs) running WebLogic Server and the load balancer. SSH to a VM as the opc OS user and then switch to the oracle OS user in order to manage Oracle SOA Cloud Service software like WebLogic Server, or to install additional Oracle software. The opc user has root privileges to the OS if you need to modify the OS configuration, create additional OS users, or install additional OS packages. See Access a VM Through a Secure Shell (SSH).

About Authentication Options

Get an overview of the different ways in which you can determine the identity of a user or system that is accessing an application running in Oracle SOA Cloud Service. Clients can authenticate against an external LDAP or database, or their identities can be validated with different token technologies like SAML.

By default, cloud users and application users are managed by different security frameworks and are located in different identity stores. Consequently, these users support different authentication options.

Single Sign-On (SSO) is the ability for a user to authenticate once and then gain access to many different application components, even though these components may have their own authentication schemes. SSO enables users to login securely to all their applications, web sites and mainframe sessions with just one identity.

Cloud Authentication

In order to create and manage cloud services such as Oracle SOA Cloud Service, Oracle Cloud users are authenticated against a specific identity domain and with a username and password. See "Cloud Users" in About Users in Oracle SOA Cloud Service.

WebLogic Server Authentication

An Oracle WebLogic Server domain defines a security realm that controls authentication, authorization, role mapping, credential mapping and security auditing across all of the servers in the domain. These services are implemented as security providers. WebLogic Server includes many types of built-in providers and you can also build your own. Authentication providers in particular establish trust for a user by validating credentials or tokens. They can also identify any groups to which the user belongs, in order to make access decisions.

You can also configure multiple authentication providers in a single security realm. For example, consider a scenario in which the WebLogic Server administration users are located in one LDAP while application users are found in a different LDAP.

This table describes some of the authentication options available in a WebLogic Server security realm.

Authentication Option Description

Embedded LDAP (default)

Each user’s credentials and group memberships are maintained in an Lightweight Directory Access Protocol (LDAP) server that is hosted in the domain’s Administration Server and replicated to all Managed Servers in the domain. Oracle does not recommend using the embedded LDAP for large production applications.

See "Managing the Embedded LDAP Server" in Administering Security for Oracle WebLogic Server (12.2.1.4 | 12.2.1.3 | 12.2.1.2 | 12.1.3).

External LDAP

WebLogic Server includes authentication providers that are compatible with Oracle Internet Directory, Microsoft Active Directory, iPlanet, Open LDAP or any other LDAP-compliant server. These providers differ primarily in how they are configured by default to match typical directory schemas for their corresponding LDAP server.

If this LDAP server is hosted outside of the VMs in your Oracle SOA Cloud Service instance, you may need to enable network communication between your VMs and the LDAP server. See Manage Access Rules for an Oracle SOA Cloud Service Instance.

See "Configuring LDAP Authentication Providers" in Administering Security for Oracle WebLogic Server (12.2.1.4 | 12.2.1.3 | 12.2.1.2 | 12.1.3).

Relational Database

WebLogic Server includes authentication providers that use a relational database as a data store for users, passwords and groups. These providers are configured by default with a typical SQL database schema to support these entities, but you can also customize this default configuration to match your database's existing schema.

To use the database authentication providers, you must create a data source in the domain to establish connectivity to the database. If you selected this database when you created your Oracle SOA Cloud Service instance, a data source already exists. If this database is hosted outside of the VMs in your Oracle SOA Cloud Service instance, you may need to enable network communication between your VMs and the database.

See:

SAML

In perimeter authentication, a system outside of WebLogic Server establishes trust through tokens. WebLogic Server can generate and consume Security Assertion Markup Language (SAML) tokens (assertions), and supports both SAML 1.1 and SAML 2.0.

See in Administering Security for Oracle WebLogic Server:

Manage Passwords for Oracle SOA Cloud Service

You may need to update the various credentials used to run a service instance, in order to meet corporate security policies or government regulations, or in response to a perceived security threat.

The specific tools and procedures you use to modify passwords depends on the type of user and where it is stored in the environment. In addition, there are consequences to changing certain system users because other resources in the environment use these credentials as well.

For general information about users, see About Users in Oracle SOA Cloud Service.

User Updating the Password Updating Dependencies

Cloud User

To update your Oracle Cloud password, see Change and Manage Your Passwords in Getting Started with Oracle Cloud.

If you are an Identity Domain Administrator, you can reset other users’ passwords. See Resetting User Passwords in Managing and Monitoring Oracle Cloud.

When you create an Oracle SOA Cloud Service instance you provide the location of an Oracle Cloud Infrastructure Object Storage Classic container along with credentials to access and update backup files in this storage container. If you change the password for this cloud user, you also need to update the backup configuration of your service instance. Otherwise, automated and manual backups may fail.

See Configure Automated Backups for an Oracle SOA Cloud Service Instance.

WebLogic Server Administrator

By default your Oracle WebLogic Server domain is configured to use the embedded LDAP security provider as the identity store for users, passwords and groups. This includes the WebLogic Server administrator user whose credentials you initialize when you create the Oracle SOA Cloud Service instance.

You can use any available WebLogic Server tools to modify user credentials in the embedded LDAP, including the Administration Console, WLST and REST API. To use the Administration Console, see "Modify Users" in Administration Console Online Help for Oracle WebLogic Server (12.2.1.4 | 12.2.1.3 | 12.2.1.2 | 12.1.3).

Administrative credentials are required in order to boot the servers in your domain. A boot identity file is a text file that contains encrypted user credentials for starting and stopping an instance of WebLogic Server. If you change the password for this user, you must also update any boot identity files that use the same credentials. These files are located on the VM file system. Replace the current encrypted password with your new password. Otherwise, servers may fail to boot if you attempt to restart them.

See "Boot Identity Files" in Administering Server Startup and Shutdown for Oracle WebLogic Server (12.2.1.4 | 12.2.1.3 | 12.2.1.2 | 12.1.3).

For information on using SSH to access Oracle SOA Cloud Service VMs, see Access a VM Through a Secure Shell (SSH).

Load Balancer Administrator

If you add a load balancer to your Oracle SOA Cloud Service instance when you initially create it, the load balancer is configured with the same credentials as the WebLogic Server administrator. If you add a load balancer at a later time, you have the option to provide different credentials. In either case use the Load Balancer Console to change this user’s password.

For service instances running Oracle Traffic Director 12c, see Configure WebLogic Server Users in Administering Oracle WebLogic Server with Fusion Middleware Control. Be sure to access the console for the load balancer, and not for the WebLogic Server domain.

For service instances running Oracle Traffic Director 11g, see Securing Access to the Administration Server in Oracle Traffic Director Administrator’s Guide.

None

Database User

The Oracle WebLogic Server domain in an Oracle SOA Cloud Service instance is automatically configured with several JDBC data sources. Each data source connects to an Oracle Database Classic Cloud Service database deployment. You specify the database name and credentials for these data sources when you create the service instance.

If you modify the password for one of the database users, the data sources in the WebLogic domain may fail to connect to the database. Use one of the standard WebLogic administrative interfaces to modify the connection properties of the existing data sources. See "Configuring JDBC Data Sources" in Administering JDBC Data Sources for Oracle WebLogic Server (12.2.1.4 | 12.2.1.3 | 12.2.1.2 | 12.1.3).

When you create a service instance, you select one database deployment to host the Oracle Required Schema and you provide appropriate database credentials. If you modify the password of this database user, you must perform an additional task. Use the WebLogic Scripting Tool (WLST) to execute the modifyBootStrapCredential command and then restart the Administration Server. 

modifyBootStrapCredential(jpsConfigFile='/u01/data/domains/DOMAIN_NAME/config/
fmwconfig/jps-config.xml',username='SCHEMA_PREFIX_OPSS',
password='NEW_PASSWORD')

Application User

By default your Oracle WebLogic Server domain is configured to use the embedded LDAP security provider as the identity store for users, passwords and groups. This includes any custom application users you’ve defined.

You can use any available WebLogic Server tools to modify user credentials in the embedded LDAP, including the Administration Console, WLST, and REST API. To use the Administration Console, see "Modify Users" in Administration Console Online Help for Oracle WebLogic Server (12.2.1.4 | 12.2.1.3 | 12.2.1.2 | 12.1.3).

Alternatively, you can customize your WebLogic domain to use other security providers for users and passwords, such as a database or an LDAP server. In general, you do not use WebLogic Server to directly modify user credentials in these external identity stores. Instead use the native administrative tools offered by these resources. For more information about security providers, see About Authentication Options.

None

Relocate Oracle SOA Cloud Service to a Different Identity Domain

Not Oracle Cloud at Customer This topic does not apply to Oracle Cloud at Customer.

An Oracle Cloud account administrator has the ability to move your Oracle SOA Cloud Service entitlement to another identity domain in the same account.

When you activate an order in Oracle Cloud, services in the order are typically activated in a default identity domain within the account. If necessary you can relocate Oracle SOA Cloud Service from one identity domain to another. However, you must delete any existing service instances prior to relocating the service.

See Relocating a Service Entitlement to Another Identity Domain in Managing and Monitoring Oracle Cloud.

During the relocation process, the service administrator will be added to the target identity domain but other Oracle Cloud users and administrators will not. The identity domain administrator will need to create any other users and administrators in the target identity domain, and to assign them the appropriate roles. If applicable, the bulk user import and role assignment features can be used for this task. For more information, see: