IT-Security (Part 6): WebLogic Server and Authorization

Key words: IT-Security, WebLogic Server, WebLogic Security Framework, Authorization, authorization process, Role Mapping, Roles, Adjudication Process, Security Service Provider Interfaces (SSPIs), Users, Groups, Principals and Subjects

We discussed about Authentication in Part 4 and 5[1]; now let us focus on Authorization topic. Authorization is known as access control too and is used to clear main questions such as: „What can you access?“, „Who has access to a WebLogic resource?“, „Is access allowed?“ and in general „Who can do what?“ In order to guarantee integrity, confidentiality (privacy), and availability of resources, WebLogic are restricted accesses to these resources. In other words, authorization process is responsible to grant access to specific resources based on an authenticated user’s privileges.

Authorization: What can you access?

After authentication one user, it is the first question that system has to answer: „What can you access?“ In this sense, WebLogic Server has to clear, which resources are available for a particular user, that will be cleared by using the user’s security role and the security policy assigned to the requested WebLogic resource. A WebLogic resource is generally understood as a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access using security roles and security policies. WebLogic resource implementations are available for[2]:

  • Administrative resources
  • Application resources
  • Common Object Model (COM) resources
  • Enterprise Information System (EIS) resources
  • Enterprise JavaBean (EJB) resources
  • Java Database Connectivity (JDBC) resources
  • Java Messaging Service (JMS) resources
  • Java Naming and Directory Interface (JNDI) resources
  • Server resources
  • Web application resources
  • Web service resources
  • Work Context resources

The Authorization Process

I’m going to clear whole process in a top-down approach. First of all, we have to see what will be happen in Authorization Process? Figure 1 Authorization Process[3] shows how WebLogic Security Framework communicated with a particular Security Provider and Authorization providers respectively.

 

Authorization Process

Authorization Process

Figure 1 Authorization Process

If a user want to use one protected resource, then WebLogic send a request to “Resource Container” that handles the type of WebLogic resource being requested receives the request (for example, the EJB container receives the request for an EJB resource). It forwards to “WebLogic Security Framework” and its request parameters, including information such as the subject of the request and the WebLogic resource being requested. The Role Mapping providers use the request parameters to compute a list of roles to which the subject making the request is entitled and passes the list of applicable roles back to the WebLogic Security Framework. On this information will be decided about authorization: e.g. PERMIT and/or DENY. WebLogic Server provides an auditing to collect, store and distribute information about requests and outcomes. It calls Adjudication. It can happened that for Authorization is defined multiple providers. For such cases is an Adjudication provider available. The WebLogic Security Framework delegates the job of merging any conflicts in the Access Decisions rendered by the Authorization providers to the Adjudication provider. It resolves the conflicts and sends a final decision (TRUE or FALSE) to WebLogic Security Framework.[4]

WebLogic Security Framework

I have mentioned a bit about WebLogic Security Framework in Part 1 and 2[5]. Figure 2 WebLogic Security Service Architecture shows a high-level view of the WebLogic Security Framework. The framework contains interfaces, classes, and exceptions in the weblogic.security.service package. The Framework provides a simplified application programming interface (API) that can be used by security and application developers to define security services. Within that context, the WebLogic Security Framework also acts as an intermediary between the WebLogic containers (Web and EJB), the Resource containers, and the security providers[6].

WebLogic Security Framework

WebLogic Security Framework

Figure 2 WebLogic Security Service Architecture

The Security Service Provider Interfaces (SSPIs) can be used by developers and third-party vendors to develop security providers for the WebLogic Server environment[7].

Security Provider

Figure 1 Authorization Process presents Security Provider as next module that provides security services to applications to protect WebLogic resources.  A security provider consists of runtime classes and MBeans, which are created from SSPIs and/or Mbean types. Security providers are WebLogic security providers (provided with WebLogic Server) or custom security providers. 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.

Roles

In order to complete authorization process, is Role Mapping within security provider necessary. Simple to say, a role mapper maps a valid token to a WebLogic user. Formerly that we focus on Roles, I would like to clarify a few more terms.

Users, Groups, Principals and Subjects

User is an entity that is authenticated in our security provider in last steps (See: Part 4 and 5 – Authentication Process[8]). A user can be a person or a software entity or other instances of WebLogic Server. As a result of authentication, a user is assigned an identity, or principal. A principal is an identity assigned to a user or group as a result of authentication and can consist of any number of users and groups. Principals are typically stored within subjects. Both users and groups can be used as principals by WebLogic Server.

Groups are logically ordered sets of users. Usually, group members have something in common. For example, a company may separate its IT-Department into two groups, Admins and Developers. In this form, it will be possible to define different levels of access to WebLogic resources, depending on their group membership. Managing groups is more efficient than managing large numbers of users individually. For example, an administrator can specify permissions for several 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[9].

Security Roles

Role is 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. A security role is a privilege granted to users or groups based on specific conditions[10].

Like groups, security roles allow you to restrict access to WebLogic resources for several users at once. However, unlike groups, security roles[11]:

  • Are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day.
  • Can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain (unlike groups, which are always scoped to an entire 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 is „in“ the security role. Multiple users or groups can be granted a single security role. It can be summarized as follows:

Groups are static and defined on Domain level (coarse granularity) and Roles are dynamic and defined on Resource level (fine granularity). Continued…

See too last parts of IT-Security and Oracle Fusion Middleware:

  1. https://thecattlecrew.wordpress.com/2014/02/17/it-security-weblogic-server_1/
  2. https://thecattlecrew.wordpress.com/2014/03/05/it-security-part-2-weblogic-server-and-oracle-platform-security-services-opss-2/
  3. https://thecattlecrew.wordpress.com/2014/03/14/it-security-part-3-weblogic-server-and-java-security-features/
  4. https://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/
  5. https://thecattlecrew.wordpress.com/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/

[1] See: https://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/

and https://thecattlecrew.wordpress.com/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/

[2] Oracle® Fusion Middleware Understanding Security for Oracle WebLogic Server, 11g Release 1 (10.3.6), E13710-06

[3] Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6), E13707-06

[4] Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6), E13707-06

[5] See: https://thecattlecrew.wordpress.com/2014/02/17/it-security-weblogic-server_1/

and https://thecattlecrew.wordpress.com/2014/03/05/it-security-part-2-weblogic-server-and-oracle-platform-security-services-opss-2/

[6] See: http://docs.oracle.com/cd/E24329_01/web.1211/e24484/archtect.htm

[7] See: http://docs.oracle.com/cd/E24329_01/web.1211/e24446/security.htm#autoId3

[8] See: https://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/

and https://thecattlecrew.wordpress.com/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/

[9] See: http://docs.oracle.com/cd/E28280_01/apirefs.1111/e13952/taskhelp/security/ManageUsersAndGroups.html

[10] See: http://docs.oracle.com/cd/E13222_01/wls/docs81/secwlres/secroles.html

[11] See: http://docs.oracle.com/cd/E13222_01/wls/docs90/secintro/realm_chap.html