Let’s continue with Authorization topic. We discussed about the Authorization Process and its main components such as WebLogic Security Framework and Security Provider. Now, we look at Security Provider’s subcomponents: Role Mapping and Security Policies.
The Role Mapping: Is access allowed?
Role Mapping providers help to clear, weather a user has the adequate role to access a resource? The Authorization provider can with this role information answer the “is access allowed?” question for WebLogic resources.
The Role Mapping Process
Role mapping is the process whereby principals are dynamically mapped to security roles at runtime. The WebLogic Security Framework sends Request Parameter to specific Role Mapping provider that is configured for a security realm as a part of an authorization decision. Figure 1 Role Mapping Process presents how the Role Mapping providers interact with the WebLogic Security Framework to create dynamic role associations. The result is a set of roles that apply to the principals stored in a subject at a given moment.
Figure 1 Role Mapping Process
Let’s review each part again:
- The request parameters are including information such as the subject of the request and the WebLogic resource being requested.
- Role Mapping provider contains a list of the roles. For instance, if a security policy specifies that the requestor is permitted to a particular role, the role is added to the list of roles that are applicable to the subject.
- As response, get WebLogic Security Framework the list of roles.
- These roles can then be used to make authorization decisions for protected WebLogic resources, as well as for resource container and application code. I’m going to discuss about that in part 9.
Read full post here.