Security Realms

A security realm comprises mechanisms for protecting WebLogic 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. When a user attempts to access a particular WebLogic resource, WebLogic Server tries to authenticate and authorize the user by checking the security role assigned to the user in the relevant security realm and the security policy of the particular WebLogic resource.

Users:

      Users are entities that can be authenticated in a security realm, such as myrealm . A user can be a person, such as application end user, or a software entity, such as a client application, or other instances of 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 be directly associated with security roles.

Groups:

       Groups are logically ordered sets of users. Usually, group members have something in common. For example, a company may separate its sales staff into two groups, Sales Representatives and Sales Managers. Companies may do this because they want their sales personnel to 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. For example, an administrator can specify permissions for 50 users at one time by placing the users in a group, assigning the group to a security role, and then associating the security role with a WebLogic resource via a security policy.

All user names and groups must be unique within a security realm.

Security Roles:

       A dynamically computed privilege that is granted to users or groups based on specific conditions. The difference between groups and roles is that a group is a static identity that a server administrator assigns, while membership in a role is dynamically calculated based on data such as user name, group membership, or the time of day. Security roles are granted to individual users or to groups, and multiple roles can be used to create security policies for a WebLogic resource.

Security Policies:

        A security policy is an association between a WebLogic resource and one or more users, groups, or security roles. Security policies protect the WebLogic resource against unauthorized access. A WebLogic resource has no protection until you create a security policy for it. A policy condition is a condition under which a security policy will be created. WebLogic Server provides a set of default policy conditions. WebLogic Server includes policy conditions that access the HTTP Servlet Request and Session attributes and EJB method parameters. Date and Time policy conditions are included in the Policy Editor.

Security providers

        Security providers are modules that provide security services to applications to protect WebLogic resources. You can use the security providers that are provided as part of the WebLogic Server product, purchase custom security providers from third-party security vendors, or develop your own custom security providers.

 Security Provider database:

         A security provider database contains the users, groups, security roles, security policies, and credentials used by some types of security providers to provide security services.

Embedded LDAP Server:  

        WebLogic Server uses its embedded LDAP server as the database that stores user, group, security roles, and security policies for the WebLogic security providers. The embedded LDAP server is a complete LDAP server that is production quality for reasonably small environments (10,000 or fewer users). For applications that need to scale above this recommendation, the embedded LDAP server can serve as an excellent development, integration and testing environment for future export to an external LDAP server for production deployment. The embedded LDAP server supports the following access and storage functions:

• Access and modification of entries in the LDAP server
• Use of an LDAP browser to import and export security data into and from the LDAP server.
• Read and write access by the WebLogic security providers.

WebLogic Security Provider	Embedded LDAP Server Usage
Authentication	Stores user and group information.
Identity Assertion	Stores user and group information.
Authorization	Stores security roles and security policies.
Adjudication	None.
Role Mapping	Supports dynamic role associations by obtaining a computed set of roles granted to a requestor for a given WebLogic resource.
Auditing	None.
Credential Mapping	Stores Username-Password credential mapping information.
Certificate Registry	Stores registered end certificates.

 RDBMS Security Store:

     WebLogic Server provides the option of using an external RDBMS as a datastore that is used by the following security providers:

• XACML Authorization and Role Mapping providers
• WebLogic Credential Mapping provider
• PKI Credential Mapping provider
• The following providers for SAML 1.1:

                SAML Identity Assertion provider V2
                SAML Credential Mapping provider V2

• The following providers for SAML 2.0:

                SAML 2.0 Identity Assertion provider
                SAML 2.0 Credential Mapping provider

• Default Certificate Registry

When the RDBMS security store is configured in a security realm, an instance of any of the preceding security providers that has been created in the security realm automatically uses only the RDBMS security store as a datastore, and not the embedded LDAP server. Other security providers continue to use their default stores; for example, the WebLogic Authentication provider continues to use the embedded LDAP server.
Oracle recommends that you configure the RDBMS security store at the time of domain creation. The Configuration Wizard has been enhanced to simplify the process. This ensures that when the domain is booted, the security policies required to access the domain can be retrieved from the external RDBMS.
Note that the use of the RDBMS security store is required to use SAML 2.0 services in two or more WebLogic Server instances in a domain, such as in a cluster.