An Overview of Role-Based Security
The topics in this section explain how role-based security can be used to restrict access to resources (web services, page flows, Java controls, EJBs) to only those users who have been granted a particular security role. It also explains the relationship between EJB-scoped, application-scoped, web-application scoped, and global security roles.
To restrict access you set up two kinds of tests that candidate users must pass to access some resources: an authentication process, which determines the user's identity and group membership, and an authorization process, which decides whether a user has the role membership necessary to access a particular resource. Once a user has access to a method and the method executes, it can run under the security role of the user or under a different security role.
The Authentication Process
A candidate user is first tested against the authentication process. The authentication process is generally a login process, where the candidate user is asked to provide a username and password. If the candidate succeeds in passing this challenge, the user is granted a set of identities: one identity is his username identity, the other identities are the set of groups that user has membership in. The user's username identity and group identities are called the user's principals: think of these principals as a set of credentials that the user presents when he/she wants to access some resource protected by an authorization process. For more information, see Authentication.
The Authorization Process
In the authorization process, users are tested to see if they have been granted the required role to access the protected resource. If they have been granted the required role, they can access the resource; if they haven't, they are denied access. A user has been granted a particular role if one of his/her principals has been granted a particular role. Principals are granted roles by a set of role-principal mappings.
Note. A user can be a person or another software component. For instance, a web service can invoke an EJB's method with security restrictions; if the web service does not pass the authorization process, it is prevented from invoking the EJB method.
Global Roles
Global roles are available to all resources within a server's security realm, that is, a server's domain. These roles can be used by any application and any resource using this domain. WebLogic Server predefines a set of global roles but you can define additional global roles as needed. For more information, see the WebLogic Server help topic Securing WebLogic Resources.
Scoped Roles
Scoped roles apply to a particular resource. WebLogic Workshop applications can have three different scopings:
- Application scoped (defined in the application's application.xml / weblogic-application.xml files)
-
Web application scoped (defined in a project's web.xml / weblogic.xml files)
-
EJB scoped (defined in an EJB's ejb-jar.xml / weblogic-ejb-jar.xml files)
Application scoped roles can be used in an authorization process to protect any of the resources within the application, whereas web application scoped roles apply only to the resources within an individual web project and EJB scoped roles apply only to the resources within an individual EJB. For instance, if you want a security role to be defined just for a particular EJB, you make it EJB-scoped.
Note that EJB scoped roles do not exclusively protect WebLogic Workshop's EJB projects: they also can be used to protect Web Services, Java control extensions (JCX files), and JPD files. This is because all these files are compiled into EJBs at compile time.
The following diagram shows the three kinds of scoped roles, and corresponding deployment descriptors, that you can define with WebLogic Workshop.
Note. You can also define scoped security roles for other resources such as JDBC resources. For more information, see the WebLogic Server help topic Securing WebLogic Resources.
Role-Principal Mapping
Role-principal mappings define how principals map to security roles. A particular user can be mapped to one or more security roles or a group can be mapped to one or more security roles. Role-principal mappings for a scoped role are defined in the appropriate deployment descriptor configuration file (see the <security-role-assignment> fragments in the above picture; this is discussed in more detail in Implementing Role-Based Security).
For scoped roles, you can alternatively use the <externally-defined/> element to indicate that the role and role-principal mapping are defined elsewhere in the security realm. Specifically, when you use this element for EJB-scoped or web application scoped roles, WebLogic Server first examines the application-scoped roles for a role with the same name and with a role-principal mapping definition. If no appropriate application-scoped roles are found, global roles are examined. For application-scoped roles with the <externally-defined/> element, global roles are examined for role-principal mappings.
Note. When you map a scoped role to a principal, the principal is assumed to exist in the security realm. Role-principal mapping does not have the side effect of defining the principal if it doesn't exist. For more inforrmation, see Creating Principals and Role-Principal Mappings.
Running Under Another Security Role
An EJB, Java control, or web service method can run under the security role of the invoking user, or it can run under a different security role and principal. This might for instance be necessary when the EJB or web service in turn use resources that have strict security requirements. For an example, see EJB Security Sample.
Related Topics
Authentication
Implementing Role-Based Security
How Do I: Create An Application-Scoped Security Role?