Proxy Users

Proxy user is a named common object distinct from the authorized user. Proxy users are either SIMPLE or GROUP objects. SIMPLE objects are used to provide for and establish an association between individual authorized users and the role they play in using the facilities controlled by SunScreen. GROUP objects are used to allow creation of groups of SIMPLE proxy users that share common access to facilities. Thus, GROUPs streamline the task of allowing or removing access.

Some special proxy user objects also provide the means to map external collections of users into the access control facilities of SunScreen. In SunScreen, external access to SecurID users and RADIUS users is provided. (Access to other external user databases is afforded using RADIUS as an intermediary agent. For example, access to LDAP user databases stored through Sun Directory Services (SDS) are accessible through RADIUS.)

The figure below summarizes the relationship between rules, authorized users, proxy users, and external user databases.

Figure 9-1 Summary of the Relationship Between Rules, Authorized Users, Proxy Users, and External User Databases

Authorized users and proxy users names are distinct, and you can have objects with identical names in each. Choose a naming strategy for each set that best reflects the naming systems already employed. For example, you can choose to name authorized users by employee identities, like distinguishing names or employee numbers, and proxy users by names that reflect their normal user login names deployed on server systems (for example: UNIX login name). Names may not contain the following characters:

! # $ % ^ & * { } [ ] < > " \ ? ` / @ NULL

Names of authorized users, proxy users, and other user naming items are often deliberately chosen to be different for purposes of clarity.

The figure below shows the relationship of the proxy user to the authorized user and backend user name's password.

The records in the proxy-user database provide the link between the records in the authorized-user database and the backend user's name in the server's user database.

Figure 9-2 ProxyUser Example

Defining a Proxy User Object

The SIMPLE proxy user object is used to define associations between user authentication mechanisms and the identity a user assumes when connected to a permitted network resource. This association is loosely dubbed a role.

A SIMPLE proxy user object can indicate one of three types of authentication to be used: (1) none, (2) an authorized user object, or (3) an external authentication mechanism.

The relationship between SIMPLE proxy users and the authentication mechanism was shown in Figure 9-1.

A SIMPLE proxy user object also indicates the user identity string to be supplied when establishing the user identity on a network resource. This network resource is dubbed the backend server and, by derivation, the identity established on the backend server is defined by the backend_user_name item.

The backend_user_name is only used by the FTP proxy.

A GROUP proxy user object is a collection of one or more references to other proxy user objects, either SIMPLE or GROUP.

Any proxy user object, either SIMPLE or GROUP, contains the following items:

• name - Name of the entity (1 to 255 characters).

• enabled | disabled - The flag for the entire object. If disabled, authentication of the associated user is always denied. The default is enabled .

• group | simple - The type designator of the object. You can usually omit this on input because it can be deduced from the presence of other type-specific items.

• description="descstr" (Optional) - A demographic string that can be used to store notations about the role.

A SIMPLE proxy user object contains the following items:

• radius | securid (optional) - Indicates that this object is a SPECIAL one, associated with unrestricted mapping of users from the RADIUS or SecurID system (an external authentication method). Only one SPECIAL indicator can be present in a given proxy user object. If present, the next ( auth_user_name= ) item should not be given.

• auth_user_name="auser" (optional) - Indicates that the name of an authorized user object that is used to authenticate this user role. If it is absent, and if no SPECIAL item is present, then the proxy user object requires no authentication.

• backend_user_name="beuser" - Gives the backend user name string to supply when establishing the user's identity on a backend server. If no SPECIAL item is present, then this item is required, otherwise; it is ignored.

A GROUP proxy user object contains zero or more of the following items:

• member_name="memname" - Gives the name of another proxy user object that is a group member.

  ---

  Note -

  Although you can add a GROUP proxy user object, including a complete list of its members, the special commands addmember and deletemember are provided to edit the membership list of a GROUP.

  ---

Creating a Proxy User Object

The proxy user object is manipulated using the proxyuser subcommand of ssadm edit. proxyuser takes one of the following as commands:

• add "name" item... - Creates or overwrites an object. It takes a complete (perhaps initial, in the case of GROUP) description of the object, beginning with its name, followed by desired items, as defined above.

• delete "name" - Deletes a named object.

• addmember "grpname" "memname" - Adds a member to an existing GROUP object. Duplicate addmember operations are ignored.

• deletemember "grpname" "memname" - Deletes a member from an existing GROUP object. Any attempts to remove an unknown member are ignored.

• print[,sortopt] ["name"] - Displays one or more objects. If an object name is given, then only that object's definition is displayed; otherwise, all proxy user objects are displayed.

• names [,sortopt] - Displays the names of all objects. sortopt can be:

  • asc - ascending order by name (case-sensitive)

  • desc - descending order by name (case-sensitive)

  • iasc - ascending order by name (case-insensitive)

  • idesc - descending order by name (case-insensitive)

  • raw - order stored in database

  The default is asc.

Examples: Displaying, Creating, Adding, Removing Proxy User Objects

Following are examples of displaying, creating, adding, and removing proxy user objects:

To display existing proxy user objects, while logged into the primary Screen:

admin% ssadm -r primary edit Initial
edit> proxyuser print jdh
"jdh" ENABLED SIMPLE AUTH_USER_NAME="jeff.hogg" BACKEND_USER_NAME="jeffh" 
DESCRIPTION="Jeff Hogg as self on Solaris" 
edit> proxyuser print proxyusers
"proxyusers" ENABLED GROUP MEMBER_NAME="radius" MEMBER_NAME="jdh" 
DESCRIPTION="users allowed through FTP and telnet proxies"

To create the above SIMPLE proxy user object, while logged into the primary Screen:

admin% ssadm -r primary edit Initial
edit> proxyuser add jdh auth_user_name=jeff.hogg 
backend_user_name=jeffh description="Jeff Hogg as self on Solaris"
edit> quit

To create the above GROUP proxy user object, while logged into the primary Screen. First create the initial group with no members:

admin% ssadm -r primary edit Initial 
edit> proxyuser add proxyusers group description="users allowed through FTP
 and telnet proxies" 

The above empty group creation demonstrates a case where the GROUP type cannot be deduced from the other tags, since description= is a tag common to all proxy user object types.

To add the members of the example GROUP:

edit> proxyuser addmember proxyusers radius
edit> proxyuser addmember proxyusers jdh

Member names are stored in the order in which you add them to GROUP objects. The order is unimportant to authentication processing. This example also uses a SPECIAL object radius that is defined during initial installation.

In each of the above add operations, the items have been allowed to default to enabled.

Following are examples of displaying and removing proxy user objects.

To remove a member reference from a GROUP proxy user object, while logged into the primary Screen:

admin% ssadm -r primary edit Initial
edit> proxyuser deletemember proxyusers radius
edit> proxyuser print proxyusers 
"proxyusers" ENABLED GROUP MEMBER_NAME="jdh" 
DESCRIPTION="users allowed through FTP and telnet proxies"

To display all proxy user objects, while logged into the primary Screen:

admin% ssadm -r primary edit Initial
edit> proxyuser print
"admin" ENABLED SIMPLE AUTH_USER_NAME="admin" DESCRIPTION="initial SunScreen 
administrator" 
"admin-group" ENABLED GROUP MEMBER_NAME="admin" DESCRIPTION="SunScreen administrators"  
"anonymous" ENABLED SIMPLE BACKEND_USER_NAME="anonymous" 
DESCRIPTION="unauthenticated user, for anonymous FTP, etc."  
"ftp" ENABLED SIMPLE BACKEND_USER_NAME="anonymous" 
DESCRIPTION="unauthenticated user, for anonymous FTP, etc."  
"jdh" ENABLED SIMPLE AUTH_USER_NAME="jeff.hogg" BACKEND_USER_NAME="jeffh" 
DESCRIPTION="Jeff Hogg as self on Solaris"  
"proxyusers" ENABLED GROUP MEMBER_NAME="radius" MEMBER_NAME="jdh" 
DESCRIPTION="users allowed through FTP and telnet proxies" 
"radius" ENABLED SIMPLE RADIUS DESCRIPTION="default, external, non-specific RADIUS 
proxy_user" "securid" ENABLED SIMPLE SECURID DESCRIPTION="default, external, 
non-specific SecurID proxy_user" 

To display the names of all proxy user objects, while logged into the primary Screen:

admin% ssadm -r primary edit Initial
edit> proxyuser names,raw
"admin" 
"admin-group"  
"anonymous" 
"ftp" 
"radius" 
"securid" 
"jdh" 
"proxyusers"

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.)