4 Customizing the Default Security Configuration
Oracle WebLogic Server provides a default security configuration that can be customized if you want to replace the default security settings in order to simplify the management of security.
This chapter includes the following sections:
For information about configuring security providers, see About Configuring WebLogic Security Providers and About Configuring the Authentication Providers in WebLogic Server.
For information about migrating security data to a new security realm, see Migrating Security Data.
Why Customize the 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 (also known as the DefaultAuthenticator).
-
When performing authentication, use the GUID or DN attributes of principals, in addition to user names, specify that principal matching is case-insensitive.
-
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.
-
Use a custom Authorization or Role Mapping provider that does not support parallel security policy and role modification, respectively, in the security provider database.
For information about configuring different types of security providers in a security realm, see About Configuring WebLogic Security Providers and About Configuring the Authentication Providers in WebLogic Server.
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 you create a security realm, determine the set of the security providers you want to use, as well as the model for establishing security policies.
Note the following:
-
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.
In addition, custom Authorization and Role Mapping providers may or may not support parallel security policy and role modification, respectively, in the security provider database. If your custom Authorization and Role Mapping security providers do not support parallel modification, the WebLogic Security framework can enforce a synchronization mechanism that results in each application and module being placed in a queue and deployed sequentially. To do this, set the Deployable Provider Synchronization Enabled and Deployable Provider Synchronization Timeout controls for the realm.
-
The security roles and policies for Web application and EJB resources can be set through deployment descriptors or through the WebLogic Server Administration Console. See Options for Securing Web Application and EJB Resources in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
-
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 that the Web resource is deprecated in this release of WebLogic Server.
Note:
When you create a new security realm, you must configure at least one of the Authentication providers to return asserted LoginModules. Otherwise,
run-astags defined in deployment descriptors will not work.
See Configure new security realms in the Oracle WebLogic Server Administration Console Online Help.
Creating and Configuring a New Security Realm: Main Steps
The main steps to configure a new security realm include choosing a realm name, selecting and configuring the set of required security providers, creating the appropriate security policies for protecting the WebLogic resources in the realm, and protecting the users accounts that are defined in the realm.
To create a new security realm:
Using Automatic Realm Restart
The Impact of Dynamic and Non-Dynamic Configuration Changes on Realm Restart
The type of configuration change you make determines how realm restart impacts that change. The following three scenarios demonstrate the type of changes you can make to the realm, to a security provider, or another WebLogic configuration, and how automatic realm restart affects those changes:
-
Dynamic Changes: Some changes that you make in the Administration Console take effect immediately when you activate them in the Change Center of the WebLogic Server Administration Console. Such changes, called dynamic changes, do not require a server restart or a realm restart.
-
Nondynamic changes to realm or provider that do not require a server restart: If you make changes to the nondynamic attributes of the realm or security provider, and if automatic realm restart has been enabled for that realm, then realm is restarted during the commit of the Activate Changes process in the Change Center of the WebLogic Server Administration Console. Therefore, a server restart is not required. If automatic realm restart is not enabled for a realm, then a server restart is required for nondynamic changes to that realm or provider.
-
Nondynamic changes to realm or provider and to other WebLogic Server configuration: When nondynamic configuration changes are made to both the security realm and to other (that is, non-security related) WebLogic domain attributes that do require a server restart, the realm is not restarted even if automatic restart is configured and enabled for that realm. In such cases, a server restart is required.
Configuration Options for Realm Restart
A realm restart implies that WebLogic Server initializes a new realm instance with the configuration changes that you made to the previous realm instance. As a result, the old (previous) realm instance is shut down. When the new instance is initialized, the realm object references from the previous instance are migrated to the new instance. However, operations on the old realm instance may still be in progress at the time the new instance is ready. The retire timeout allows in-progress operations to complete without being interrupted while the old instance remains running for the specified timeout period. Use the RetireTimeoutSeconds attribute of the RealmMBean to specify the time (in seconds) that you require before the old realm instance shuts down or retires. The minimum value for this attribute is 1 second, whereas the default value is 1 minute (60 seconds). To change the value for this attribute using the WebLogic Server Administration Console, select the Configuration > General tab page for your security realm. On the General page, set the value (in seconds) for the Retire Timeout attribute.
The default security realm setting provides compatibility with previous WebLogic behavior because a custom security provider may not be able to support realm restart. Therefore, in the default security realm, automatic realm restart is disabled by default. However, in the new security realms that you create, automatic realm restart is enabled by default. You can use the AutoRestartOnNonDynamicChanges attribute of the Realm MBean to enable or disable automatic restart of the realm if nondynamic changes are made to the realm or providers within the realm. To set this attribute using the Administration Console, see Enable automatic realm restart in Oracle WebLogic Server Administration Console Online Help.
For more information about RealmMBean attributes, see RealmMBean in MBean Reference for Oracle WebLogic Server.