Declarative Role-based Security

WebLogic Platform uses declarative security to configure authorization. Instead of embedding security logic in the application code, deployment descriptor files are used to do the following:

• Determine what roles should have access to protected resources.

• Map the roles to principals (or users) maintained in the security database or repository.

With this decoupling of security data from the application, the system can be maintained and reconfigured easily.

Determining What Roles Should Have Access

With WebLogic Workshop, the system automatically does much of the deployment descriptor configuration at compile time, based on special annotations that developers set in their component code.

For Enterprise JavaBean (EJB) projects and all components implemented as EJBsJava controls, Web services, and process definition filesauthorization is configured through the @common:security annotation. This annotation has six attributes; the key one is the roles-allowed attribute, which defines a list of security roles that can access the given resource. The other attributes are used for more advanced security operations. All the attributes are summarized in Table 14.5. The annotation can occur at the class level or the individual method level. Listing 14.3 provides an example of a Newsletter Web service file showing authorization at the method-level scope. In this case, all visitors to the Casino Web site can get the free newsletter and subscribe to the paid edition, but only managers can retrieve the list of subscribers.

Table 14.5. @commmon:security Annotation Attributes

ATTRIBUTE	DEFINITION
roles-allowed	List of roles authorized to access the resource
roles-referenced	List of roles that can be used to call other protected resources
run-as-principal	Allows the called resource to assume the identity of the principal before method invocation; requires the run-as attribute to be set, as well
run-as	Allows the called resource to change the role before invocation
single-principal	Used for conversations and can be true or false; if true, only the principal ( user ) who began the conversation can continue
callback-roles-allowed	Lists roles authorized to invoke callbacks on the resource; applicable only to controls that have defined callbacks

Listing 14.3. Sample Web Service ( .jws ) File That Shows Method Authorization Scoping

 public class Newsletter implements com.bea.jws.WebService {     static final long serialVersionUID = 1L;     /**      * @common:operation      */     public void getFreeEdition()     {     }     /**      * @common:operation      */     public void subscribe()     {     }     /**      * @common:operation      * @commmon:security roles-allowed="managers"      */     public void getSubscriberList()     {     } } 

For Web applications, authorization is configured through the @jpf:controller and @jpf:action annotations. The former is defined at the class level; the latter is used to configure at the method level. For the purpose of authorization, both annotations have a single pertinent attribute, roles-allowed . This attribute defines a list of security roles that can access the given resource.

Mapping Roles to Principals

With applications generated by Workshop, roles and their mappings to principals can be configured in three locations:

• At the enterprise application level

• At the Web application level

• At the EJB level

Roles and mappings at the enterprise application level are inherited by the Web application and EJB levels. To configure them through the application's Security Roles folder visible in the Workshop Application pane, follow these steps:

1. Right-click on the Security Roles folder.

2. Select the Create a New Role option.

3. Specify the role name .

All data from the entries in this folder are added automatically to the appropriate deployment descriptors at compile time.

Similarly, for EJB- related components, both the role definitions and the mappings are added automatically to the appropriate deployment descriptors at compile time. In this case, the configuration is based on the settings of the @common:security annotation in the Workshop code files, mentioned in the previous section, "Determining What Roles Should Have Access."

Configuration at the Web application level, however, requires manual editing of the deployment descriptor files. Table 14.6 summarizes the deployment descriptor files used at all three levels as well as the steps to configure them.

Table 14.6. Deployment Descriptors That Store Role and Mapping Data

DESCRIPTOR	ACTION REQUIRED
application.xml	Configure through menu options on Security Roles folder in Workshop
weblogic-application.xml	Configure through menu options on Security Roles folder in Workshop
ejb-jar.xml	Configure through @common:security annotations in Workshop source files
weblogic-ejb-jar.xml	Configure through @common:security annotations in Workshop source files
web.xml	Configure by manually adding <auth-constraint> element and <security-role> elements
weblogic.xml	Configure by manually adding <security-role-assignment> element

Authenticating Users

After the protected resources are linked to roles via the <auth-constraint> element in the WEB-INF/web.xml file, requests for accessing these resources cause the browser to prompt the user for a username and password. If, however, two-way SSL is established, no login prompt is necessary; the system authenticates the user based on the client certificate.

Testing Role-based Security

Setting up test security users to verify that resources are properly protected couldn't be easier. Creating a role at the application layer, as described earlier, automatically creates a user with the same name as the role and a password set to password . This user is added to the WebLogic Server default security provider, an embedded Lightweight Data Access Protocol (LDAP) server.

To learn more about configuring the LDAP server or replacing it with a different security provider, consult the online WebLogic Server product documentation at

http://edocs.bea.com/wls/docs81/secmanage/index.html