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 11, “Using the JAAS API” for more information.
For more information about J2EE version 1.3, see the Java Web site .
For more information about servlet technology, see the Java Web site .
For more information about CSIv2, see the OMG Web site
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 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 Chapter 9, “EAServer EJB Interoperability,” in the EAServer Programmer’s Guide.
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 EAServer 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 Chapter
9, “EAServer EJB Interoperability,” 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
Advanced 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 Advanced tab since these values
are overwritten by the values set in the Security tab.
Identities defined in EAServer 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.
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 EAServer 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
Advanced 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 Advanced tab since these values
are overwritten by the values set in the Security tab.
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 Advanced 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 Advanced tab since these values are
overwritten by the values set in the Security tab.
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.
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 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 Chapter
9, “EAServer EJB Interoperability,” in
the EAServer Programmer’s Guide.
From EAServer 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.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|