Proxy User Processing Logic

In earlier sections, the relationship between authorized user objects and proxy user objects was described, as well as an introduction of external (SPECIAL) proxy user authentication methods. This section gives more specifics regarding these objects and mechanisms, and the sequence of steps performed upon them by the processing logic.

There are fundamentally two types of authentication processing performed in SunScreen. Whenever a user identity is required, authentication processing occurs first, using one of these two processes. After SUCCESS is obtained in the authentication of an identity you supplied, access control matching determines if the user is allowed to perform the operation being attempted; authentication FAILURE denies any requested operation. (Access control is described in the section "User Access Control Processing Logic".)

The first type of processing is the authentication of an authorized user object directly. This form occurs when authenticating an administrator of SunScreen, either through the administration GUI Login page or by the ssadm login subcommand. In these situations, the user name provided must match an ENABLED authorized user object. Authentication logic has been previously described (see "Authorized User Authentication Processing Logic").

The second type of processing is the authentication of a proxy user object. This form occurs when authenticating a user who desires access through the FTP or telnet proxies.

As previously introduced, authentication of a proxy user object can take one of three subpaths: (1) null authentication, (2) authorized user authentication, or (3) SPECIAL external authentication method processing.

Regardless of the proxy user authentication path, only ENABLED objects can be used for authentication. A DISABLED object always results in an authentication FAILURE if attempted.

Null Authentication

Null authentication occurs when a SIMPLE proxy user object named by the user contains no auth_user_name= item. In this situation, whatever input is given for the password is accepted without any checking. The preinstalled anonymous and ftp proxy user objects are examples of this type of authentication.

There is nothing special about the names anonymous and ftp for these preinstalled objects. You can create additional null authentication proxy user objects and use them instead of or in addition to the preinstalled ones. This allows the creation of null authentication paths that are private to your installation.

Referenced Authorized User Authentication

Authorized user authentication occurs when an auth_user_name= item is present. In this situation, authorized user authentication logic is performed on the authorized user object named in the item (see "Authorized User Authentication Processing Logic").

SPECIAL External Method Authentication

SPECIAL external authentication method processing occurs when you supply an identity, which is a compound name consisting of a SPECIAL external authentication method and a backend user name.

The syntax of this compound name is:

/ext_method_name/back_end_username

For example, compound names that use the preinstalled RADIUS and SecurID SPECIAL methods might be:

	/radius/jeffh 	/securid/jeffh

There is nothing special about the names radius and securid in these preinstalled SPECIAL objects; they are distinguished by their special radius or securid items. You can create additional SPECIAL authentication methods and use them instead of or in addition to the preinstalled ones. This enables you to create authentication paths that are private to your installation, perhaps to hide these paths or to abbreviate user input.

SPECIAL external authentication logic varies depending upon the method in question. More specifics about the two external methods (RADIUS and SecurID) can be found in later sections. There are two means for using SecurID tokens for authentication: one within the authorized user object, the other through SPECIAL external proxy user objects. The reason for this apparent redundancy lies in the level of trustedness of the two mechanisms. When using the authorized user path, an association is formed between a specific SunScreen authorized user object and a specific SecurID token holder. The SPECIAL external authentication mechanism allows, in essence, SecurID to authenticate any user who passes the challenges. The ability to establish authenticity for purposes of SunScreen administration is never available to SPECIAL external authentication.

You choose the mechanism to employ depending upon the security requirements of your site.

User Access Control Processing Logic

As previously referenced, once an identity is supplied, the would-be user is authenticated. This (now authentic) user must be allowed to perform the operation presently being attempted. The logic that determines the abilities of a user is loosely termed access control.

As with the initial nature of user authentication, there are two contexts within which access control is employed: SunScreen administrative activities and usage of network facilities controlled by FTP, Telnet, and (optionally) HTTP proxies.

Once an administrative user has been authenticated, access to administrative capabilities is controlled by the administrative rules for both remote and local use. Within each such rule, a user name is found. If the authorized user named within the rule matches the authenticated identity, then access is granted at the level the rule specifies. Alternatively, the rule can reference a proxy user object; if the authenticated identity is a member of that proxy user object, then the associated rule-specified access is likewise allowed.

SunScreen proxies that perform user authentication do so by requiring their rules to reference a proxy user object. Once the user-supplied identity has been authenticated, that identity (which is always a proxy user in this context) is evaluated to see if it is a member of the proxy user object that the rule referenced. If it is, then the associated rule matches. (See Chapter 10, Proxies.)