Proxy User Authentication

The FTP, Telnet, and (optionally) HTTP proxies of SunScreen provides the ability to restrict access to users who can verify their authenticity.

User authentication mechanisms of SunScreen are described in detail in Chapter 9, Authentication. In this section, the discussion is prefaced by notes that pertain especially to how these user mechanisms are employed by the proxies.

The goals of user authentication within a proxy are to:

• Establish the authenticity of a proxy user

• Locate a rule that references that authenticated proxy user

A side-effect of establishing an authentic user is a collateral mapping to a backend user identity. This identity is a string that is supplied (by the FTP proxy) as the user of the backend server (for example, a user's userid on Solaris).

The second goal is achieved by the rule matching steps previously described. A rule that references the authentic proxy user itself, or that references a GROUP proxy user that contains an ENABLED member reference to that authentic proxy user, causes a successful user match.

Proxy Limitations

Proxy implementation has the following limitations:

• Proxies can only be used on Screens with at least one routing-mode interface.

• You cannot use proxies on Screens in an HA cluster.

Automatically-Saved Common Objects

The proxies use the following common objects:

• Authorized user

• Proxy user

• Jar hash

• Jar signature

Once these objects are added or edited, the change is stored immediately and cannot be reversed. The Save button in the administration GUI is greyed out to show that it is inactive. Although the changes made to these objects are saved immediately, they do not take effect until a policy is activated.