WebLogic Server uses a mechanism to provide a secure environment, as follows:
A security realm is a mechanism for protecting Oracle WebLogic Server resources, such as Authenticators, Adjudicators, Authorizers, Auditors, Role mappers, and Credential mappers. Resources in a domain are protected only under one security realm and by a single security policy in that security realm. A user must be defined in a security realm in order to access any resources belonging to that realm. When a user attempts to access a particular resource, WebLogic Server tries to authenticate the user and then authorize the user action by checking the access privileges that are assigned to the user in the relevant realm.
In the previous screenshot you can see the different components belonging to a security realm.
Users are entities that use WebLogic Server, such as:
- Application end users
- Client applications
- Other Oracle WebLogic Servers
A person can be defined as both an individual user and a group member. Individual-access permissions override any group member-access permissions. Oracle WebLogic Server evaluates each user by first looking for a group and testing whether the user is a member of the group and then looking for the user in the list of defined users.
- Logical sets of users
- More efficient for managing a large number of users
Groups can contain users or even other groups. This makes it easier to manage their security by giving permissions to a group instead of a single user.
By clicking on the Security Realm (myrealm is the WebLogic default) you can manage users and groups:
Users and Groups can both have one or many Group Memberships. WebLogic ships with a number of explicitly predefined groups like Administrators, Deployers, Operators, and Monitors.
WLS also has two implicitly predefined groups:
- everyone - authenticated and unauthenticated (something such as public)
- users - anyone who is authenticated or anyone with a known identity
A security role is a permission granted to users or groups based on several conditions. Just as for groups, security roles allow you to restrict access to WebLogic resources for several users simultaneously.
Security roles are assigned and granted to users or groups dynamically, based on conditions such as username, group membership, or the time of day, and can be scoped to specific WebLogic resources within an application in a WebLogic Server domain. Granting a security role to a user or a group confers the defined access privileges to that user or group as long as the user or group has the security role assigned. Multiple users or groups can be granted a single security role. A role definition is specific to a security realm.
WebLogic Server defines a set of default global roles for protecting all the WebLogic resources in a domain. A scoped role protects a specific resource, such as a method of an EJB or a branch of the JNDI tree. Most roles are scoped.
By default no security role is enforced and therefore all the resources can be accessed by any user.
- Admin can display and modify all resource attributes and perform start and stop operations. By default, users in the Administrators group are granted the Admin role.
- Operator can display all resource attributes. Users can start, suspend, resume, and stop resources. By default, users in the Operators group are granted the Operator role.
- Monitor can display all resource attributes. Users can modify the resource attributes and operations that are not restricted to the other roles. By default, users in the Monitors group are granted this role.
- Deployer can display all resource attributes. Users can deploy applications, EJBs, and other deployable modules. By default, users in the Deployers group are granted the Deployer role.
- AppTester can test the versions of applications that are deployed to the Admin mode.
- Anonymous: All users are granted this role.
These defaults are stored in an embedded LDAP directory, that is, the default to use for authentication.
It is a full LDAP implementation, production quality, and suitable for up to 10k users. Even when an external LDAP is used for production, development and test could work with this embedded LDAP. The embedded LDAP is file-based all data is stored in LDIF files stored in the domain.
JEE already provides a standard model for securing Web applications and EJBs. In this standard model, you define role mappings and policies in the Web application or EJB deployment descriptors. But sometimes this JEE standard can be too inflexible for some environments, and in this case Oracle WebLogic Server has more flexible models to support the JEE standard.
Applications define security roles in their descriptor files:
- Web Application:
web.xml - Enterprise Java Bean application:
ejb-jar.xml - Enterprise Application:
application.xml
These can be inspected in the Admin Console; depending on application deployment, they may be editable.
WebLogic Server provides security policies and roles that are used together to control access to or protect resources. The security realm that WebLogic Server provides, stores policies in the embedded LDAP server.
You can create a root-level policy that applies to all instances of a specific resource type. Also, you can create a policy that applies to a specific resource instance. If the instance contains other resources, the included resource will inherit the policy as well. For example, you can create a policy for an entire EAR, an EJB JAR containing multiple EJBs, a particular EJB within that JAR, or a single method within that EJB.
Each policy has one or more conditions in it:
- Basic: This can be used to allow or deny access to everyone or specific users, groups, or roles.
- Date and Time: When you use any of the date and time conditions, the security policy grants access to all users for the date or time you specify.
- Context Element: You can use the context element conditions to create security policies based on the value of HTTP Servlet Request attributes, HTTP Session attributes, and EJB method parameters.
Authentication Providers are used to derive "Enterprise Identity" using login credentials, certificate or custom headers, using some form of LDAP, or other identity store. They can be configured in the Admin Console. There can be more than one active authentication provider.
The Control Flag governs whether authentication from a provider is required. If multiple providers are present, then at least one of them must be set to REQUIRED. You can mess up your domain resulting in not being able to start your server anymore (if you use two Authentication Providers, define the WebLogic user in both of them and set one to REQUIRED resulting in not being able to access the domain anymore). In fact, you should always set the DefaultAuthenticator to REQUIRED.
Providers can be created in the Security Realm under the Providers tab.
WebLogic Server also provides some third-party providers:
- LDAP Authentication providers for external LDAP
- Stores Open LDAP, Microsoft Active Directory, Oracle Internet Directory, and Novell NDS
- DBMS authentication providers
- Access security data in custom database schema
- Windows NT Authentication provider
- LDAP X509 Identity Assertion provider
- SAML Authentication/Identity Assertion
- Custom Authentication provider
- For example, to work with third-party IDMs
The following screenshot shows the list of third-party providers:
A credential map is a mapping of credentials used by Oracle WebLogic Server for credentials that are used in a legacy (or a remote) system to connect to a given resource in that system. Credential maps allow your Oracle WebLogic Server to log in to a remote system on behalf of a subject that has already been authenticated.
A credential mapping provider of WLS can handle different types of credentials, such as username/password, and public key certificates. Credential mappings can be set in deployment descriptors of applications or through the Administration Console.
There can be multiple credential mapping providers configured in a security realm.