This chapter describes how to configure security in WebLogic Server Multitenant (MT). The chapter refers to the WebLogic Server documentation sets and online help for additional information as appropriate.
This chapter assumes that you have a working knowledge of the WebLogic Server security concepts and tasks described in Understanding Security for Oracle WebLogic Server.
This chapter includes the following sections:
Configuring the Administrative Identity Domain: Main Steps and WLST Example
Configuring Security Realms and Primary Identity Domains: Main Steps and Examples
Setting Identity Domain Aware Providers Required Control: Main Steps
Configuring Security in a Domain Partition: Related Tasks and Links
WebLogic Server MT expands upon the traditional WebLogic Server security support in two significant ways:
Multiple realms. WebLogic Server MT supports multiple active realms and allows each partition to execute against a different realm.
As before, there is only one active "default realm" used at the global (domain) level.
Identity domains. An identity domain is a logical namespace for users and groups, typically representing a discrete set of users and groups in the physical datastore. Identity domains are used to identify the users associated with particular partitions.
Administrative roles for configuration and management when logged in directly to a partition. You can use WLST to connect directly to a domain partition instead of logging in to the domain level.
These changes are described in the sections that follow.
As described in "Security Realms" in Understanding Security for Oracle WebLogic Server, a security realm comprises mechanisms for protecting WebLogic resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. You use realms to configure authentication, authorization, role mapping, credential mapping, auditing, and other services.
WebLogic Server traditionally supports multiple realms in a domain configuration, but only one realm—typically referred to as the "default realm" or "admin realm"—can be active at any given time.
In contrast, WebLogic Server MT supports multiple active realms and allows each partition to execute against a different realm.
This means that a partition can have unique security providers, users, groups, security roles, and security policies. Resources and applications in the domain partition are available only to users within the domain partition's security realm. Other tenants cannot see or access the resources or applications.
Note:
Partitions can share a security realm, with consequent loss of independence and isolation. In particular, if you do not specify a realm when you create a partition, the default realm is shared with the partition and there is no security isolation between the partition and the domain.Note:
Identity domains are an optional feature you should use only if your user store supports them. The structure, configuration, and management of the identity domain itself are outside of the control of and are opaque to WebLogic Server.The purpose of an identity store is for a partition's users to able to access the partition, while other partitions' users cannot.
Identity domains distinguish users associated with different partitions.You can configure a partition with an identity domain that identifies the set of users associated with the partition. Access policies allow those users—but not users from other identity domains—to access the partition.
Identity domain names should be meaningful in your environment.
There is a generally a one-to-one mapping between partitions and identity domains. However, it is possible for multiple partitions to use the same identity domain. The result is to remove any distinction between users of those partitions, which may not be appropriate in your environment.
There are two types of identity domains:
Administrative identity domain—The identity domain for the default security realm in the domain. The purpose of the administrative identity domain is to distinguish between global domain users and partition users. WebLogic Server system administrators belong to this administrative identity domain.
The administrative identity domain is shown on the WLS Administration Console Domain > Security page.
Primary identity domain—The primary identity domain configured for a partition. The primary identity domain is used as the default identity domain when authenticating partition users and for determining ownership of partition resources.
This primary identity domain is shown on the WLS Administration Console Authentication providers provider-specific pages.
The user store's representation of an identity domain can be anything supported by the underlying technology. For example:
You can create a separate LDAP instance for each identity domain.
An identity domain field can be added to user records in a database.
Identity domains are represented as distinct sub-trees in the Users and Groups hierarchies of a single Oracle Internet Directory (OID) instance.
WebLogic Server MT creates a default administrative identity domain and a default primary identity domain as follows:
Administrative identity domain—WebLogic Server MT creates a default identity domain named idd_DOMAIN in the default security realm. The administrative identity domain is created when you create the first partition in a domain in production mode.
If you create the first partition in a domain in development mode, the default value is null. (This is the only case in which null is considered a valid identity domain.)
Primary identity domain—WebLogic Server MT creates the default identity domain for a partition with the name of the partition prefixed with idd when you create the partition.
This primary identity domain is shown on the provider-specific WLS Administration Console page for the WebLogic Default Authenticator provider.
The default primary identity domain is a convenience feature for the DefaultAuthenticator with the embedded LDAP. It is intended for testing and internal development use, not for a production environment. The embedded LDAP does not actually use identity domains.
You can use WLST to connect directly to a domain partition instead of logging in at the domain level, as described in Connecting Directly to a Domain Partition: WLST Example.
The configuration and management capabilities of the WebLogic administrative roles in a partitioned environment are shown in Table 6-1.
Table 6-1 Administrative Roles for Configuration and Management
| Role | Logged in to Domain | Logged in to Partition via WLST |
|---|---|---|
|
Administrator |
Full control over domain resources, including partition configuration and management. |
Write access to partition owned MBeans. Read-only access to own PartitionMBean.Realm and PartitionMBean.PrimaryIdentityDomain attributes. Read-only access to own RealmMBean and its children. |
|
Deployer |
Configure resources within the domain and partitions, deploy/redeploy/undeploy/start/stop applications within the domain and partitions. |
Configure resources within the partition, deploy/redeploy/undeploy/start/stop applications within the partition. |
|
Operator |
Start/stop servers, partitions, resource groups. |
Start/stop partition and resource group. |
|
Monitor |
Read-only access to domain and partition resources. |
Read-only access to partition resources. |
The administrative identity domain is shown on the WLS Administration Console Domain > Security page.
If you are using the default security realm with the Default Authenticator only to store WebLogic Server Administrator credentials, you can accept the default idd_DOMAIN value. Proceed to Configuring Security Realms and Primary Identity Domains: Main Steps and Examples.
However, if your chosen user store for the default realm supports identity domains, and you have configured an identity domain for WebLogic Server Administrators, you need to configure at least one Authentication provider in the default realm to match your administrative identity domain value.
Perform these steps from the WLS Administration Console:
Select the chosen Authentication provider in the default realm and specify an existing administrative identity domain.
In the navigation pane, select Security Realms.
Select the default security realm.
Select the Providers page.
Select the chosen Authentication provider.
Select the Provider Specific page.
Enter the name of a valid administrative identity domain in the Identity Domain field.
Save your changes.
Navigate to the Domain > Security page and change the Administrative Identity Domain: value to the name of the administrative identity domain.
Save your changes.
Restart the Administration Server.
The following example:
Gets the domain MBean.
Gets the security configuration for the domain.
Sets the administrative identity domain for the security configuration.
Gets the default realm for the security configuration.
Looks up the default Authentication provider for the realm.
Sets the identity domain for the default Authentication provider.
Note:
You must restart the Administration Server. Setting the administrative identity domain value is a non-dynamic change and requires a server restart.
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> ADMIN_IDD = "Admin-idd"
wls:/base_domain/edit/ !> secure=domain.getSecurityConfiguration()
wls:/base_domain/edit/ !> secure.setAdministrativeIdentityDomain(ADMIN_IDD)
wls:/base_domain/edit/ !> realm = secure.getDefaultRealm()
wls:/base_domain/edit/ !> defAtn = realm.lookupAuthenticationProvider('DefaultAuthenticator')
wls:/base_domain/edit/ !> defAtn.setIdentityDomain(ADMIN_IDD)
You are not required to create a security realm. Partitions can share a security realm, or use the default realm. However, the best practice is to create a security realm for each partition. This is particularly true if you want to use identity domains in order to get isolation.
If your user store does support identity domains, configure the primary identity domain as described in this section.
Perform the following steps to configure security realms and identity domains in a domain partition. Note that some of the steps require the WLS Administration Console.
Create a security realm. The name must be unique within the domain.
If you are using Fusion Middleware Control, navigate to WebLogic Domain > Security > Security Realms. The default providers are created on your behalf in the new realm.
If you are using the WLS Administration Console, select Security Realms in the navigation pane. You will probably find it most convenient to select the option to create the default providers in the new realm.
Add partition-specific users to the security realm.
If you are using Fusion Middleware Control, navigate to WebLogic Domain > Security > Users and Groups. Select the security realm you just created and click Create on the Users and Groups pages to add users and groups to the realm.
If you are using the WLS Administration Console, select Security Realms in the navigation pane. Select the security realm you just created, and then the Users and Groups page. Click New on the Users and Groups pages to add users and groups to the realm.
Configure your providers in the security realm, as described in "Manage Security Providers" in the Oracle WebLogic Server Administration Console Online Help.
Perform this step from the WLS Administration Console.
Optionally, select the Authentication provider you just created and specify an existing identity domain. Identity domains are an optional feature you can use only if your user store supports them.
Perform this step from the WLS Administration Console.
Select the Provider Specific page.
Enter the name of a valid identity domain in the Identity Domain field.
Save your changes.
When you later create a partition as described in Configuring Domain Partitions.
Specify the security realm you created.
Specify the identity domain you set for the Authentication provider.
If you use Fusion Middleware Control to create the domain partition, specify the primary identity domain on the Create Domain Partition: General page. If you do not specify a value, WebLogic Server MT creates the default identity domain for a partition with the name of the partition prefixed with idd when you create the partition.
If you use the WLS Administration Console to create the domain partition, WebLogic Server MT creates the default identity domain with the name of the partition prefixed with idd. After you create the partition, and before you activate your changes, navigate to the Partition > General page and change the default to your actual identity domain name.
The following example:
Gets the domain MBean.
Gets the security configuration for the domain.
Sets the administrative identity domain for the security configuration.
Gets the default realm for the security configuration.
Looks up the default Authentication provider for the realm.
Sets the identity domain for the default Authentication provider.
Creates a new realm for the partition.
Creates the required security providers for the new realm.
Creates a domain partitionFoot 1 .
Creates a virtual target.
Sets the host name and URI prefix for the virtual target.
Adds the virtual target as an available target in the partition.
Sets the security realm for the partition.
Sets the primary identity domain for the partition.
Creates the resource group.
Adds the virtual target to the resource group.
Activates the changes.
Starts the partitionFootref 1.
edit()
startEdit()
wls:/base_domain/edit/ !> domain=getMBean('/')
wls:/base_domain/edit/ !> ADMIN_IDD = "Admin-idd"
wls:/base_domain/edit/ !> secure=domain.getSecurityConfiguration()
wls:/base_domain/edit/ !> secure.setAdministrativeIdentityDomain(ADMIN_IDD)
wls:/base_domain/edit/ !> realm = secure.getDefaultRealm()
wls:/base_domain/edit/ !> defAtn = realm.lookupAuthenticationProvider('DefaultAuthenticator')
wls:/base_domain/edit/ !> defAtn.setIdentityDomain(ADMIN_IDD)
wls:/base_domain/edit/ !> partrealm=secure.createRealm('partrealm')
wls:/base_domain/edit/ !> partrealm.createAuthenticationProvider("DefaultAuthenticator","weblogic.security.providers.authentication.DefaultAuthenticator")
wls:/base_domain/edit/ !> defAtnP = partrealm.lookupAuthenticationProvider('DefaultAuthenticator')
wls:/base_domain/edit/ !> defAtnP.setIdentityDomain('partID')
wls:/base_domain/edit/ !> partrealm.createAuthenticationProvider("DefaultIdentityAsserter","weblogic.security.providers.authentication.DefaultIdentityAsserter")
wls:/base_domain/edit/ !> partrealm.createAuthorizer("XACMLAuthorizer","weblogic.security.providers.xacml.authorization.XACMLAuthorizer")
wls:/base_domain/edit/ !> partrealm.createRoleMapper("XACMLRoleMapper","weblogic.security.providers.xacml.authorization.XACMLRoleMapper")
wls:/base_domain/edit/ !> partrealm.createAdjudicator("DefaultAdjudicator","weblogic.security.providers.authorization.DefaultAdjudicator")
wls:/base_domain/edit/ !> partrealm.createCredentialMapper("DefaultCredentialMapper","weblogic.security.providers.credentials.DefaultCredentialMapper")
wls:/base_domain/edit/ !> cert = partrealm.createCertPathProvider("WebLogicCertPathProvider","weblogic.security.providers.pk.WebLogicCertPathProvider")
wls:/base_domain/edit/ !> partrealm.setCertPathBuilder(cert)
wls:/base_domain/edit/ !> pv = partrealm.createPasswordValidator('SystemPasswordValidator','com.bea.security.providers.authentication.passwordvalidator.SystemPasswordValidator')
wls:/base_domain/edit/ !> pv.setMinPasswordLength(8)
wls:/base_domain/edit/ !> pv.setMinNumericOrSpecialCharacters(1)
wls:/base_domain/edit/ !> peppart=domain.createPartition('Pep')
wls:/base_domain/edit/ !> vt=domain.createVirtualTarget('TestVT')
wls:/base_domain/edit/ !> vt.setHostNames(jarray.array([String('localhost')],String))
wls:/base_domain/edit/ !> vt.setUriPrefix('/foo')
wls:/base_domain/edit/ !> peppart.addAvailableTarget(vt)
wls:/base_domain/edit/ !> peppart.setRealm(partrealm)
wls:/base_domain/edit/ !> peppart.setPrimaryIdentityDomain('partID')
wls:/base_domain/edit/ !> peprg=peppart.createResourceGroup('TestRG')
wls:/base_domain/edit/ !> peprg.addTarget(vt)
wls:/base_domain/edit/ !> activate()
wls:/base_domain/edit/ !> startPartitionWait(peppart)
For an example of creating domain partitions from REST, see "Creating Partitions" in Administering Oracle WebLogic Server with RESTful Management Services.
This example demonstrates how to create a partition, including:
A new security realm for the partition, including security providers and the primary identity domain.
A virtual target for the cluster, on which the applications will run.
A virtual target for the Administration Server, so that the Deployer can create system resources and deploy applications.
A resource group for each virtual target.
Partition users in the Administrator, Deployer, Monitor, and Operator roles.
The following WebLogic security providers must be identity-domain-aware to function correctly in an environment where identity domains are configured.
Role Mapping
Authorization
Credential Mapping
Audit
For example, an Authorization provider that does not understand identity domains cannot correctly distinguish between two users with the same name but different identity domains, and therefore cannot make valid authorization decisions.
The standard WebLogic Server security providers are identity-domain-aware. However, deprecated providers, such as DefaultRoleMapper and DefaultAuthorizer, are not identity-domain-aware.
If you have configured identity domains in your user store, you can force the use of identity-domain-aware providers by setting the Identity Domain Aware Providers Required control. Setting this control specifies that only role mapping, authorization, credential mapping, and audit providers that support identity domains are used, even if no identity domains are configured.
Perform these steps from the WLS Administration Console:
Navigate to the Domain > Security page.
Set the Identity Domain Aware Providers Required control.
Save your changes.
SSL configuration is not partition-specific. All partitions use the standard WebLogic Server SSL configuration described in "Configuring SSL" in Administering Security for Oracle WebLogic Server 12c (12.2.1).
However, note the following important differences:
If you configure an explicit or offset port for the virtual target as described in Configuring Virtual Targets, SSL is not supported for that virtual target.
This means that clients (for example, RMI clients) cannot communicate directly over SSL to a partition that uses port-based routing.
CertPath providers configured in non-default security realms, such as security realms associated with one or more partitions, are not run as part of the extra SSL validation. Only the default security realm's CertPath provider is run.
You can use WLST to connect directly to a domain partition instead of logging in to the domain level. When you do this:
The user name you specify is validated against the security realm for that partition.
See Table 6-1 for the configuration and management capabilities of the WebLogic administrative roles when logged directly in to a partition.
The initial view of the MBean hierarchy is partition-specific.
The WLST syntax is as follows. Note that only t3 connections are supported.
wls:/offline> connect('username','password',"t3://system:port/partitions/partition-name")
For example:
wls:/offline> connect('weblogic','password',"t3://somehost:7001/partitions/Partition-0")
Connecting to t3://somehost:7001/partitions/Partition-0 with userid
weblogic ...
Successfully connected to partition "Partition-0".
wls:/base_domain/serverConfig/Partitions/Partition-0>
Specify a URL that matches a configured virtual target for the partition. For example, if you have a virtual target without a host name and a uriPrefix of /foo, you can connect as follows:
connect('weblogic','password',"t3://somehost:7001/foo")
MBean hierarchy is partition-specific
The MBean hierarchy after connecting is partition-specific:
wls:/base_domain/serverConfig/Partitions/Partition-0> ls() dr-- AvailableTargets dr-- CoherencePartitionCacheConfigs dr-- DataSourceForJobScheduler dr-- DataSourcePartition dr-- DefaultTargets dr-- JDBCSystemResourceOverrides dr-- JMSSystemResourceOverrides dr-- JTAPartition dr-- MailSessionOverrides dr-- ManagedExecutorServiceTemplates dr-- ManagedScheduledExecutorServiceTemplates dr-- ManagedThreadFactoryTemplates dr-- PartitionLog dr-- PartitionWorkManager dr-- PartitionWorkManagerRef dr-- ResourceGroups dr-- ResourceManager dr-- ResourceManagerRef dr-- SelfTuning dr-- SystemFileSystem dr-- WebService -r-- BatchJobsExecutorServiceName null -r-- DataSourceForJobScheduler null -r-- GracefulShutdownTimeout 0 -r-- IgnoreSessionsDuringShutdown false -r-- JobSchedulerTableName WEBLOGIC_TIMERS -r-- MaxConcurrentLongRunningRequests 50 -r-- MaxConcurrentNewThreads 50 -r-- Name Partition-0 -r-- ParallelDeployApplicationModules false -r-- ParallelDeployApplications true -r-- PartitionID 085b48c2-6d70-434e-8200-f4eb f28ca3a0 -r-- PartitionLifeCycleTimeoutVal 120 -r-- PartitionWorkManager null -r-- PartitionWorkManagerRef null -r-- PrimaryIdentityDomain idd_Partition-0 -r-- RCMHistoricalDataBufferLimit 250 -r-- ResourceDeploymentPlanPath null -r-- ResourceManager null -r-- ResourceManagerRef null -r-- StartupTimeout 0 -r-- Type Partition -r-- UploadDirectoryName C:\Oracle\Middleware\Oracle_ Home\user_projects\domains\base_domain/partitions/Partition-0/system\servers\Adm inServer\upload\
See the following topics for additional information:
"Manage Security Providers" in the Oracle WebLogic Server Administration Console Online Help.
"Create Users" in the Oracle WebLogic Server Administration Console Online Help.
"Configuring SSL" in Administering Security for Oracle WebLogic Server 12c (12.2.1)
Footnote Legend
Footnote 1: Note: You must restart the Administration Server before you can start the partition. Setting the administrative identity domain value is a non-dynamic change and requires a server restart.