For information about migrating security data to a new security realm, see Migrating Security Data.
Why Customize the Default Security Configuration?
To simplify the configuration and management of security, WebLogic Server provides a default security configuration. In the default security configuration, myrealm is set as the default (active) security realm, and the WebLogic Adjudication, Authentication, Identity Assertion, Credential Mapping, CertPath, XACML Authorization and XACML Role Mapping providers are defined as the security providers in the security realm.
Customize the default security configuration if you want to do any of the following:
Replace one of the security providers in the default realm with a different security provider.
Configure additional security providers in the default security realm. (For example, if you want to use two Authentication providers, one that uses the embedded LDAP server and one that uses a Windows NT store of users and groups.)
Use an Authentication provider that accesses an LDAP server other than WebLogic Server’s embedded LDAP server.
Use an existing store of users and groups (for example, a DBMS database) instead of defining users and groups in the WebLogic Authentication provider.
Add an Auditing provider to the default security realm.
Use an Identity Assertion provider that handles SAML assertions or Kerberos tokens.
Use the Certificate Registry to add certificate revocation to the security realm.
Change the default configuration settings of the security providers.
The easiest way to customize the default security configuration is to add the security providers you want to the default security realm (myrealm). However, Oracle recommends instead that you customize the default security configuration by creating an entirely new security realm. This preserves your ability to revert more easily to the default security configuration. You configure security providers for the new realm; migrate any security data, such as users as groups, from the existing default realm; and then set the new security realm as the default realm. See Creating and Configuring a New Security Realm: Main Steps.
Before You Create a New Security Realm
Before creating a new security realm, you need to decide:
Which security providers you want to use. WebLogic Server includes a wide variety of security providers and, in addition, allows you to create or obtain custom security providers. A valid security realm requires an Authentication provider, an Authorization provider, an Adjudication provider, a Credential Mapping provider, a Role Mapping provider, and a CertPathBuilder. In addition, a security realm can optionally include Identity Assertion, Auditing, and Certificate Registry providers. If your new security realm includes two or more providers of the same type (for example, more than one Authentication provider or more than one Authorization provider), you need to determine how these providers should interact with each other. See Using More Than One Authentication Provider.
What model to use to set security roles and security policies for Web application and EJB resources. These security roles and policies can be set through deployment descriptors or through the WebLogic Administration Console. See see Options for Securing Web Application and EJB Resources in Securing WebLogic Resources Using Roles and Policies.
Whether or not to use the Web resource.
The Web resource is deprecated. If you are configuring a custom Authorization provider that uses the Web resource (instead of the URL resource) in the new security realm, enable Use Deprecated Web Resource on the new security realm. This option changes the runtime behavior of the Servlet container to use a Web resource rather than a URL resource when performing authorization.
Note:
When you create a new security realm, you must configure at least one of the Authentication providers to return asserted LoginModules. Otherwise, run-as tags defined in deployment descriptors will not work.
Configure the required security providers for the security realm. A valid security realm requires an Authentication provider, an Authorization provider, an Adjudication provider, a Credential Mapping provider, a Role Mapping provider, and a CertPathBuilder. See Configuring WebLogic Security Providers and Configuring Authentication Providers.
If you configured the WebLogic Authentication, Authorization, Credential Mapping or Role Mapping provider or the Certificate Registry in the new security realm, verify that the settings of the embedded LDAP server are appropriate. See Managing the Embedded LDAP Server..
Protect WebLogic resources in the new security realm with security policies. Creating security policies is a multi-step process with many options. To fully understand this process, read Securing WebLogic Resources Using Roles and Policies. This document should be used in conjunction with Securing WebLogic Server to ensure security is completely configured for a WebLogic Server deployment.
If the security data (users and groups, roles and policies, and credential maps) defined in the existing security realm will also be valid in the new security realm, you can export the security data from the existing realm and import it into the new security realm. See Migrating Security Data.
Protect user accounts in the new security realm from dictionary attacks by setting lockout attributes. See Protecting User Accounts.
Set the new realm as the default security realm for the WebLogic domain. See Change the default security realm in the Administration Console Online Help.
Note:
You can also use the WebLogic Scripting Tool or Java Management Extensions (JMX) APIs to create a new security configuration. See WebLogic Scripting Tool.
