WebLogic Server offers a robust set of security tools to protect your WebLogic Server environment from unauthorized access. Use WebLogic Remote Console to secure your system.
For general information on security concepts in WebLogic Server, see:
WebLogic Server regularly checks your domain to ensure it complies with its recommended security policies. If a domain does not meet the recommendations, a security warning is logged and displayed in WebLogic Remote Console.
When there are active security warnings in your domain, a red banner appears across the top of the WebLogic Remote Console window. It will remain until you have fixed the security issue.
For more information on the issues that might trigger a security warning, see Review Potential Security Issues in Securing a Production Environment for Oracle WebLogic Server.
Do not rely on the Security Warnings Report alone to determine the security of your domain. While these security configuration settings cover a broad set of potential security issues, other security issues that do not generate warnings may still exist in your domain.
Environments running WebLogic Server 14.1.1.0 and earlier require the July 2021 Patch Set Update (PSU) to see security warnings.
In the Security Warnings banner, click View/Refresh Report to see which issues have been flagged.
You can also get to the Security Warnings page through the Monitoring perspective, then Environment, then Domain Security Runtime.
Review the description of the issue to understand the security warning.
Follow the steps suggested in Resolution Information to fix the problem.
The same issue can affect multiple servers within your domain simultaneously. Make sure to fix the issue on every affected server.
If you think certain policies don’t apply to your environment or are not feasible to implement with your business needs, you can disable individual security checks, with the exception of the minimum JDK version check.
If necessary, restart the servers to apply the fix and clear the security warnings.
For the latest information on security warnings and their suggested steps for resolution, see the My Oracle Support article, WebLogic Server Security Warnings (Doc ID 2788605.1).
The same issue may affect multiple servers within your domain simultaneously. As you review the Security Warnings Report, make sure that you fix the issue on every affected server. Depending on the problem and its resolution, you may need to restart servers to update the Security Warnings Report.
A security realm is a collection of mechanisms designed to protect WebLogic Server resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. A user must be defined in a security realm in order to access any WebLogic resources belonging to that realm.
For more information, see Security Realms in Understanding Security for Oracle WebLogic Server.
WebLogic Server provisions each new domain with a security realm with pre-configured security configurations. See The Default Security Configuration in WebLogic Server in Administering Security for Oracle WebLogic Server.
If the default security configurations do not meet your requirements, you can create a new security realm with custom settings and providers and set it as the default security realm. See Customizing the Default Security Configuration in Administering Security for Oracle WebLogic Server.
You can set WebLogic Server to immediately apply non-dynamic changes to a security realm without restarting WebLogic Server. See Enable Automatic Realm Restart.
For a security realm to be valid, the following security providers must be configured:
WebLogic Server includes a default option for each of the required security providers, plus alternative options if the default provider does not suit your needs. You can also create your own custom providers.
A security realm organizes the security configurations of a domain.
Before you create a new security realm, review the considerations outlined in Before You Create a New Security Realm in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms.
Click New.
Enter a name for the new security realm.
Turn on the Create Default Providers option if you want WebLogic Server to add the required security providers to the security realm, ensuring that the new security realm is valid.
You can modify the default providers or replace them with another provider as needed.
If you do not enable Create Default Providers, then you must manually configure the required security providers before you can commit the new security realm. For a list of which security providers are required, see Required Security Providers.
Click Create.
You can configure WebLogic Server to replace the default security configurations with a custom security realm.
Although you can customize the original default security configuration, Oracle recommends creating an entirely new security realm and making changes to security configurations there, which allows you to easily revert to the original default security configuration if necessary.
If you haven’t done so already, create a new security realm. See Create a Security Realm.
In the Edit Tree, go to Environment, then Domain.
Select the Security tab.
From the Default Realm drop-down list, select the security realm that you want to make the default.
Click Save.
Consider enabling the configuration archive to save previous domain configurations so you can revert to a previous security configuration if necessary. See Back Up Configuration Files.
Certain mistakes when configuring a new security realm or security providers can prevent you from booting the server. If this happens, then you can revert the configuration XML files to reinstate a previous realm configuration and recover from the error.
You can only revert to a previous configuration if configuration archiving is enabled and has been saving previous versions of the configuration. See Back Up Configuration Files.
You can also use WLST Offline to correct a mistake that prevents you from booting the server.
This process will only revert your security realm (meaning, the configuration of the realm and its providers), not the users, groups, roles, or security policies used by the realm, which are persisted in a data store and not in the configuration files.
Locate the config.jar file that contains the security configuration to which you want to revert, copy it to a temporary directory, and unpack it.
Copy the unpacked configuration files to the appropriate location in the DOMAIN_HOME/config directory. For information about which directories hold which configuration files, see Domain Directory Contents in Understanding Domain Configuration for Oracle WebLogic Server.
Restart WebLogic Server.
You can set WebLogic Server to immediately apply non-dynamic changes to a security realm without restarting WebLogic Server.
In the default security realm, automatic realm restart is disabled by default. In new security realms that you create, automatic realm restart is enabled by default.
For more information, see Using Automatic Realm Restart in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms, then myRealm.
Enable the Automatically Restart after Non-Dynamic Changes option.
Click Save.
The WebLogic Security Service supports a wide variety of security architectures, including multiple security providers.
Before you configure security providers for your WebLogic security realm, you should have a good understanding of how the WebLogic Security Service works and what sort of security architecture you want for your WebLogic environment. See:
Your security architecture can consist of a combination of the default security providers included in WebLogic Server, security providers developed by third parties, or custom security providers that you develop yourself.
Types of security providers include:
Use authentication providers to prove the identity of users or system processes. The WebLogic Authentication provider and WebLogic Identity Assertion provider are enabled by default but you can configure additional authentication or identity assertion providers as needed.
For more information about the authentication and identity assertion providers included in WebLogic Server, see Choosing an Authentication Provider in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms, then myRealm, then Authentication Providers.
Click New.
In the Name field, enter a name for the new provider.
From the Type drop-down list, select the type of authentication provider.
Click Create.
On the Configuration page for the new authentication provider, set the appropriate values on the Common and Provider-Specific Parameters tabs.
Click Save.
We recommend that you configure the Password Validation provider immediately after configuring a new WebLogic domain. The password validation provider, which is included with WebLogic Server, can be configured with several out-of-the-box authentication providers to manage and enforce password composition rules. Whenever a password is created or updated in the security realm, the corresponding authentication provider automatically invokes the password validation provider to ensure that the password meets the established composition requirements. For more information, see Configure the Password Validation Provider.
If you have multiple Authentication providers in your domain, use the JAAS control flag to control how each Authentication provider is used in the login sequence.
For information on how WebLogic Server handles multiple Authentication providers, see Using More Than One Authentication Provider in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms and choose the security realm where you want to make changes.
Expand the Authentication Providers node and choose the Authentication provider that you want to configure.
Select an option from the Control Flag drop-down list:
Click Save.
Repeat for the rest of the Authentication providers in the domain.
Use Authorization providers to determine who has access to a resource.
For more information on Authorization providers, see Configuring an Authorization Provider in Administering Security for Oracle WebLogic Server.
The WebLogic Authorization provider was deprecated in WebLogic Server 14.1.1.0.0 and will be removed in a future release. The XACML Authorization provider is the default provider.
In the Edit Tree, go to Security, then Realms, then myRealm, then Authorizers.
Click New.
In the Name field, enter a name for the new provider.
From the Type drop-down list, select the type of Authorization provider.
Click Create.
On the new Authorization provider page, set the desired values.
Click Save.
An Adjudication provider resolves authorization conflicts by weighing each Authorization provider’s access decision and determining whether to permit access to the requested resource.
If you only have one Authorization provider configured in the security realm and it is the WebLogic Authorization provider, then an ABSTAIN returned from the single Authorization provider is treated as a DENY.
Each security realm must have one, and only one, Adjudication provider.
WebLogic Server offers one Adjudication provider for the WebLogic Security Framework: the WebLogic Adjudication provider. Note that WebLogic Remote Console refers to the WebLogic Adjudication provider as the Default Adjudicator.
For more information on Adjudication providers, see Configuring the WebLogic Adjudication Provider in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms, then myRealm, then Adjudicator.
Click Create.
In the Name field, enter a name for the new provider.
From the Type drop-down list, select the type of Adjudication provider.
Click Create.
On the new Adjudication provider page, set the appropriate values on the Default Adjudicator Parameters tab.
Click Save.
Role mapping is the process whereby principals (users or groups) are dynamically mapped to security roles at runtime. A Role Mapping provider determines what security roles apply to the principals stored in a subject when the subject is attempting to perform an operation on a WebLogic resource.
Since these operations usually involve gaining access to a WebLogic resource, Role Mapping providers are typically used with Authorization providers.
The WebLogic Role Mapping provider was deprecated in WebLogic Server 14.1.1.0.0 and will be removed in a future release. The XACML Role Mapping provider is the default provider.
For more information on Role Mapping providers, see Configuring a Role Mapping Provider in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms, then myRealm, then Role Mappers.
Click New.
In the Name field, enter a name for the new provider.
From the Type drop-down list, select the type of Role Mapping provider.
Click Create.
On the new Role Mapping provider page, update values as necessary.
Click Save.
An Auditing provider collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation.
You can configure multiple Auditing providers in a security realm, but none are required. The default security realm does not include an Auditing provider.
WebLogic Auditing provider is the standard Auditing provider for the WebLogic Security Framework. Note that the WebLogic Remote Console refers to the WebLogic Auditing provider as the Default Auditor.
You can also configure WebLogic Server to audit configuration actions. See Enable Configuration Auditing.
For more information on Auditing providers, see Configuring the WebLogic Auditing Provider.
In the Edit Tree, go to Security, then Realms, then myRealm, then Auditors.
Click New.
In the Name field, enter a name for the new provider.
Click Create.
On the new Auditing provider page, set the appropriate values on the Default Auditor Parameters tab.
Click Save.
A Credential Mapping provider allows WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated. You must have one Credential Mapping provider in a security realm, and you can configure multiple Credential Mapping providers in a security realm.
For more information on Credential Mapping providers, see Configuring Credential Mapping Providers in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms, then myRealm, then Credential Mappers.
Click New.
In the Name field, enter a name for the new provider.
From the Type drop-down list, select the type of Credential Mapper.
Click Create.
On the new Credential Mapping provider page, update the values on the Default Credential Mapper Parameters tab as necessary.
Click Save.
After you have configured a credential mapping provider, you can map credentials to WebLogic resources. You can create credential mappings for the following WebLogic Server resources:
The general process is:
Certain WebLogic resources require that you manually form a connection between its MBean configuration data and its security data.
As part of this process, you will create the first credential mapping for the resource.
You must configure the WebLogic resource before you can add any mappings.
In the Security Data Tree, go to Realms, then myRealm, then Credential Mappers.
Continue until you reach the WebLogic resource that you want to prepare for credential mappings.
For example:
Click New and fill in the fields as necessary.
Click Create.
A reference to the resource is added under the resource’s node. The name of the resource is generated by combining its property values.
You cannot delete a reference to a resource with multiple credential mappings. To delete a resource reference, you must delete all of the credential mappings first - which will then delete the resource reference automatically.
You can add a new credential mapping to associate another WebLogic resource to a remote user.
In the Security Data Tree, go to Realms, then myRealm, then Credential Mappers, then credentialMappingProvider, then wlResourceType, then wlResourceName, then Credential Mappings.
Click New.
Fill in the fields as needed.
If you want to map to a remote user that is already referenced in the remote resource, disable the Create Credential option.
Click Create.
The credential mappings and credentials for each WebLogic resource appear under the resource’s node.
When you delete a credential mapping, the remote user that the WebLogic resource was previously associated with is also deleted if it was the only credential mapping using that remote user.
You can edit a credential mapping to associate a WebLogic user for a WebLogic resource to a different remote user.
WebLogic Remote Console must already be aware of the remote user before you can remap the WebLogic Server user. If you want to remap the WebLogic resource to a new remote user, you must first add it to WebLogic Remote Console.
In the Security Data Tree, go to Realms, then myRealm, then Credential Mappers, then credentialMappingProvider, then wlResourceType, then wlResourceName, then Credential Mappings.
Select the credential mapping that you want to edit.
In the Remote User field, replace the username of the current remote user with the username of the remote user that you want to remap the WebLogic resource to.
Click Save.
After you have added the first set of credentials for a remote system to a WebLogic resource, you can add more users from that remote system.
In the Security Data Tree, go to Realms, then myRealm, then Credential Mappers, then credentialMappingProvider, then wlResourceType, then wlResourceName, then Credentials.
Click New.
Enter the username and password for the remote user.
Click Create.
You can now map a WebLogic user for the WebLogic resource to the new set of credentials.
If the password of the remote user changes, you’ll need to update it in WebLogic Remote Console or the mapping will break and prevent the WebLogic resource from logging into the remote system.
Each WebLogic resource has its own set of credentials. Removing a set of credential from WebLogic Remote Console will not affect the user in the remote system.
You cannot delete a credential that currently has a WebLogic resource mapped to it.
In the Security Data Tree, go to Realms, then myRealm, then Credential Mappers, then credentialMappingProvider, then wlResourceType, then wlResourceName, then Credentials.
If the set of credentials that you want to delete has an active credential mapping, you can either:
Under the same WebLogic resource, expand the Credentials node.
Delete the set of credentials.
Click Save.
A Certification Path provider completes and validates certificate chains by using trusted CA based checking.
The provider checks the signatures in the chain, ensures that the chain has not expired, and confirms that one of the certificates in the chain is issued by one of the server’s trusted CAs. If any of these checks fail, the chain is not valid. Optionally, the provider checks the certificate chain’s basic constraints.
For more information on certificate validation on WebLogic Server, see Configuring the Certificate Lookup and Validation Framework in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms, then myRealm, then Cert Path Providers.
Click New.
In the Name field, enter a name for the new provider.
Click Create.
If you want to make this Certification Path provider the current builder of certificate chains for this realm, perform the following steps:
In the Edit Tree, go to Security, then Realms, then myRealm.
On the Cert Path Builder tab, select the Certification Path provider from the Cert Path Builder drop-down list.
Click Save.
When configured in a security realm, the Password Validation provider is automatically invoked by a supported authentication provider whenever a password is created or updated for a user in that realm. The Password Validation provider then performs a check to determine whether the password meets the criteria established by the composition rules, and the password is accepted or rejected as appropriate.
The password composition rules you can configure for the Password Validation provider include:
Passwords cannot contain a curly brace { as the first character.
If the Default Authentication provider is configured in the security realm, make sure that the setting for the minimum password length is consistent in both the Default Authentication provider and the Password Validation provider.
In the Edit Tree, go to Security, then Realms, then myRealm, then Password Validators.
Click New.
Enter a name for the password validator.
Click Create.
On the configuration page of the password validator that you just created, select the System Password Validator Parameters tab.
Use the configuration options to determine the criteria for an acceptable password.
Click Save.
If the security providers provided by WebLogic Server do not meet the needs of your environment, then you can design your own custom security providers.
Create a custom security provider. For guidance, see Introduction to Developing Security Providers for WebLogic Server in Developing Security Providers for Oracle WebLogic Server.
Place the MBean JAR file for the custom provider in the WL_HOME/server/lib/mbeantypes directory.
Add the custom security provider to the domain’s security realm using WLST or the WebLogic Server RESTful management interface.
If you are adding a deployable Authorization provider and the provider does not support parallel security policy, then set the RealmMBean.DeployableProviderSynchronizationEnabled attribute to true. Next, for the RealmMBean.DeployableProviderSynchronizationTimeout attribute, enter a timeout value (in milliseconds) or accept the default value.
If you are adding a deployable Role Mapping provider and the provider does not support role modification, then set the RealmMBean.DeployableProviderSynchronizationEnabled attribute to true. Next, for the RealmMBean.DeployableProviderSynchronizationTimeout attribute, enter a timeout value (in milliseconds) or accept the default value.
For more information, see Is Your Custom Authorization Provider Thread Safe? or Is Your Custom Role Mapping Provider Thread Safe? in Developing Security Providers for Oracle WebLogic Server.
After you add the custom security provider to the security realm, you can use WebLogic Remote Console to configure and manage the inherited, standard attributes of the custom security provider. However, you cannot use WebLogic Remote Console to manage the custom attributes from your MDF file.
The embedded LDAP server contains user, group, group membership, security role, security policy, and credential map information. By default, each WebLogic Server domain has an embedded LDAP server configured with the default values set for each attribute.
The WebLogic Authentication, Authorization, Credential Mapping, and Role Mapping providers use the embedded LDAP server as their database. If you use any of these providers in a new security realm, you may want to change the default values for the embedded LDAP server to optimize its use in your environment.
In the Edit Tree, go to Environment, then Domain.
On the Security tab, select the Embedded LDAP subtab.
Update the values as appropriate for your environment.
Consider updating the settings for backing up for the embedded LDAP servers. Specifically Backup Hour, Backup Minute, and Backup Copies. For information on how WebLogic Server backs up data for the embedded LDAP server, see Backup and Recovery in Administering Security for Oracle WebLogic Server.
Click Save and commit your changes.
Restart the server.
The WebLogic Security providers store their data in the embedded LDAP server. When you delete a WebLogic Security provider, the security data in the embedded LDAP server is not automatically deleted. The security data remains in the embedded LDAP server in case you want to use the provider again. Use an external LDAP browser to delete the security data from the embedded LDAP server.
WebLogic Server employs users and groups to control access to its resources.
Users are entities that can be authenticated in a security realm. A user can be a person, such as application end user, or a software entity, such as a client application, or other instances of a WebLogic Server. As a result of authentication, a user is assigned an identity or principal. Each user is given a unique identity within the security realm. Users may be placed into groups that are associated with security roles, or can be directly associated with security roles.
Groups are logically ordered sets of users. Users are organized into groups that can have different levels of access to WebLogic resources, depending on their job functions. Managing groups is more efficient than managing large numbers of users individually. All user and group names must be unique within a security realm.
For more information, see Users, Groups, And Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
WebLogic Remote Console can only add, edit, or delete the users and groups within the default authentication provider (WebLogic Authentication Provider). If you are using another authentication provider that supports the required WebLogic Server APIs, you can view its users and groups in WebLogic Remote Console, but to manage them, you’ll need to use an external tool specific to the provider. Providers that do not support the required WebLogic Server APIs do not appear in the Security Data tree.
You can add users to the WebLogic Authentication provider.
In the Security Data Tree, go to Realms, myRealm, then Authentication Providers, then DefaultAuthenticator, then Users.
Click New.
Enter a Name, Description, and Password for the user.
User names must be unique in the security realm and passwords must be eight characters or longer.
Click Create.
If you want to add the new user to a group, then under the Membership tab, select a group under the Available section and move it to the Chosen section.
User groups provide an efficient way to manage multiple users with the same responsibilities.
You can add groups to the WebLogic Authentication provider.
In the Security Data Tree, go to Realms, myRealm, then Authentication Providers, then DefaultAuthenticator, then Groups.
Click New.
Enter a Name (and optionally, a Description) for the group.
Group names must be unique in the security realm.
Click Create.
You can nest a group under another so it inherits policies. Under the Membership tab, move groups from Available over to Chosen and the current group will be nested under the Chosen groups.
You can control how many login attempts can be made by the same user account before WebLogic Server locks the account.
For more information, see How Passwords Are Protected in WebLogic Server and Protecting User Accounts in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Security, then Realms, then myRealm.
On the User Lockout tab, turn on the Lockout Enabled option.
In the Lockout Threshold field, set the maximum number of invalid user login attempts that you want to allow before the user account is locked.
Modify any additional user lockout attributes as necessary.
Click Save.
You can unlock user accounts that became locked because of excessive failed login attempts on a per server basis.
In the Monitoring Tree, go to Environment, then Servers, then myServer.
Go to Security, then Realm Runtimes, then myRealm.
Click Unlock User.
Enter the username of the locked user account. If applicable to your domain, you can also enter the identity domain.
Click Done.
If you added an authentication provider other than the default authentication provider (WebLogic Authentication Provider) to your security realm, you can view its users and groups but you cannot edit them in WebLogic Remote Console.
In the Security Data Tree, go to Realms, myRealm, then Authentication Providers.
Select the authentication provider whose users and groups you want to view.
Expand the Users or Groups nodes to view the users and groups.
To edit these users and groups, you’ll need to use an external tool specific to the provider.
Use security policies to manage who can access a resource in a WebLogic Server domain.
A resource is an entity (such as a Web Service or a server instance) or an action (such as a method in a Web Service or the act of shutting down a server instance). For a list of resource types, see Resource Types You Can Secure with Policies in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
A security policy specifies which users, groups, or roles can access the resource according to a set of conditions. Whenever possible, you should use security roles to determine access control. A security role, like a security group, grants an identity to a user. Unlike a group, however, membership in a role can be based on a set of conditions that are evaluated at runtime.
For most types of WebLogic resources, you can use WebLogic Remote Console to define the security policies and roles that restrict access. For Web applications and EJB resources, you can also use deployment descriptors.
The general process to secure a WebLogic resource is:
For more information, see Securing Resources Using Roles and Policies for Oracle WebLogic Server.
A security role is an identity granted to users or groups based on specific conditions. Multiple users or groups can be granted the same security role and a user or group can be assigned more than one role. Security roles are used by policies to control access a WebLogic resource.
WebLogic Server provides a default set of roles that you can use with any policy. These are called global roles and you can create your own if the default global roles do not meet your needs.
You can also create roles that are only used by policies for a specific resource. These are called scoped roles. For example, You can create a scoped role for a specific EJB that contains highly sensitive business logic. When you create a policy for the EJB, you can specify that only the scoped role can access the EJB.
If two roles conflict, the role of a narrower scope overrides the role of the broader scope. For example, a scoped role for an EJB resource overrides a global role or a scoped role for the enterprise application that contains the EJB.
Security roles are created within a security realm, and the roles can be used only when the realm is active.
For more information, see Overview of Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Create a new role that applies to all WebLogic resources deployed within a security realm (and thus the entire WebLogic Server domain).
Before creating a new global security role, review the Default Global Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server to assess if an existing role is sufficient for your needs.
In the Security Data Tree, go to Realms, then myRealm, then Role Mappers, then XACMLRoleMapper, then Global, then Roles.
Click New.
Enter a name for the new global role.
Click Create.
After a role is created, you can build a policy that uses conditions to determine which users or groups it encompasses. We recommend that whenever possible, you use the Group condition which grants the security role to all members of a specified group.
Create a new role that can only be used with policies that apply to specific resources.
In the Security Data Tree, go to Realms, then myRealm, then Role Mappers, then XACMLRoleMapper, then myResource, then Roles.
myResource is the node path to the resource and may contain multiple node children. For example, to create a scoped role for a queue in a JMS module, your path would be …XACMLRoleMapper, then JMS Modules, then jmsModuleName, then Queues, then queueName, then Roles.
Click New.
Enter a name for the new scoped role.
Click Create.
After a role is created, you can build a policy that uses conditions to determine which users or groups it encompasses. We recommend that whenever possible, that you use the Group condition which grants the security role to all members of a specified group.
A security policy specifies the conditions that users, groups, or roles must meet to access a resource. Policies must have one or more conditions and you can combine conditions to create complex policies for more dynamic access control.
Root level policies apply to all instances of a specific resource type, for example, all JMS resources in your domain. All default security policies are root level policies.
You can also create policies that only apply to a specific resource instance. If the instance contains other resources, the policy will apply to the included resource as well. For example, you can create a policy for an entire JMS system resource, or for a particular queue or topic within that resource.
The policy of a narrower scope overrides policy of a broader scope. For example, if you create a security policy for a JMS system resource and a policy for a JMS queue within that system resource, the JMS queue will be protected by its own policy and will ignore the policy for the system resource.
For more information, see Security Policies in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
It’s recommended that you use the Role condition where possible. Basing conditions on security roles lets you create one security policy that takes into account multiple users or groups, and is a more efficient method of management.
See Security Policy Conditions in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
You can build and edit a policy by modifying a condition’s arguments or by modifying the relationships between conditions in the policy.
You can only edit the arguments of the condition. If you want to use a different predicate for the condition, you must add a new condition.
Conditions have three different types of relationships: AND, OR, and Combination.
AND: All of the conditions joined by an AND operator must be met.OR: At least one of the conditions joined by an OR operator must be met.Combination: Two or more conditions are combined and must be evaluated as a group. Conditions within a combination are themselves related to each other through AND or OR operators.By default, a new condition is added as a simple condition at the top of the list of conditions. To insert a new condition elsewhere, select an existing condition and then click Add Condition. You will get a drop-down list with options to add the new condition either above or below the selected condition. The order of conditions is not meaningful to how the policy is interpreted.
A policy can contain multiple simple or compound conditions or a mix of simple and compound conditions. You can also nest compound conditions.
Why should you use compound conditions? Consider the following scenario: a resource exists where you want Administrators to always have access, but to restrict Deployer access to between 9 a.m. and 5 p.m EST. The following policy would address both requirements:
OR
AND access occurs between 09:00:00 and 17:00:00 GMT -5:00Use the actions on the Policy page to edit a policy.
| Action | Description |
|---|---|
| Add Condition |
Adds a new condition to the policy. You can choose to add the new condition above or below another condition. |
| Combine |
When multiple conditions are selected, you can combine them to create a compound condition. |
| Uncombine |
When a compound condition is selected, you can break it into independent (simple) conditions. |
| Remove |
Deletes a simple or compound condition from the policy. When there are no conditions in a policy, the default policy applies. |
| Negate |
Reverses the meaning of a condition. The criteria to access a resource becomes the opposite of the original condition. |
| Reset |
Reverts the policy to its last saved change, not the last change. It's recommended that you save your policy frequently or you may lose several changes unintentionally using the Reset action. |
You can also edit a policy from its Advanced tab where the policy is expressed as string. Any changes made to a policy in the Advanced tab are reflected in the main Policy tab, and vice versa.
To delete a policy, simply delete all of its conditions. Confirm that the default security policy for the resource instance will provide adequate access control before you delete a policy.
You can create a security policy that only applies to a specific resource instance. If the instance contains other resources, the policy will apply to the included resources as well.
In the Security Data Tree, go to Realms, then myRealm, then Authorizers, then XACMLAuthorizer, then myResourceInstance.
myResourceInstance is the node path to the resource instance and may contain multiple nodes. For example, to create a policy for a queue in a JMS module, your path would be “…XACMLAuthorizer, then JMS Modules, then jmsModuleName, then Queues, then queueName.”
Click Add Condition.
Select a predicate from the Predicate List. Depending on the predicate you choose, you may need to configure arguments for the condition.
Click OK.
Click Save.
Add more conditions to the policy to increase its complexity.
WebLogic Server uses private keys, digital certificates, and trusted certificates issued by certificate authorities to establish and verify server identity and trust.
WebLogic Server provides a default identity keystore and a default trust keystore. These default keystores are appropriate for testing and development purposes only.
DemoIdentity.jks and DemoTrust.jks, respectively.DemoIdentity.p12 and DemoTrust.p12, respectively.Additionally, WebLogic Server trusts the certificate authorities in the cacerts file in the JDK.
For more information, see:
If you are using the demo certificates in a multi-server domain, Managed Server instances will fail to boot if you specify the fully-qualified DNS name. For information about this limitation and suggested workarounds, see Limitation on CertGen Usage in Administering Security for Oracle WebLogic Server
The OPSS Keystore Service (KSS) provides an alternative mechanism to manage keys and certificates for message security. See Managing Keys and Certificates in Securing Applications with Oracle Platform Security Services. The OPSS KSS makes using certificates and keys easier by providing central management and storage of keys and certificates for all servers in a domain. You can use the OPSS KSS to create and maintain keystores of type KSS. If the Oracle Java Required Files (JRF) template is installed on the WebLogic Server system, you have the option to use KSS keystores. The KSS keystore is available only with the JRF template and is not available with the default WebLogic Server configuration.
Obtain digital certificates, private keys, and trusted CA certificates from the CertGen utility, the keytool utility, the OPSS Keystore Service, or a reputable vendor that creates and signs certificates for use on the internet. You can also use the digital certificates, private keys, and trusted CA certificates provided by WebLogic Server. The demonstration digital certificates, private keys, and trusted CA certificates should be used in a development environment only.
See Configure Keystores.
If using KSS, verify whether KSS is properly populated, and note the KSS URIs and aliases of the required certificates and keys. You will need the KSS URIs and key aliases when specifying keystores, keys, and certificates.
Store the private keys, digital certificates, and trusted CA certificates. Private keys and trusted CA certificates are stored in a keystore. If using KSS, import the required keys and certificates to KSS.
Configure the identity and trust keystores for a WebLogic Server instance. See Configure Keystores.
Configure SSL/TLS attributes for the server. These attributes describe the location of the identity key and certificate in the keystore. See Set Up SSL/TLS.
WebLogic Server uses private keys, digital certificates, and trusted certificates issues by certification authorities to establish and verify server identity and trust. You can use JKS or PKCS12 keystores for identity and trust.
For more information, see Configuring Keystores in Administering Security for Oracle WebLogic Server.
For testing and development purposes only, WebLogic Server provides a demonstration identity keystore and a demonstration trust keystore. For production environments, you should configure your own identity and trust keystores.
DOMAIN_NAME/security/DemoIdentity.jks and WL_HOME/server/lib/DemoTrust.jks, respectively.DOMAIN_NAME/security/DemoIdentity.p12 and DOMAIN_NAME/security/DemoTrust.p12, respectively.Additionally, the JDK installation provides the cacerts truststore in JKS format at JDK/lib/security/cacerts
If you are using custom identity and custom trust keystores:
Obtain private keys and digital certificates from a reputable third-party certificate authority (CA).
Create identity and trust keystores.
Load the private keys and trusted CAs into the keystores.
In the Edit Tree, go to Environment, then Servers, then myServer.
Click the Security tab, then the Keystores tab.
From the Keystores drop-down list, select a type for storing and managing private keys/digital certificate pairs and trusted CA certificates.
Demo Identity and Demo Trust - Select this option to use the demo certificates (suitable for development and testing). This is the default setting, and uses the demonstration identity and trust keystores, and the JDK cacerts keystore.
To use a KSS keystore for demo identity and trust, you must first enable the Use KSS For Demo option (on the Environment: Domain page, under the Security tab (click Show Advanced Fields)) which determines whether the Demo Identity and Demo Trust key stores should be obtained from the Oracle Key Store Service (KSS).
Custom Identity and Java Standard Trust - Select this option to use an identity keystore you created and the trusted CAs that are defined in the cacerts file in the JAVA_HOME/jre/lib/security directory.
Custom Identity and Custom Trust - Select this option to use both identity and trust keystores that you created.
Custom Identity and Command Line Trust - Select this option to use an identity keystore that you created, but the trust keystore is passed as an argument in the command that starts WebLogic Server.
Define attributes for the identity and trust keystores. Depending on the keystore type that you selected, different options are available.
Click Save.
Repeat on all applicable servers.
If you are updating a keystore configuration and have SSL/TLS configured already, you can check that all SSL/TLS connections exist according to the specified connection. In the Monitoring Tree, go to Environment, then Servers. Restart the applicable servers.
If you enabled custom keystores and want to use Node Manager to start Managed Servers, you must also update the nodemanager.properties file to match.
At minimum, update the following node manager properties as applicable to your environment:
CustomIdentityAliasCustomIdentityKeyStoreFileNameCustomIdentityPrivateKeyPassPhraseCustomIdentityKeyStorePassPhraseKeyStores
See Node Manager Properties in Administering Node Manager for Oracle WebLogic Server.WebLogic Server’s JSSE implementation supports X.509 certificate revocation (CR) checking, which checks a certificate’s revocation status as part of the SSL/TLS certificate validation process. CR checking improves the security of certificate usage by ensuring that received certificates have not been revoked by the issuing certificate authority. By default, CR checking is disabled in WebLogic Server.
WebLogic Server’s CR checking implementation includes both the Online Certificate Status Protocol (OCSP) and certificate revocation lists (CRLs). For more information, see X.509 Certificate Revocation Checking in Administering Security for Oracle WebLogic Server.
Ensure that you have configured the identity and trust keystores for WebLogic Server. See Identity and Trust.
In the Edit Tree, go to Environment, then Domain.
On the Security tab, click the SSL Certificate Revocation Checking subtab.
Turn on the Enable Certificate Revocation Checking option.
Select a revocation checking method from the Revocation Checks drop-down list. The default is OCSP_THEN_CRL.
Use the OCSP and CRL tabs to customize settings for the revocation checking method. For information on the options, see Using the Online Certificate Status Protocol or Using Certificate Revocation Lists in Administering Security for Oracle WebLogic Server.
If you want a certificate whose revocation status cannot be determined to fail SSL/TLS certificate path validation, turn on the Fail on Unknown Revocation Status option.
When this option disabled, if an X.509 certificate’s revocation status cannot be determined, but the SSL/TLS certificate path validation is otherwise successful, the certificate will be accepted.
Click Save.
You can configure certificate authority overrides to the certificate revocation configuration. See Configure Certificate Authority Overrides.
Configuring a certificate authority override allows you to specify CR checking behavior that is specific to certificates issued by a particular certificate authority (CA). A certificate authority override always supersedes the corresponding certificate revocation (CR) checking configuration that is set at the domain level.
A certificate authority override can be used to supersede, for a given CA, any domain-wide CR checking configuration settings, with the exception of the CRL local cache, which is configured on a domain-wide basis only.
If you haven’t done so already, enable certificate revocation checking as described in Enable Certificate Revocation Checking.
In the Edit Tree, go to Security, then Certificate Authority Overrides.
Click New and then enter a name for the new certificate authority override.
Click Create.
In the Distinguished Name field, enter the distinguished name of the CA. This must be the complete issuer distinguished name (defined in RFC 2253) of the certificates for which this override applies.
For example, CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState,C=US.
Use the General, OCSP, and CRL tabs to modify the settings as necessary for your environment. For descriptions of the attributes and when you might want to configure them, see:
Click Save.
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), ensure secure connections by allowing two applications connecting over a network connection to authenticate the other’s identity and by encrypting the data exchanged between the applications.
Authentication allows a server and optionally a client to verify the identity of the application on the other end of a network connection. Encryption makes data transmitted over the network intelligible only to the intended recipient.
WebLogic Server supports SSL/TLS on a dedicated listen port which defaults to 7002. To establish an SSL/TLS connection, a Web browser connects to WebLogic Server by supplying the SSL/TLS listen port and the HTTPs protocol in the connection URL, for example, https://myserver:7002.
You can configure SSL/TLS as either one-way or two-way.
For more information on how SSL/TLS is used in WebLogic Server, see Configuring SSL in Administering Security for Oracle WebLogic Server.
Although the terms TLS, SSL, and SSL/TLS are used interchangeably throughout WebLogic Server documentation, it is expected and encouraged that you use a currently supported version of TLS, not SSL, to secure communication in WebLogic Server.
Establish secure communication between multiple applications connecting over a network connection.
Configure the identity and trust keystores for WebLogic Server. See Configure Keystores.
In the Edit Tree, go to Environment, then Servers, then myServer.
Click the Security tab, then the SSL subtab.
Set SSL/TLS attributes for the private key alias and password.
In the Server Private Key Alias field, enter the keystore attribute that defines the string alias used to store and retrieve the server’s private key.
In the Server Private Key Pass Phrase field, enter the keystore attribute that defines the passphrase used to retrieve the server’s private key.
Click Show Advanced Fields.
Turn off the Disable Hostname Verification option.
In the Export Key Lifespan field, indicate the number of times WebLogic Server can use an exportable key between a domestic server and an exportable client before generating a new key. The more secure you want WebLogic Server to be, the fewer times the key should be used before generating a new key.
For both the Inbound Certificate Validation and the Outbound Certificate Validation drop-down lists, select a validation method.
Enable two-way SSL/TLS.
By default, WebLogic Server is configured to use one-way SSL/TLS, where the server passes its identity to the client. In a two-way SSL/TLS connection, the client verifies the identity of the server and then passes its identity certificate to the server. The server then validates the identity certificate of the client before completing the SSL/TLS handshake. The server determines whether or not two-way SSL/TLS is used.
Before enabling two-way SSL/TLS, ensure that the trust keystore for the server includes the certificate for the trusted certificate authority that signed the certificate for the client. See Identity and Trust.
Turn on the Two Way SSL Enabled option.
Choose whether to enable the Client Certificate Enforced option. When enabled, a client is required to present a certificate. If a certificate is not presented, the SSL/TLS connection is terminated. When disabled, the SSL/TLS connection continues even if a certificate is not presented by the client.
You may also want to force all administration clients use two way SSL/TLS. If an administration client attempts to connect to a server on a channel that does not require two-way SSL/TLS, then the connection is rejected.
Under Environment, then Domain, click the Security tab and enable Show Advanced Fields.
Turn on the Require 2 way TLS for Admin Clients option.
Click Save.
Repeat on all applicable servers.
A host name verifier ensures the host name in the URL to which the client connects matches the host name in the digital certificate that the server sends back as part of the SSL/TLS connection. If the host name in the certificate matches the local machine’s host name, host name verification passes if the URL specifies localhost, 127.0.0.1, or the default IP address of the local machine.
A host name verifier is useful when a SSL/TLS client (or a WebLogic Server acting as an SSL/TLS client) connects to an application server on a remote host. Host name verification is performed only by a SSL/TLS client. By default, WebLogic Server has host name verification enabled and we recommend keeping it enabled for production environments.
The following steps only apply when a WebLogic Server instance is acting as an SSL/TLS client. Stand alone SSL/TLS clients specify the use of host name verification using command-line arguments or the API.
In the Edit Tree, go to Environment, then Servers, then myServer.
Click the Security tab, then SSL.
Click Show Advanced Fields.
Turn off Disable Hostname Verification.
Choose a hostname verifier from the Hostname Verifier drop-down list.
As of WebLogic Server 14.1.1.0.0, the default verifier is the wildcard verifier.
If you want to use a custom verifier, follow these steps.
If you write a custom host name verifier, the class that implements the host name verifier must be specified in the CLASSPATH of WebLogic Server (when acting as an SSL/TLS client) or a stand alone SSL/TLS client.
When you use stand alone SSL/TLS clients, a custom host name verifier must be specified on the command line using the following argument or through the API: -Dweblogic.security.SSL.HostnameVerifier=classname where classname specifies the implementation of the weblogic.security.SSL.HostnameVerifier interface.
Create a custom host name verifier as described in Using a Custom Hostname Verifier in Developing Applications with the WebLogic Security Service.
From the Hostname Verifier drop-down list, select Custom Verifier.
In the Custom Hostname Verifier field, enter the name of the implementation of the weblogic.security.SSL.HostnameVerifier interface.
Click Save.
All the server SSL/TLS attributes are dynamic. When modified using WebLogic Remote Console, they cause the corresponding SSL/TLS server or channel SSL/TLS server to restart and use the new settings for new connections. Old connections will continue to run with the old configuration.
All server SSL/TLS attributes are dynamic. You can modify these attributes and then apply your changes without rebooting WebLogic Server. Instead, only the corresponding SSL/TLS server or channel SSL/TLS server will restart and use the new settings for new connections. Existing connections continue to run with the old configuration.
If you haven’t done so already, turn on automatic realm restart in the default security realm. See Enable Automatic Realm Restart.
If automatic realm restart is not enabled, old connections will continue to run with the old configuration and you must restart WebLogic Server after restarting SSL/TLS to ensure that all the SSL/TLS connections exist according to the specified configuration.
In the Monitoring Tree, go to Environment, then Servers.
Select the checkbox for each server where you want to restart SSL/TLS.
Click Restart SSL to restart the SSL/TLS listen sockets to apply changes to your keystore.
Configure cipher suites supported by WebLogic Server.
In the Edit Tree, go to Environment, then Servers, then myServer.
Click the Security tab, then the SSL subtab.
Click Show Advanced Fields.
In the Cipher Suites field, enter the cipher suites that you want to support on this server.
In the Excluded Cipher Suites field, enter any cipher suites that you want to block on this server.
Click Save.
Repeat for other servers as necessary.
Cross domain security establishes trust between two WebLogic Server domains by using a credential mapper to configure communication between the WebLogic Server domains.
For more information, see Configuring Cross-Domain Security in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Environment, then Domain.
On the Security tab, turn on Cross Domain Security Enabled.
To reduce the impact on performance, WebLogic Server caches the authenticated subject. If you want to modify the cache settings for your environment, click Show Advanced Fields and change the following settings:
Click Save and then commit your changes.
Create a user for cross domain security and assign it to the CrossDomainConnectors group. See Create a User.
For more information on, see Configuring Cross-Domain Users in Administering Security for Oracle WebLogic Server.
Configure a cross-domain security credential mapping for the cross-domain security user.
For information on credential mapping, see Configure a Credential Mapping Provider.
In the Security Data Tree, go to Realms, then myRealm, then Credential Mappers, then myCredentialMapper, then Remote Resources.
Click New.
Turn on the Use cross-domain protocol option.
In the Remote Domain field, enter the name of the remote domain that needs to interact with the local domain.
In the Remote User field, enter the username of the user configured in the remote domain that is authorized to interact with the local domain.
In the Remote Password field, enter the password of the user configured in the remote domain that is authorized to interact with the local domain.
Click Create.
If you want multiple WebLogic Server domains to interoperate, you can specify the same domain credential for each of the domains. Typically, the domain credential is randomly generated by default and therefore, no two domains have the same domain credential.
When this feature is enabled, identity is passed between WebLogic Server domains over an RMI connection without requiring authentication in the second domain. When inter-domain trust is enabled, transactions can commit across domains. A trust relationship is established when the domain credential for one domain matches the domain credential for another domain. For more information, see Enabling Global Trust in Administering Security for Oracle WebLogic Server.
Instead of enabling global trust between domains, consider using the CrossDomainConnector role, as described in Enable Cross Domain Security.
In the Edit Tree, go to Environment, then Domain.
On the Security tab, click Show Advanced Fields.
In the Security Credential field, enter a new password for the domain. Choose a strong password.
Click Save.
Perform the same procedure in each domain for which you want to enable global trust, entering the exact same password.
Connection filters allow you to deny access at the network level. They can be used to protect server resources on individual servers, server clusters, or an entire internal network or intranet.
For more information on connection filters, see Using Connection Filters in Administering Security for Oracle WebLogic Server.
In the Edit Tree, go to Environment, then Domain.
On the Security tab, select the Filter subtab.
Turn on the Connection Logger Enabled option to enable the logging of accepted messages. The Connection Logger logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.
In the Connection Filter field, specify the connection filter class to be used in the domain.
weblogic.security.net.ConnectionFilterImpl.In the Connection Filter Rules field, enter the syntax for the connection filter rules.
For more information about connection filter rules, see Guidelines for Writing Connection Filter Rules in Developing Applications with the WebLogic Security Service.
If you want WebLogic Server to ignore errors in filter rules during server startup, turn on the Connection Filter Ignore Rule Errors option.
Click Save.
To improve security, WebLogic Server uses the JDK JEP 290 mechanism to filter incoming serialized Java objects and limit the classes that can be deserialized.
For more information, see Using JEP 290 in Oracle WebLogic Server in Administering Security for Oracle WebLogic Server.
When using the allowlist model, WebLogic Server and the customer define a list of the acceptable classes and packages that are allowed to be deserialized, and block all other classes.
WebLogic Server also supports using blocklists for JEP 290 filtering. For instructions on using blocklists, see How WebLogic Server Uses JEP 290 Blocklists and Allowlists in Administering Security for Oracle WebLogic Server.
Configure the domain to record all of the classes and packages used in both WebLogic Server and customer application deserialization.
In the Edit Tree, go to Environment, then Domain.
On the Security tab, select the Allow List subtab.
Turn on the Recording Enabled option.
When recording is enabled, all classes are allowed during deserialization except for the classes specified in the blocklist.
Save and commit the change.
Run a full set of tests to ensure that the recorded allowlist configuration file provides appropriate coverage of all packages and classes that must be allowed in order for your application to run successfully. When deserialization occurs, each class is recorded in DOMAIN_HOME/config/security/jep290-recorded.serial.properties.
A sample jep290-recorded.serial.properties is shown below:
Wed May 19 23:55:13 UTC 2021
weblogic.oif.serialFilter=\
com.company1.common.collections.objs.*;\
com.company1.common.tools.Calculator;\
com.company2.shared.tools.Converter
weblogic.oif.serialGlobalFilter=\
com.company1.common.lists.AList;\
com.company1.common.tools.Calculator;\
com.company2.shared.tools.*
Turn off the Recording Enabled option. Save and commit the change.
Configure the domain to use allowlists.
In the Edit Tree, go to Environment, then Domain. Click the Security tab, then the Allow List subtab. From the Violation Action drop-down list, select the appropriate setting.
IGNORE - Ignore the allowlist and use the blocklists. If any class found during deserialization is present in the blocklist, the class is blocked from being deserialized.
LOG - Log a message if a violation occurs but allow the class unless it is listed in the blocklist.
DENY - Block everything except the classes specified in the allowlist, and log a message when a class is blocked.
You can also set the AllowListViolationAction on a channel using the network access point. Doing so allows you to use an allowlist on untrusted external channels and a blocklist on internal trusted channels.
Click Save and commit your changes.
By default, the directory containing the allowlist configuration file is polled every 60 seconds. If you want to change the default polling interval, do the following:
In the Edit Tree, go to Environment, then Domain.
Click the Security tab, then the Allow List subtab.
In the Serial Profile Polling Interval field, enter the new interval.
Click Save.
Configure your production domain to use allowlists by copying the recorded allowlist configuration file that you just created to the DOMAIN_HOME/config/security directory of the production domain.
Oracle recommends that you run your production domain with AllowListViolationAction set to Log for some period of time to ensure that all classes and packages were recorded.
It’s important to maintain the accuracy of the allowlist configuration file. Whenever a new application is deployed to the domain, or a new version of the application is deployed, you should repeat this entire process, to recreate the allowlist or verify the allowlist with the new application to ensure that all packages and classes required by the new or updated application are included in the allowlist.
You can configure your WebLogic Server instance as either a Service Provider or Identity Provider.
For more information on using SAML 2.0 with WebLogic Server, see Configuring SAML 2.0 Services in Administering Security for Oracle WebLogic Server.
You cannot configure SAML 1.1 services using WebLogic Remote Console.
If you plan to have SAML 2.0 services running in more than one WebLogic Server instance in the domain, then create a domain in which the RDBMS security store is configured. See Use the RDBMS Security Store.
The RDBMS security store is required by SAML 2.0 security providers in production environments so that the data they manage can be synchronized across all of the WebLogic Server instances that share that data.
Oracle does not recommend upgrading an existing domain in place to use the RDBMS security store. If you want to use the RDBMS security store, then you should configure the RDBMS security store at the time of domain creation. If you have an existing domain with which you want to use the RDBMS security store, then create the new domain and migrate your existing security realm to it.
See Managing the RDBMS Security Store in Administering Security for Oracle WebLogic Server.
Review the considerations described in Web Application Deployment Considerations for SAML 2.0 in Administering Security for Oracle WebLogic Server.
Configure SAML 2.0 general services. Apply the same configuration settings to each server instance. See Configure SAML 2.0 General Services.
If you are configuring a SAML 2.0 Identity Provider site,
Create an instance of the SAML 2.0 Credential Mapping provider in the security realm. See Configure a Credential Mapping Provider.
Configure SAML 2.0 Identity Provider services. Apply the same configuration settings to each server instance. See Configure SAML 2.0 Identity Provider Services.
Publish the metadata file describing your site, and manually distribute it to your Service Provider partners. See Publish SAML Metadata.
Create and configure your Service Provider partners. See Create a SAML 2.0 Web Service Service Provider Partner or Create a SAML 2.0 Web Single Sign-On Service Provider Partner.
If you are configuring a SAML 2.0 Service Provider site,
Create an instance of the SAML 2.0 Identity Assertion provider in the security realm. See Configure an Authentication or Identity Assertion Provider
If you are allowing virtual users to log in using SAML, create an instance of the SAML Authentication provider. See Configuring the SAML Authentication Provider in Administering Security for Oracle WebLogic Server.
Configure SAML 2.0 Service Provider services. Apply the same configuration settings to each server instance. See Configure SAML 2.0 Service Provider Services
Publish the metadata file describing your site, and manually distribute it to your Identity Provider partners. See Publish SAML Metadata
Create and configure your Identity Provider partners. See Create a SAML 2.0 Web Service Identity Provider Partner or Create a SAML 2.0 Web Single Sign-On Identity Provider Partner.
Whether you configure a WebLogic Server instance as a SAML 2.0 Identity Provider or as a SAML 2.0 Service Provider, you must configure the server’s general SAML 2.0 services.
For more information, see Configuring SAML 2.0 General Services in Administering Security for Oracle WebLogic Server.
Review the general steps for configuring SAML 2.0 services as described in Configure SAML 2.0 Services: Main Steps.
In the Edit Tree, go to Environment, then Servers.
Select the server instance where you want to configure SAML general services.
Click the Security tab, then the SAML 2.0 General subtab.
Turn on the Replicated Cache option to use the persistent cache for storing SAML 2.0 artifacts.
This option is required if you are configuring SAML 2.0 services in two or more WebLogic Server instances in your domain. If you are configuring SAML 2.0 services in a cluster, you must enable this option in each Managed Server instance individually.
Modify the settings as necessary for your environment. For descriptions of the fields and when you might want to configure them, see About SAML 2.0 General Services in Administering Security for Oracle WebLogic Server.
Click Save.
Repeat for the rest of the servers in domain. Make sure you apply the exact same configuration settings to all servers.
Publish the metadata file. See Publish SAML Metadata.
Next, configure the server as an Identity Provider or as a Service Provider. See Configure SAML 2.0 Identity Provider Services or Configure SAML 2.0 Service Provider Services, respectively.
The SAML metadata file contains the information about this site’s SAML 2.0 services. Share this file with your federated partners to facilitate SAML 2.0 web single sign-on.
In the Monitoring Tree, go to Environment, then Servers, then myServer.
On the SAML 2.0 tab, click Publish Metadata.
In the Publish Metadata dialog box, specify a file path location to save the metadata file. The file path must be relative to the Administration Server.
Click Done.
Distribute the metadata file to your federated partners. For distribution recommendations, see Publishing and Distributing the Metadata File in Administering Security for Oracle WebLogic Server.
A SAML 2.0 Identity Provider creates, maintains, and manages identity information for principals, and provides principal authentication to other Service Provider partners within a federation by generating SAML 2.0 assertions for those partners.
Perform the SAML 2.0 general services configuration as described in Configure SAML 2.0 General Services.
Configure a SAML 2.0 Credential Mapping provider if you haven’t done so already. See Configure a Credential Mapping Provider.
In the Edit Tree, go to Environment, then Servers.
Select the server instance where you want to perform SAML configuration for servers in the role of Identity Provider.
Click the Security tab, then the SAML 2.0 Identity Provider subtab.
Turn on the Enabled option to activate this server’s SAML 2.0 services in the role of Identity Provider.
Modify the settings as necessary for your environment. For descriptions of the attributes and when you might want to configure them, see Configure SAML 2.0 Identity Provider Services in Administering Security for Oracle WebLogic Server.
Click Save.
Repeat for the rest of the servers. Make sure you apply the same configuration settings to all servers.
Create and configure your Service Provider partners. See Create a SAML 2.0 Web Single Sign-On Service Provider Partner or Create a SAML 2.0 Web Service Service Provider Partner.
Coordinate with your federated partners to ensure that the SAML bindings you have enabled for this SAML authority, as well as your requirements for signed documents, are compatible with your partners.
A SAML 2.0 Service Provider partner is an entity that consumes the SAML 2.0 assertions generated by the Identity Provider site.
Obtain, using a trusted and secure mechanism, the metadata file from your federated partner that describes the partner, the binding support, certificates and keys, and so on. See Obtain Your Service Provider Partner’s Metadata File in Administering Security for Oracle WebLogic Server.
In the Security Data Tree, go to Realms, then myRealm, then Credential Mappers and select the SAML 2.0 credential mapping provider that you configured for the server.
Click the Partners node.
Click New.
Enter a name for the Service Provider partner.
From the Type drop-down list, select Web Service Service Partner.
Click Create.
Turn on the Enabled option to enable interactions between this server and this Service Provider partner.
Modify the settings as necessary for your environment. For descriptions of the settings and when you might want to configure them, see Create and Configure Web Single Sign-On Service Provider Partners in Administering Security for Oracle WebLogic Server.
Click Save.
A SAML 2.0 Service Provider partner is an entity that consumes the SAML 2.0 assertions generated by the Identity Provider site.
Obtain, using a trusted and secure mechanism, the metadata file from your federated partner that describes the partner, the binding support, certificates and keys, and so on. See Obtain Your Service Provider Partner’s Metadata File in Administering Security for Oracle WebLogic Server.
In the Security Data Tree, go to Realms, then myRealm, then Credential Mappers and select the SAML 2.0 credential mapping provider that you configured for the server.
Click the Partners node.
Click New.
Enter a name for the Service Provider partner.
From the Type drop-down list, select Web Single Sign-On Service Partner.
In the Meta Data File Name field, enter the file path to the metadata partner file you received from your federated partner.
Click Create.
Turn on the Enabled option to enable interactions between this server and this Service Provider partner.
Modify the settings as necessary for your environment. For descriptions of the settings and when you might want to configure them, see Create and Configure Web Single Sign-On Service Provider Partners in Administering Security for Oracle WebLogic Server.
Click Save.
A Service Provider is a SAML authority that can receive SAML assertions and extract identity information from those assertions. The identity information can then be mapped to local Subjects, and optionally groups as well, that can be authenticated.
Perform the SAML 2.0 general services configuration as described in Configure SAML 2.0 General Services.
If you haven’t done so already, configure a SAML 2.0 Identity Assertion provider . See Configure an Authentication or Identity Assertion Provider.
In the Edit Tree, go to Environment, then Servers.
Select the server instance where you want to perform SAML configuration.
Click the Security tab, then the SAML 2.0 Service Provider subtab.
Turn on the Enabled option to activate this server’s SAML 2.0 services in the role of Service Provider.
Modify the settings as necessary for your environment. For descriptions of the attributes and when you might want to configure them, see Configure SAML 2.0 Service Provider Services in Administering Security for Oracle WebLogic Server.
Click Save.
Repeat for the rest of the servers. Make sure you apply the same configuration settings to all servers.
Create and configure your Identity Provider partners. See Create a SAML 2.0 Web Single Sign-On Identity Provider Partner or Create a SAML 2.0 Web Service Identity Provider Partner.
A SAML 2.0 Identity Provider partner is an entity that generates SAML 2.0 assertions consumed by the Service Provider site.
Obtain, using a trusted and secure mechanism, the metadata file from your federated partner that describes the partner, the binding support, certificates and keys, and so on. See Obtain Your Identity Provider Partner’s Metadata File in Administering Security for Oracle WebLogic Server.
In the Security Data Tree, go to Realms, then myRealm, then Authentication Providers and select the SAML 2.0 Identity Assertion provider that you configured.
Click Partners node.
Click New.
Enter a name for the Identity provider partner.
From the Type drop-down list, select Web Service Identity Partner.
Click Create.
Turn on the Enabled option to enable interactions between this server and this Identity Provider partner.
Modify the settings as necessary for your environment. For descriptions of the settings and when you might want to configure them, see Create and Configure Web Single Sign-On Identity Provider Partners in Administering Security for Oracle WebLogic Server.
Click Save.
Click the Assertion Signing Certificate tab to configure the Identity Provider partner’s assertion signing certificate.
Coordinate with your partner to obtain the Assertion Signing Certificate in a secure manner. For more information, see Using Security Assertion Markup Language (SAML) Tokens For Identity in Securing WebLogic Web Services for Oracle WebLogic Server.
Click Import Certificate from File and enter the file path to the .pem or .der file containing the X.509 certificate.
Click Done.
WebLogic Remote Console will populate the page with information pulled from the imported certificate.
A SAML 2.0 Identity Provider partner is an entity that generates SAML 2.0 assertions consumed by the Service Provider site.
Obtain, using a trusted and secure mechanism, the metadata file from your federated partner that describes the partner, the binding support, certificates and keys, and so on. See Obtain Your Identity Provider Partner’s Metadata File in Administering Security for Oracle WebLogic Server.
In the Security Data Tree, go to Realms, then myRealm, then Authentication Providers and select the SAML 2.0 Identity Assertion provider that you configured for the server.
Click the Partners node.
Click New.
Enter a name for the Identity Provider partner.
From the Type drop-down list, select Web Single Sign-On Identity Partner.
In the Meta Data File Name field, enter the file path to the metadata partner file you received from your federated partner.
Click Create.
Modify the settings as necessary for your environment. For descriptions of the settings and when you might want to configure them, see Create and Configure Web Single Sign-On Identity Provider Partners in Administering Security for Oracle WebLogic Server.
Click Save.
You can use an external RDBMS as a data store for the authorization, role mapping, credential mapping, and certificate registry providers. This data store, called the RDBMS security store, is strongly recommended when using SAML 2.0 services in two or more WebLogic Server instances in a domain.
If you plan to use the RDBMS security store, you should set it up when you first create the domain. If you have an existing domain, then you should create a new domain, configure it for RDBMS, and then migrate security data from the existing domain over to the new domain. We do not recommend trying to enable the RDBMS security store on an existing domain.
For information on using the RDBMS security store in WebLogic Server, see Managing the RDBMS Security Store in Administering Security for Oracle WebLogic Server.
For a list of security providers affected by the RDBMS, see Security Providers that Use the RDBMS Security Store in Administering Security for Oracle WebLogic Server.
For a list of the specific RDBMS systems supported in this release of WebLogic Server for use as an RDBMS security store, see Oracle Fusion Middleware Supported System Configurations.
Create a new WebLogic domain using either the Domain Configuration wizard or WLST Offline. See Creating a WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard or Creating WebLogic Domains Using WLST Offline in Understanding the WebLogic Scripting Tool, respectively.
Do not start the domain at this time.
Enable the RDBMS security store using WLST Offline. See Use WLST Offline to Create the RDBMS Security Store in Administering Security for Oracle WebLogic Server.
Create the RDBMS tables in your data store. The WebLogic Server installation directory includes a set of scripts for each supported RDBMS system.
Typically this step is performed by the database administrator. See Create RDBMS Tables in the Security Datastore in Administering Security for Oracle WebLogic Server for a description of the scripts, their locations in the product installation directory, and instructions for running them.
Start the domain.
You can update the RDBMS security store settings. However, you should avoid modifying the database settings of the RDBMS security store after it has been created.
In the Edit Tree, go to Security, then Realms, then myRealm, then RDBMS Security Store.
Click New.
Enter values for the Name, Connection URL, Driver Name, and Username fields.
The database name, type, and user credentials must match the values you set when you created the domain.
Click Create.
Specify the appropriate settings for JNDI and JMS so that the RDBMS security store can cache database information in memory correctly. If the RDBMS is running in more than one JVM, for example, the domain has multiple servers, or other Oracle products are sharing the same RDBMS store with the new domain, these caches must be synchronized to ensure the integrity of the security data. To configure server synchronization:
Specify a JNDI user name and password. This can be any valid user in the security realm who has access to JNDI.
Create a JMS topic. You can reuse an existing one. See Configure Resources for JMS System Modules.
Failure to configure JMS actions in a multiserver domain in which the RDBMS security store is configured may result in a security vulnerability.
Click Save.
If the JMS topic with which the RDBMS security store is configured goes down, see Managing the RDBMS Security Store in Administering Security for Oracle WebLogic Server for important information about restoring it.