Authentication asks the question "Who are you?" using credentials such as username/password combinations to determine whether the caller is acting on behalf of specific users or system processes. In WebLogic Server, authentication providers prove the identity of users or system processes and transport and make identity information available to the components of a system (via subjects) when needed.
Authorization answers the question "What can you access?" based on user identity or other information. WebLogic Server provides an authorization provider to limit interaction between the users and the WebLogic resources to ensure integrity, confidentiality, and availability.
In this scenario, a user (or a client application), also referred to as the subject, attempts to log in to a system with a username/password combination. Oracle WebLogic establishes trust by validating that user's username and password. WebLogic Server passes the subject to the specified Principal Validation provider, which signs the principals and then returns them to the client application via WebLogic Server.
A principal is an identity assigned to a user or group as a result of authentication. The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals. Whenever the principals stored within the subject are required for other security operations, the same Principal Validation provider will verify that the principals stored within the subject have not been modified since they were signed. When the user (subject) enters the user name and password, these properties and any other related information are encapsulated into the principal.
The validation of a principal is performed by the principal validator. After successfully proving the identity, an authentication context is established, which allows an identified user or system to be authorized.
During the authorization process, Oracle WebLogic determines whether it can perform a given operation on a given resource, and returns the result of that decision to the client application.
Roles are obtained from the Role Mapping providers and input to the Access Decisions. The Access Decisions are then consulted for an authorization result. If multiple Access Decisions are configured and return conflicting authorization results (such as PERMIT and DENY), an Adjudication provider is used to resolve the contradiction by returning a final decision.
