WebLogic Security Realm

Securing WebLogic Server 12c

,
November 2012

$19.99

Learn to develop, administer and troubleshoot for WebLogic Server with this book and ebook.

(For more resources related to this topic, see here.)

Configuration of local LDAP server: user/roles/lockout

The simplest way to configure your security realm is through the WebLogic Administration Console; you can find all about security in the section, on the main tree, Security Realms, where the default configuration called myrealm is placed.

Under Security Realms, we have a preconfigured subset of Users, Groups, Authentication methods, Role Mapping, Credential Mapping providers, and some other security settings.

You can configure many realms' security sets, but only one will be active.

On the myrealm section, we find all security parameters of the internal LDAP server configurations, including users and groups.

Consider this; Oracle declares that the embedded WebLogic LDAP server works well with less than 10,000 users; for more users, consider using a different LDAP server and Authentication Provider, for example, an Active Directory Server.

Users and groups

Obviously, here you can and configure some internal users and some internal groups. A user is an entity that can be authenticated and used to protect our application resources. A group is an aggregation of users who usually have something in common, such as a subset of permissions and authorizations.

Users section

The console path for the Users section is as follows:

Click on Security Realms | myrealm | Users and Groups | Users.

In this section, by default you will find your administrator account, used to log in to the WebLogic Administration Console and configured on the wizard during the installation phase; you can also create some other users (note: the names are case insensitive insert ) and set the following settings:

  • User Description: An internal string description tag

  • User Password: User password subjected to some rules

  • View User Attributes: Some user attributes

  • Associate groups: Predefined in the Groups section

Please be attentive to preserve the integrity of the administrative user created in the installation configuration wizard; this user is vital for the WebLogic Server (startup process); don't remove this user if you don't have some advanced knowledge of what you are doing and how to roll back changes

Take care also to change the admin user's password after installation phase; if you use the automatic startup process without providing a user and password (required when needed to start the admin console in the OS as a service, without prompting any interactive request) you will need to reconfigure the credentials file to start up the admin server at boot. The following file needs to be changed:

$DOMAIN_HOME\servers\Adminserver\security\boot.properties username=weblogic password=weblogicpassword

After the first boot, the WebLogic admin server will encrypt this file with its internal encryption method.

Groups section

The console path for the Groups section is as follows:

Security Realms | myrealm | Users and Groups | Groups

In this section, by default, you will find some groups used to profile user grants (only the Administrators' and Oracle System's group was populated) whose names are case insensitive. Define new groups before creating a user to associate with them.

The most important groups are as follows:

  • Administrators : This is the most powerful group, which can do everything in the WebLogic environment. Do not add plenty of people to it, otherwise you will have too many users with the power to modify your server configuration.

  • Deployers: This group can manage applications and resources (for example, JDBC, web services) and is very appropriate for the operations team that needs to deploy and update different versions of applications often during the day.

  • Monitors: This group provides a read-only access to WebLogic and is convenient for monitoring WebLogic resources and status

  • Operators: This group provides the grant privilege to stop, start, and resume WebLogic nodes.

All users without an associated group are recognized to an Anonymous role. In this case the implicit group (not present in the list) will be the everyone group.

Security role condition

The console path for Roles and Policies are as follows:

  • Go to Security Realms | myrealm | Users and Groups | Realm Roles | Realm Policies | Roles

  • Go to Security Realms | myrealm | Users and Groups | Realm Roles | Realm Policies | Policies

In WebLogic, you can configure some advanced collection of rules to trust or deny the access over role security configuration dynamically; all conditions need to be true if you want to grant a security role.

There are some available conditions in WebLogic role mapping, which we will now explore in the next section.

Basic

The available options are as follows:

  • User: This option adds the user to a specific role if his username matches the specified string

  • Group: This option adds the specified group to the role in the same way as the previous rule

  • Server is in development mode: This option adds the user or group in a role if the server is started in the development mode

  • Allow access to everyone: This option adds all users and groups to the role

  • Deny access to everyone: This option rejects all users from being in the role

Date and time-based

When used, this role condition can configure a rule based on a date or on a time basis (between, after, before, and specified) to grant a role assignment.

Context element

The server retrieves information from the ContextHandler object and allows you to define role conditions based on the values of HTTP servlet request attributes, HTTP session attributes, and EJB method parameters.

User lockout

The console path for User Lockout is Security Realms | myrealm | User Lockout.

User Lockout is enabled by default; this process prevents user intrusion and dictionary attacks. It also improves the server security and can configure some policies to lock our local configured users. This option is globally applied to any configured security provider.

In this section, you can define the maximum number of consecutive invalid login attempts that can occur before a user's account is locked out and how long the lock lasts. After that period, the account is automatically re-enabled.

If you are using an Authentication Provider that has its own mechanism for protecting user accounts, disable the Lockout Enabled option.

When a user is locked, you can find a message similar to the following message in the server logs:

<Apr 6, 2012 11:10:00 AM CEST> <Notice> <Security> <BEA-090078>
<User Test in security realm myrealm has had 5 invalid login attempts, locking account for 30 minutes.>

Unlocking user

The result of lock settings are a blocked user; if you need to unlock him immediately, you have to go to the section named Domain, created in the wizard installation phase in the left pane under the Security section. Here, you can view the Unlock User tab, where you can specify that the username be re-enabled. Remember to click on the Lock & Edit button before you do any changes.

When you manually unlock a user, you can find a message similar to the following message in the server logs:

... .<1333703687507> <BEA-090022> <Explicitly unlocked, user Test.>

Summary

By using this recipe, we have focused on the key steps to follow application resources in a fast and easy way.

Resources for Article :


Further resources on this subject:


Books to Consider

comments powered by Disqus