Chapter 2 Securing Component Access

Client authorization

EAServer provides component authorization through both roles and custom components:

Roles EAServer's authorization model is based on roles. Define roles in Jaguar Manager. Each role can include and exclude specific user names and digital certificates. If you use native operating system authentication, you can also include and exclude operating system group names; all users in the specified group are affected.

Roles are attached to EAServer packages, components, and methods. Attaching a role to a package controls access to all components in the package. To use a component, a user must be allowed component access by both the roles that are attached to the component and the roles that are attached to the package that contains the component.

See "Configuring EAServer roles" for more information on defining roles.

Custom components EAServer provides role and authorization service components with which you can create and install your own component to authorize clients to access resources on EAServer. See Chapter 8, "Creating Authentication, Role, and Authorization Service Components"

Enterprise JavaBeans

EJB 1.0 components use the package, component, and method role-based access control model used by all other component types. "Configuring EAServer roles" describes how to configure roles and associate them with packages, components, and methods.

EJB 2.0 and 1.1 component security uses method-level constraints rather than the package and component role constraints used for other component models. The Roles folder does not display for EJB 2.0 or 1.1 components, or for packages that contain only EJB 2.0 or 1.1 components. If EJB 2.0 or 1.1 components are installed in a package that contains other component types, the package role folder has no effect on the EJB 2.0 or 1.1 components.

WARNING!

In the default server configuration, an EJB 2.0 method with no role constraints cannot be invoked by any user. The com.sybase.jaguar.server.ejb.role.default property has been deprecated in EAServer version 4.1. See "EJB 2.0 component behavior in EAServer 4.0 versus 4.1 and later" for more information about com.sybase.jaguar.server.ejb.role.default behavior.

To restrict access beyond the configured permissions, you can call the isCallerInRole Java method to check the user's role membership. If you call the isCallerInRole Java method, you must configure role references to map names used in isCallerInRole calls to J2EE role names that are configured in the package properties.

Configuring logical role mappings

Role settings in EJB 2.0 and 1.1 method permission use logical J2EE role names which must be mapped to EAServer role names in the properties of the package where the component is installed. The logical names are used when exporting the component to an EJB-JAR file. Configure role mappings as follows:

If necessary, define new EAServer roles to be used in the method level constraints. See "Configuring EAServer roles" for details.
Display the package properties.
Display the Role Mapping tab and configure the mappings as follows:
- To add a logical J2EE role name, click Add and enter the role name.
- To specify the mapped EAServer role, click in the right column, opposite the J2EE role to be mapped, then use the pull-down menu to choose the mapped role.

Configuring EJB 2.0 or 1.1 method permissions

If necessary, define new EAServer roles to be used by callers of the component and map them to J2EE roles in the package properties. You must map a J2EE role name for each role to be used in method permissions.
For each method that requires limited access, display the Method Properties dialog and highlight the Permissions tab. A check box displays for each mapped J2EE role in the package that contains the component. Select the check box by each role that can call the method.

Several predefined roles are available. For example, select the predefined "everybody" role if all users are to have access, or select "nobody" if all users are to be denied access. "Predefined roles" describes the other predefined EAServer roles.

If the logical J2EE role is not mapped to an EAServer role, then at runtime, the server defaults to performing role checks against the logical J2EE role. The server assumes there exists an EAServer role with the same name as that of the logical J2EE role.

Configuring EJB 2.0 or 1.1 role references

If necessary, define new EAServer roles to be used by callers of the component. and map them to J2EE roles in the package properties. You must map a J2EE role name for each role to be used in role references.
For each component that calls the isCallerInRole method, display the Component Properties dialog and highlight the Role Refs tab. Add or modify roles as follows:
- To add a role, click Add and edit the new entry as described below.
- To modify a role, edit the Reference Name (used in isCallerInRole calls), and choose the mapped J2EE role (configured in the properties of the package where the component is installed).

EJB 2.0 authorization of methods with no defined permissions

For EJB 2.0 components, if there are no roles associated with a method, then access is denied to everyone, which is different from EJB version 1.x . Keep this in mind when upgrading from EJB version 1.x to 2.0. Also see "EJB 2.0 component behavior in EAServer 4.0 versus 4.1 and later" for more information about com.sybase.jaguar.server.ejb.role.default behavior.

The com.sybase.jaguar.server.ejb.role.default property affects only EJB 2.0 components, not EJB 1.1 or 1.0 components.

Usually a role reference is mapped to a J2EE role. However, sometimes the mapping to the J2EE role may be missing, either intentionally, or due to mappings or customization not being performed after you deploy a J2EE application. In some cases, the mapping of the J2EE role to the EAServer role is missing. The following describes the behavior of the server in such cases:

If a role reference to J2EE role mapping is located, then a mapping between the J2EE role and an EAServer role is searched. If the search fails, role checks are performed against the J2EE role directly. If the search succeeds, then role checks are performed against the EAServer role.
If the role reference to J2EE role mapping search fails, then a mapping between the role reference and an EAServer role is performed. If a match is found, role checks are performed against the EAServer role. Otherwise, role checks are performed against the role reference directly.

In some EAServer and application configurations, the role reference name, the J2EE role name, and EAServer role name may be the same. In such cases, even though the mappings have not been explicitly set by the deployer at run time the server uses the default behavior, and EAServer performs the role checks internally against the EAServer role. In some application environments, this may be the intended and desired behavior, while in other environments, this may be unintended.

Role checks performed against a role that is not defined in the repository fail. If there is a role service or an authorization service, these services are consulted. See Chapter 8, "Creating Authentication, Role, and Authorization Service Components"

EJB 2.0 authorization For an EJB 2.0 bean, if there are no method permissions defined for all methods, no authorization checks are performed, and access is granted to any user. If however, any one method has a permission assigned to it, then you must assign permissions to all methods to allow client access, otherwise, your clients will be denied access due to an authorization failure.