Client authentication

Users are authenticated when a client application creates a proxy or stub object (a connection is made when the application creates the first proxy or stub; other proxies or stubs may use the same connections or allocate new connections as needed).

Authentication options for base clients include:

No authentication No user name/password authentication of session user names is performed. This is the default configuration for new servers.

Native operating system authentication User names for an EAServer connection map directly to a login name on the host operating system. For example, for UNIX, you would use network information service (NIS) passwords, and for Windows, you would use your Windows domain password. See “Configuring OS authentication” for more information. You can enable native authentication with EAServer Manager using the server’s property sheet.

SSL certificate-based authentication You can configure a secure IIOP port that requires mutual (client and server) authentication. Clients must have a valid SSL certificate to connect to this port, and the certificate must be issued by a certificate authority that is trusted by EAServer.

When clients connect with an SSL client-side certificate, the client also supplies an EAServer user name and password for the connection in addition to the certificate. EAServer performs authorization checking based on the EAServer user name. The SSL user name and certificate information are available through the built-in CtsSecurity/SessionInfo component.

EAServer provides native SSL support without the use of proxies. On the client side, the EAServer Java ORB supports SSL when run in Netscape 4.0. Java applets and Java applications, C++, PowerBuilder, and ActiveX components can use SSL natively. Other types of clients require the use of an SSL proxy.

C++ and PowerBuilder clients require that a public-key infrastructure (PKI) system be available on the client to manage digital certificates. You can use EAServer Manager, which manages EAServer’s certificate database, or you can use Entrust/Entelligence, available separately from Entrust Technologies .

See “Configuring security profiles” for information about the various authentication levels you can establish for a client-EAServer connection. See Chapter 15, “Entrust PKI Integration” for Entrust information.

Custom authentication You can code a service component to be installed in EAServer to perform your own authentication checks. For example, you can retrieve the client user name and password and check to see if they allow a login to a remote database server. See “User installed authentication services” for more information.

Quality of protection EAServer 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. See “Quality of protection” for more information.

EAServer provides a special user name, jagadmin, for the Jaguar Administrator login. Administrator authentication is performed independently of the authentication option you configure. By default, the “jagadmin” user name has no password.

Set the administrator password for new servers Immediately after you create a new server, you must secure access to the server by defining the jagadmin password and configuring the authentication mechanism of your choice. See “Administration password and OS authentication” in the EAServer System Administration Guide for more information.

User installed authentication services You can install your own service component to authenticate clients for any EAServer. For example, if you require the client user name to match a remote database user name, you can code the component to retrieve the client user name and password and attempt to log in to the remote database. For more information, see Chapter 10, “Creating and Using Custom Security Components.”