5 Configuring Security

This chapter describes how to configure security in Oracle WebLogic Server Multitenant (MT). The chapter refers to the Oracle 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:

New Security Features in Domain Partitions

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 data store. 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 Fusion Middleware Control and WebLogic Scripting Tool (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.

Domain Partition Security Realms: Overview

As described in "Security Realms" in Understanding Security for Oracle WebLogic Server, a security realm comprises mechanisms for protecting WebLogic Server 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, then the default realm is shared with the partition and there is no security isolation between the partition and the domain.

Identity Domains: Overview

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 the control of, and are invisible 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.

Types of Identity Domains

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 Oracle WebLogic Server 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 in the WebLogic Server Administration Console, on the 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 Lightweight Directory Access Protocol (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.

To enable partition administrators access to realm security data in a partition, the system administrator must configure a management identity domain on the realm. The management identity domain can be the primary identity domain, the administrative identity domain, or another identity domain supported by an authenticator in the realm. A partition administrator with the identity domain that matches this management identity domain can access a subset of the security MBeans and can invoke management operations on the MBeans. Note that although the administrative identity domain can be the management identity domain, it is not necessary because the system administrator already has permission to manage the security realm.

Default Identity Domain Values

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, then 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 WebLogic Server Administration Console page for the WebLogic Default Authenticator provider.

    The default primary identity domain is a convenience feature for the Default Authenticator 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.

Administrative Roles for Configuration and Management

You can use Fusion Middleware Control and WLST to connect directly to a domain partition instead of logging in at the domain level, as described in Connecting Directly to Domain Partitions: Main Steps and WLST Example.

The configuration and management capabilities of the WebLogic Server administrative roles in a partitioned environment are shown in Table 5-1.

Table 5-1 Administrative Roles for Configuration and Management

Role Logged In to Domain Logged In to Partition

Administrator

Full control over domain resources, including partition configuration and management.

Configure the management identity domain attribute on the Realm MBean.

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.

The partition administrator in the management identity domain:

  • Can invoke methods on a subset of the security and realm Runtime MBeans in its own partition.

  • Can invoke methods on a subset of management operations on the security provider MBeans in its own partition.

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.

Configuring the Administrative Identity Domain: Main Steps and WLST Example

The administrative identity domain is shown on the WebLogic Server Administration Console Domain > Security page.

If you are using the default security realm with the Default Authenticator only to store WebLogic Server administrator credentials, then you can accept the default idd_DOMAIN value. For more information, see 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, then you need to configure at least one authentication provider in the default realm to match your administrative identity domain value.

From the WebLogic Server Administration Console:

  1. Select the Authentication provider in the default realm and specify an existing administrative identity domain.

    1. In the navigation pane, select Security Realms.

    2. Select the default security realm.

    3. Select the Providers page.

    4. Select the Authentication provider.

    5. Select the Provider Specific page.

    6. Enter the name of a valid administrative identity domain in the Identity Domain field.

    7. Save your changes.

  2. Go to the Domain > Security page and change the Administrative Identity Domain: value to the name of the administrative identity domain.

  3. Save your changes.

  4. Restart the Administration Server.

Configuring the Administrative Identity Domain: WLST Example

The example does the following:

  1. Gets the domain MBean.
  2. Gets the security configuration for the domain.
  3. Sets the administrative identity domain for the security configuration.
  4. Gets the default realm for the security configuration.
  5. Looks up the default Authentication provider for the realm.
  6. Sets the identity domain for the default Authentication provider.

    Note:

    You must restart the Administration Server. Setting the administrative identity domain value is a nondynamic 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)

Configuring Security Realms and Primary Identity Domains: Main Steps and Examples

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 to achieve isolation between partitions.

If your user store does support identity domains, then configure the primary identity domain and the management 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 WebLogic Server Administration Console.

  1. Create a security realm. The name must be unique within the domain.

    If you are using Fusion Middleware Control, then go to WebLogic Domain > Security > Security Realms. The default providers are created on your behalf in the new realm.

    If you are using the WebLogic Server Administration Console, then in the navigation pane, select Security Realms. You will probably find it most convenient to select the option to create the default providers in the new realm.

  2. Add partition-specific users to the security realm.

    If you are using Fusion Middleware Control, go to WebLogic Domain > Security > Users and Groups. Select the security realm that you just created and on the Users and Groups pages, click Create to add users and groups to the realm.

    If you are using the WebLogic Server Administration Console, then in the navigation pane, select Security Realms. Select the security realm that you just created, and then the Users and Groups page. On the Users and Groups pages, click New to add users and groups to the realm.

  3. 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 WebLogic Server Administration Console.

  4. Optionally, select the Authentication provider that you just created and specify an existing identity domain. Identity domains are an optional feature that you can use only if your user store supports them.

    Perform this step from the WebLogic Server Administration Console.

    1. Select the Provider Specific page.

    2. In the Identity Domain field, enter the name of a valid identity domain.

    3. Save your changes.

  5. When you later create a partition as described in Configuring Domain Partitions, or if you created a partition when you created the domain using the Domain Configuration Wizard.

    1. Specify the security realm that you created.

      If you use the WebLogic Server Administration Console to configure a partition that you created using the Domain Configuration Wizard, select the security realm in the User Realm field on the Partition > Configuration > General page.

    2. Specify the identity domain that you set for the Authentication provider.

      If you use Fusion Middleware Control to create the domain partition, then specify the primary identity domain on the Create Domain Partition: General page. If you do not specify a value, then 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 WebLogic Server Administration Console to create the domain partition, then 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, go to the Partition >Configuration > General page and change the default name in the Primary Identity Domain field to your actual identity domain name.

    3. Set the management identity domain attribute in the realm to the same value that you used for the primary identity domain for the partition.

      Perform this step from the WebLogic Server Administration Console.

      Select Security Realms in the navigation pane. Select the security realm for the partition, then select Configuration > General and click Advanced. In the Management Identity Domain field, enter the name of the primary identity domain configured for the partition, and click Save.

Configuring Security Realms and Primary Identity Domains: WLST Example

The example does the following:

  1. Gets the domain MBean.

  2. Gets the security configuration for the domain.

  3. Sets the administrative identity domain for the security configuration.

  4. Gets the default realm for the security configuration.

  5. Looks up the default Authentication provider for the realm.

  6. Sets the identity domain for the default Authentication provider.

  7. Creates a new realm for the partition.

  8. Creates the required security providers for the new realm.

  9. Creates a domain partition.

  10. Creates a virtual target.

  11. Sets the host name and URI prefix for the virtual target.

  12. Adds the virtual target as an available target in the partition.

  13. Sets the security realm for the partition.

  14. Sets the primary identity domain for the partition.

  15. Sets the management identity domain for the partition.

  16. Creates the resource group.

  17. Adds the virtual target to the resource group.

  18. Activates the changes.

  19. Starts the partition.

Note:

You must restart the Administration Server before you can start the partition. Setting the administrative identity domain value is a nondynamic 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)


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/ !> partrealm.setManagementIdentityDomain('partID')
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('somehost')],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)

Configuring Security Realms and Primary Identity Domains: REST Example

For an example of creating domain partitions from Representational State Transfer (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, the primary identity domain, and the management 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 role can create system resources and deploy applications.

  • A resource group for each virtual target.

  • Partition users in the Administrator, Deployer, Monitor, and Operator roles.

For an example that demonstrates how to set the management identity domain on a partition, see "Managing Users and Groups as a Partition Administrator: REST Example"

Setting the Identity Domain-Aware Providers Required Control: Main Steps

The following WebLogic Server 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 Default Role Mapper and Default Authorizer, 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.

From the WebLogic Server Administration Console:

  1. Go to the Domain > Security page.
  2. Set the Identity Domain Aware Providers Required control.
  3. Save your changes.

Connecting Directly to Domain Partitions: Main Steps and WLST Example

You can connect directly to a domain partition using both Fusion Middleware Control and WLST, instead of logging in to the domain level. When you do this the user name that you specify is validated against the security realm and the management identity domain for that partition.

To login to a partition in Fusion Middleware Control:

  1. Enter the URL in your Web browser. For example:

    http://host1.example.com:7001/em

  2. Enter the partition user name and password and click Login to Partition.

  3. Enter the name of the partition in the Partition Name field and click Sign in.

    See Table 5-1 for the configuration and management capabilities of the WebLogic Server administrative roles when logged directly in to a partition.

Connecting Directly to Domain Partitions: WLST Example

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.

The initial view of the MBean hierarchy is partition-specific.

Using the Partition Name

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>

Using a Virtual Target

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, then 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\

Managing Security Data as a Partition Administrator: Main Steps and Examples

When logged in or connected to a partition as a member of the management identity domain, the partition administrator can manage the security realm data associated with the partition, such as managing users and groups, credential maps, roles, and policies. A partition administrator cannot change the configuration of the realm in this release.

Note:

To enable security management capabilities for the partition administrator, the system administrator must set the management identity domain attribute on the realm to be the same as the primary identity domain. See "Configuring Security Realms and Primary Identity Domains: Main Steps and Examples".

In Fusion Middleware Control, partition administrators can manage users and groups. To invoke additional security management operations on the supported MBeans, they can use WLST, REST APIs, or JMX.

An overview of the process is as follows:

  1. The system administrator configures a management identity domain on the realm. A partition administrator with the identity domain that matches this management IDD can invoke on the Security Runtime MBeans operations that control realm behavior. For example:

    • The system administrator configures the administrative identity domain on the Security Configuration MBean with the value idd-DOMAIN.

    • The system administrator configures partition Partition1 in the domain. The primary identity domain configured on the Partition MBean has the value idd-Partition1. Users that authenticate to Partition1 are part of the idd-Partition1 identity domain.

    • The system administrator configures a Partition1 realm in the domain and configures the management identity domain on the Realm MBean using the value idd-Partition1.

    • The system administrator creates the partition administration user and assigns it to the Administrators group.

    • Users with identity domain idd-DOMAIN (such as system administrators) and users with identity domain idd-Partition1 (such as partition administrators) can access the security management operations on the Realm MBean and security provider MBeans contained by the realm.

  2. The partition administrator can manage users and groups using Fusion Middleware Control.

  3. The partition administrator can navigate to the realm via the Partition MBean Realm attribute.

  4. The partition administrator can navigate to the security providers from the Realm MBean provider-related attributes.

  5. The partition administrator can invoke on a subset of the methods in the security provider MBeans. For a list of the MBean mixin interfaces for security providers available to the partition administrator, see Table 6-3 in "Security MBeans" in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server.

In a shared realm scenario with multiple partitions referring to one realm, the system administrator configures a management identity domain that matches the primary identity domain of one of the partitions. In this case, by default, only the users from the partition that matches can access the security management operations. The system administrator can also configure a separate authenticator that supports the management identity domain specifically and, in this case, users from all partitions that authenticate and specify the management identity domain can access the security management operations.

Table 5-2 lists the security management packages on which the partition administrator can invoke MBean operations when connected to the partition.

Table 5-2 Security Packages Accessible by a Partition Administrator

Package Description

weblogic.management.security

Provides interfaces and classes for the control and monitoring of security providers in a WebLogic security realm.

weblogic.management.security.audit

Provides interfaces and classes for the control and monitoring of Audit security providers in a WebLogic security realm.

weblogic.management.security.authentication

Provides interfaces and classes for the control and monitoring of Authentication security providers in a WebLogic security realm.

weblogic.management.security.authorization

Provides interfaces and classes for the control and monitoring of Authorization, Adjudication, and Role Mapping security providers in a WebLogic security realm.

weblogic.management.security.credentials

Provides interfaces and classes for the control and monitoring of Credential Mapping security providers in a WebLogic security realm.

weblogic.management.security.pk

Provides interfaces and classes for the control and monitoring of certification path security providers in a WebLogic security realm.

weblogic.management.utils

Provides interfaces and classes for the listing of data returned from security providers in a WebLogic security realm.

For details about how to manage the security realm using JMX, see "Managing Security Realms with JMX" in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server.

Managing Users and Groups as a Partition Administrator: Fusion Middleware Control Example

To manage users and groups using Fusion Middleware Control:

  1. Log into the partition as the partition administrator. Note that the partition administrator must be in the management identity domain set on the partition realm.
  2. From the Domain Partition menu, select Security, then Users and Groups.
  3. To create or monitor users, click the Users tab (if it is not already selected).

    • To create a new user, click Create. In the Create a User page, enter the user name, description, provider, and password, then click Create.

    • To edit the settings for an existing user, select the user name in the table. In the Settings for User page, edit the General Settings, Password, Attributes, and Groups as desired, then click Save.

  4. To create or monitor groups, click the Groups tab.

    • To create a new group, click Create. In the Create a Group page, enter the name, description, and provider for the group and click Create.

    • To edit the settings for an existing group, select the group name in the table. In the Settings for Group page, edit the General Settings and Membership for the group as desired, then click Save.

Creating a New User as a Partition Administrator: WLST Example

The following example demonstrates how to log into the partition Partition1 as the partition administrator, connect to the realm partition and authentication provider Partition1Realm/auth_provider2), list the available operations, and add a new user to the realm.

  1. Connect to the partition as the partition administrator P1Admin as described in "Connecting Directly to Domain Partitions: Main Steps and WLST Example".

    For example:

    wls:/offline> connect('P1Admin','password','t3://somehost:7001/partitions/Partition1')
Connecting to t3://somehost:7001/partitions/Partition1 with userid P1Admin ...
Successfully connected to partition "Partition1".
  2. Navigate to the authentication provider in the partition realm.

    For example:

    wls:/base_domain/serverConfig/Partitions/Partition1> cd ("Realm/Partition1Realm")
wls:/base_domain/serverConfig/Partitions/Partition1/Realm/Partition1Realm> 
cd("AuthenticationProviders/auth_provider2")
  3. List the available operations on the MBeans.

    For example:

    wls:/base_domain/serverConfig/Partitions/Partition1/Realm/Partition1Realm/AuthenticationProviders/auth_provider2> ls('o')
 
-r-x   addMemberToGroup                             Void : String(groupName),String(memberUserOrGroupName)
-r-x   advance                                      Void : String(cursor)
-r-x   changeUserPassword                           Void : String(userName),String(oldPassword),String(newPassword)
 
-r-x   close                                        Void : String(cursor)
-r-x   createGroup                                  Void : String(groupName),String(description)
-r-x   createUser                                   Void : String(userName),String(password),String(description)
-r-x   exportData                                   Void : String(format),String(filename),java.util.Properties
-r-x   getCurrentName                               String : String(cursor)
-r-x   getGroupDescription                          String : String(groupName)
-r-x   getSupportedUserAttributeType                javax.management.openmbean.OpenType : String(userAttributeName)
 
-r-x   getUserAttributeValue                        Object : String(userName),String(userAttributeName)
-r-x   getUserDescription                           String : String(userName)
-r-x   groupExists                                  Boolean : String(groupName)
-r-x   haveCurrent                                  Boolean : String(cursor)
-r-x   importData                                   Void : String(format),String(filename),java.util.Properties
-r-x   isMember                                     Boolean : String(parentGroupName),String(memberUserOrGroupName),Boolean(recursive)
-r-x   isUserAttributeNameSupported                 Boolean : String(userAttributeName)
-r-x   listAllUsersInGroup                          String[] : String(groupName),String(userNameWildcard),Integer(maximumToReturn)
-r-x   listGroupMembers                             String : String(groupName),String(memberUserOrGroupNameWildcard),Integer(maximumToReturn)
-r-x   listGroups                                   String : String(groupNameWildcard),Integer(maximumToReturn)
-r-x   listMemberGroups                             String : String(memberUserOrGroupName)
-r-x   listUsers                                    String : String(userNameWildcard),Integer(maximumToReturn)
-r-x   removeGroup                                  Void : String(groupName)
-r-x   removeMemberFromGroup                        Void : String(groupName),String(memberUserOrGroupName)
-r-x   removeUser                                   Void : String(userName)
-r-x   resetUserPassword                            Void : String(userName),String(newPassword)
-r-x   setGroupDescription                          Void : String(groupName),String(description)
-r-x   setUserAttributeValue                        Void : String(userName),String(userAttributeName),Object(newValue)
-r-x   setUserDescription                           Void : String(userName),String(description)
-r-x   userExists                                   Boolean : String(userName)
  4. Add a new user in the realm.

    For example:

    wls:/base_domain/serverConfig/Partitions/Partition1/Realm/Partition1Realm/AuthenticationProviders/auth_provider2> 
cmo.createUser("myuser2","mypassword2","A user in the Partition1 default authenticator")
  5. Verify that the new user was created successfully.

    For example:

    wls:/base_domain/serverConfig/Partitions/Partition1/Realm/Partition1Realm/AuthenticationProviders/auth_provider2> 
if cmo.userExists('myuser2'):
  print "User myuser2 added"
...
User myuser2 added

Managing Users and Groups as a Partition Administrator: REST Example

For an example of managing security data as a partition administrator in a partition from Representational State Transfer (REST), see "Configuring Users" in Administering Oracle WebLogic Server with RESTful Management Services.

This example demonstrates how the partition administrator creates deployer, operator, and monitor users for the partition and assigns them to their respective groups.

Configuring SSL in Domain Partitions

Secure Sockets Layer (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.

However, note the following important differences:

  • If you configure an explicit or offset port for the virtual target as described in Configuring Virtual Targets, then SSL is not supported for that virtual target.

    This means that clients (for example, Remote Method Invocation (RMI) clients) cannot communicate directly over SSL to a partition that uses port-based routing.

  • CertPath providers configured in nondefault 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.

Configuring Security in Domain Partitions: Related Tasks and Links

See the following for additional information: