Chapter 2 Securing Component Access

Intercomponent authentication for EJBs and servlets

EAServer 4.0 implements J2EE version 1.3 security requirements, including Java and C++ ORB support and CORBA Secure Interoperable version 2 protocol (CSIv2). CSIv2 is part of EJB version 2.0 interoperability requirements, and supports:

EJB 2.0 security features including:
- Caller propagation on remote servers from EJB 2.0 clients using RMI/IIOP.
- Run-as support
- Trust identities
Servlet 2.3 security enhancements including:
- Caller propagation on remote servers
- Run-as support
Java Authentication and Authorization Service (JAAS) - see Chapter 9, "Using the JAAS API" for more information.

Other references

For more information about J2EE version 1.3, see the Java Web site http://java.sun.com/j2ee .

For more information about servlet technology, see the Java Web site http://java.sun.com/products/servlet/index.html .

For more information about CSIv2, see the OMG Web site http://www.omg.org/technology/documents/formal/omg_security.htm

Intercomponent authentication for EJB 2.0 components

EJB 2.0 components use caller propagation to pass client information between servers for authentication, whereas run-as support allows EJB 2.0 components to perform method invocations on other components using a different identity.

Caller propagation

Caller propagation allows an EJB 2.0 RMI/IIOP client to pass principal information to a server and have that information propagated to other servers. In other words, EAServer 4.0 can pass a client's user name or X.509 certificate information from an EJB on one server, to an EJB on a different server. For example:

The client passes principal information to EAServer1, where the information is authenticated.
EAServer1 retrieves the remote client's authentication information by calling getCallerPrincipal().
EJBA, on EAServer1, makes a call to another Bean, which resides on EAServer2.
The propagated caller information is retrieved on EAServer2 using the getCallerPrincipal() method.

To enable caller propagation for EJB component calls made in servlet or component code, you must specify a corbaname URL in the EJB Reference properties for the EJB component, servlet, or JSP that issues the call.

For information on interoperable naming URLs, see "EAServer EJB Interoperability" in the EAServer Programmer's Guide.

Run-as support

Normally, when a component calls another component, the invocation uses the client's credentials. You can use identities to specify alternate credentials for intercomponent calls. Identities map logical identity names to a user name, password, and required SSL session characteristics. The identity names are used in the run-as mode settings for components and component methods.

Run-as support enables an EJB 2.0 component to perform method invocations on other components using a specified identity. This identity can be configured at deployment time. In the standard EJB 2.0 deployment descriptor, the run-as property is expressed in terms of a role. The role is a name of a security-role element defined in the same deployment descriptor. It is expected that at deployment time, or when configuring a new EJB, the role name should be defined. Further, the deployer selects a Jaguar identity that is expected to be present in this role. This Jaguar identity is used while invoking another EJB. The run-as feature can be enabled via Jaguar Manager.

To enable use of the run-as identity for EJB component calls made in component code, you must specify corbaname URLs in the EJB Reference properties for the EJB component that issues the call. For information on interoperable naming URLs, see the "EAServer EJB Interoperability" chapter in the EAServer Programmer's Guide.

Configuring an EJB 2.0 component to run as a different identity

If necessary, define the identity to be used as described in "Configuring identities".
Highlight the EJB 2.0 component for which you are establishing a run-as identity.
Display the Run As Identity tab and configure the settings as follows:
- Run as - choose specified .
- Role - specify a role name. The identity specified in the Mapped to Jaguar identity field should be in this role. This name is used if the component is exported to an EJB-JAR file.
- Run as identity - specify a logical identity name.
- Mapped to Jaguar identity - choose an EAServer identity from the pull down menu. This is the identity with which the component executes.
- Description - enter an optional text comment. This field can be used to provide identity mapping instructions for the deployer when the component is deployed to another server.
The Existing Mappings on the Package table displays logical identity names that are mapped to EAServer identities by components in the same package.

You can configure a run-as identity application or server-wide. This provides a convenient way to globally set the run-as identity for all of the EJBs in an application or server.

Configuring EJB 2.0 components or servlets to run as a different identity at the application or server level

If necessary, define the identity to be used as described in "Configuring identities".
Select the server or application for which you are configuring the run-as identity.
Select File | Server Properties or File | Application Properties.
Select the Security tab.
For a server, click the Set Trusted and Security Identities button. Select the run-as identity from the Run-as Identity drop-down list.

To set the run-as identity application-wide, select the run-as identity from the Run-as Identity drop-down list.

You can check the setting of your run-as identity from the All Properties tab by viewing the com.sybase.jaguar.server.security.runasidentity property, and the com.sybase.jaguar.application.security.runasidentity property. Do not set the run-as identity in the All Properties tab since these values are overwritten by the values set in the Security tab.

Trusted identities

Identities defined in Jaguar Manager configure client identities (user names, SSL certificates, or Entrust users) that can be assumed by executing components. For caller propagation, EAServer requires an identity to propagate a remote client's credentials to another server when it cannot include, as part of the request, the client's authentication data (password or a private key corresponding to a X.509 certificate). You configure a server (or container) to trust a set of identities that vouch for the client. These identities are known as trusted identities.If a target server trusts an intermediate server, it is implied that the target server trusts all servers trusted by the intermediate server.A server or container needs to establish a list of identities it trusts. Servers and containers use identities for the purpose of authentication. Other servers need to know the list of trusted identities for a server while connecting to it.

Configuring an identity for outgoing credential propagation

An identity is required when a server is making remote IIOP or IIOPS connections to other servers, and is not necessary for in-server or in-memory component calls. Use Jaguar Manager to establish this identity at the server or application level.

Configuring a security identity for outgoing interserver calls

If necessary, define the identity to be used as described in "Configuring identities".
Select the server or application for which you are configuring the security identity.
Select File | Server Properties or File | Application Properties.
Select the Security tab.
For a server, click the Set Trusted and Security Identities button. Select the security identity from the Security Identity drop-down list.

For an application, select the security identity from the Security Identity drop-down list.

You can check the setting of your security identity from the All Properties tab by viewing the com.sybase.jaguar.server.security.identity property, and the com.sybase.jaguar.application.security.identity property. Do not set the security identity in the All Properties tab since these values are overwritten by the values set in the Security tab.

Enabling trusted identities on the peer

A trusted identity vouches for someone else and is always authenticated by the peer. Establish a list of trusted identities at the server or application level.

Establishing a list of trusted identities for incoming interserver calls

If necessary, define identities to be trusted as described in "Configuring identities".
Select the server or application for which you are establishing trusted identities.
Select File | Server Properties or File | Application Properties.
Select the Security tab.
For a server, click the Set Trusted and Security Identities button. Click the Add button and highlight the identity you are adding from the drop-down list. Add as many identities as you want, one at a time.

For an application, click the Add button and highlight the identity you are adding from the drop-down list. Add as many identities as you want, one at a time.

Use the Remove button to remove a trusted identity.

You can check the settings of your trusted identities from the All Properties tab by viewing the com.sybase.jaguar.server.trustedidentities property, and the com.sybase.jaguar.server.applicaiton.trustedidentities property. Do not set trusted identities in the All Properties tab since these values are overwritten by the values set in the Security tab.

Authentication of component invocation from servlets

This section describes how to propagate servlet credentials between servers and how to use identities to map logical identity names to a user name, password, and required SSL session characteristics. The identity names are used in the run-as mode settings on Beans called from a servlets.

Caller propagation for servlets on remote servers

A servlet's or JSP's HTTP client credentials are propagated when EJBs are invoked on remote servers. Earlier versions of EAServer propagated user name/password or digital IDs, and only within the same server.

Run-as support

Run-as support for servlets is similar to run-as support for EJBs:

Run-as support is defined on a per-servlet basis.
Run-as support applies to all method invocations on Beans called from the servlet.

To enable run-as support for servlets or JSPs, the servlet or JSP must be installed in a Web application. Additionally, you must specify corbaname URLs in the EJB Reference properties for the servlet or JSP that issues the call. For information on interoperable naming URLs, see "EAServer EJB Interoperability" in the EAServer Programmer's Guide.

From Jaguar Manager, configure the run-as identity as follows:

Expand the icon for your Web application.
Highlight the servlet for which you are configuring run-as support.
Display the Run As Identity tab and configure the settings as follows:
- Run as - choose specified .
- Role - specify a role name. The identity specified in the Mapped to Jaguar identity field should be in this role. This name is used if the Web application exported to a WAR file.
- Run as identity - specify a logical identity name.
- Mapped to Jaguar identity - choose an EAServer identity from the drop-down list. This is the identity with which the servlet invokes components.
- Description - enter an optional text comment. This field can be used to provide identity mapping instructions for the deployer when the Web application is deployed to another server.
The Existing Mappings on the Web Application table displays logical identity names that are mapped to EAServer identities by servlets in the same Web application.

You can configure a run-as identity application or server-wide. This provides a convenient way to globally set the run-as identity for all of the servlets/JSPs in an application or server. See "Configuring EJB 2.0 components or servlets to run as a different identity at the application or server level" for more information.

New restrictions for EJBs and servlets

The EJB 2.0 and Servlet 2.3 specifications introduce the following restrictions for EJB 2.0 components and servlets:

For EJB 2.0 components, if there are no roles associated with a method, 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.

If you do not want to assign roles to all methods, and would like to treat methods with no role assignments as accessible by all users, set the com.sybase.jaguar.server.ejb.role.default property as described in "EJB 2.0 authorization of methods with no defined permissions".
For servlets, defining a security constraint does not define any authorization constraints. You must define an authorization constraint to access the servlet, which is a change from the Servlet 2.2 implementation.

EJB 2.0 component behavior in EAServer 4.0 versus 4.1 and later

The effect of the com.sybase.jaguar.server.ejb.role.default property on EJB 2.0 components in EAServer 4.0 differs from EAServer version 4.1 and later:

The com.sybase.jaguar.server.ejb.role.default property is a server-wide property. To assign roles to all methods of an EJB 2.0 component in EAServer 4.0, you can assign individual roles to all methods of the component, or set the com.sybase.jaguar.server.ejb.role.default property to everybody.
In EAServer 4.1 and later, com.sybase.jaguar.server.ejb.role.default has been removed. To assign a role to any one method of an EJB 2.0 component, assign roles to all methods of the component. Otherwise, the server displays an error message when trying to execute the method that does not have a role assigned to it.

If none of the methods of an EJB 2.0 component have roles assigned to them, authorization checks are not enforced and authorization is not performed. No error message is sent to the server log.