Chapter 2 Securing Component Access

Quality of protection

Jaguar Manager allows you to set the quality of protection (QOP) for EAServer packages, components, and methods. QOP establishes a minimum level of encryption and authentication that a client must meet before it can access your business logic. For example, if you do not set a QOP at the package level, all clients can access the package. You can then set a QOP that restricts access to components within that package, and a different QOP that further restricts access to methods within those components.

This chapter discusses setting server-side QOP. For information about configuring client-side QOP, see:

The component's QOP setting is ignored if the user is the system user; in other words, the user is jagadmin or the component is being called by a service or other component that runs with the system identity.

Naming service support

The client's QOP, EAServer listener's security profile, and the package, component, and method QOP work together to establish end-to-end security. To accommodate naming services and reduce connection time, a special CORBA component tag is set in the interoperable object reference (IOR). The naming service sends only profiles with QOPs that match a client's QOP so that the client tries to access only listeners and packages, components, and methods for which the client has a compatible QOP.

Usage scenarios

Figure 2-1 illustrates two clients trying to access component A. A QOP of sybpks_strong is set for the component. To access the component, the client must use a QOP that meets the minimum requirements of the component's QOP, and communicate with a listener that also meets the minimum requirements of the component's QOP.

Figure 2-1: QOP usage

In Figure 2-1:

Client 1 accesses the server at listener port 9001, but cannot access the component because the client's QOP does not meet the minimum requirements of component A.
Client 2 accesses the server at listener port 9002. The listener and client negotiate a CipherSuite that both support. The highest CipherSuite that both client and listener support uses 40-bit encryption and does not meet the minimum requirement of component A, since sybpks_strong supports only 128-bit encryption. Even though the client supports the minimum QOP required to communicate with component A, it is blocked because the listener does not support this minimum requirement.

See Table 2-1 and Table 11-2 for more information about QOP compatibility.
Neither client supports mutual authentication; consequently, neither can access the listener at port 9003.

If a client has a QOP that includes mutual authentication, it can access a package, component, or method that does not, as long as there is a listener available to authenticate the client and the client's QOP meets the minimum level of security established at the package, component, or method. Figure 2-2 illustrates this scenario.

Figure 2-2: QOP-compatible listener

Controlling access to methods

Assuming that a compatible listener is configured on the server, Figure 2-3 illustrates a situation in which the client:

Cannot access method 1 because the client's QOP does not match the minimum required by the method.
Can access method 2 because sybpks_intl meets the security requirements of the method and component A, and the package has no QOP restrictions.
Cannot access method 3 or 4 because it is blocked at the component level.

Setting a weaker QOP at the method than the component serves no purpose since the client will already be blocked at the component.

Figure 2-3: Using QOP to limit access to methods

syb_osauth

In addition to setting a QOP that establishes minimum encryption requirements, Jaguar provides another QOP, syb_osauth, for operating system authentication. You can set two QOP settings at the package, component, or method level, as long as one of them is syb_osauth:

If syb_osauth is requested by the client and is not present in the package, component, or method QOP, the client ORB returns COMM_FAILURE and the message "no suitable profiles found."
If the client does not request syb_osauth and the component, method, or listener QOP requires OS authentication, it is considered compatible (for backward compatibility with Jaguar 3.x and 2.0 clients). In this case, the user name and password are used for OS authentication.

For syb_osauth to work properly, you must enable operating-system- based authentication server-wide (not at the listener level). If you do not, you cannot load packages, components, or methods that have the syb_osauth QOP set. See "Configuring OS authentication" for information about enabling authentication for your operating system.

In Figure 2-4:

Client 1 has a compatible QOP and supplies a user name and password to access method 1. Client 1 can access method 2 without authentication.
Client 2 has a compatible QOP and uses authentication to access method 1 but gets a COMM_FAILURE error if it tries to access method 2.

Figure 2-4: Using syb_osauth

Configuring QOP from Jaguar Manager

Highlight the package, component, or method for which you want to establish a QOP.

Select File | Package, Component, or Method Properties.
Select the All Properties tab and set:
- The com.sybase.package.qop property for a package.
- The com.sybase.component.qop property for a component.
- The com.sybase.method.qop property for a method.
If the property already exists, you can highlight it and click Modify. Otherwise, click Add.
Enter the appropriate property name in the Property Name field and one (or two if using syb_osauth) of the values from Table 2-1 in the Property Value field.

After configuring QOP, you must either refresh or restart the server for your changes to take effect.

Table 2-1 provides a hierarchy of QOP settings. For a given client to access your business logic:

A QOP-compatible listener must be available on the server, and
Either the same or weaker QOP or no QOP restrictions must be placed on the package/component/method.

Table 2-1: QOP hierarchy
QOP hierarchy from weaker to stronger	Comments
syb_osauth sybpks_domestic_anon sybpks_simple sybpks_simple_mutual_auth sybpks_intl sybpks_intl_mutual_auth sybpks_domestic sybpks_domestic_mutual_auth sybpks_strong sybpks_strong_mutual_auth	Some QOP profiles overlap. For example, sybpks_domestic supports both 128-bit encryption and 40-bit encryption. If you use sybpks_domestic as a package QOP, a client QOP of sybpks_intl meets the minimum requirement of 40-bit encryption. sybpks_strong supports only 128-bit encryption and is compatible with only one of the domestic or strong profiles. For a list of CipherSuites supported by each QOP profile, see Table 11-2.