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:
Authentication methods There are nine in total; cts-auth, ftp, http, jaas, jndi, local-hash (the default), none, and os-auth. See “Login methods” of Chapter 10, “Security Configuration Tasks” for a description of each.
SSL certificate-based authentication Alternatively, you can map a client certificate to a user using the bin/set-certificate script located in the EAServer directory. Then, if the client connects to an IIOPS or HTTPS listener configured for mutual authentication (for Web applications, the Web application must also be configured for CLIENT-CERT authentication) the certificate is mapped to a user name. In the IIOP case, if you use a certificate and provide a password, the password must also be correct. However you do not need to provide a password.
Using “keytool” to add client certificates
is not sufficient, only the bin/set-certificate script
configures the necessary certificate to user mapping (which is stored
in the “default” Security Domain properties file).
See Chapter 11, “Managing Keys and Certificates” for information about
using keytool commands and set-certificate.
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. Java applets and Java applications, C++, and PowerBuilder 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 those certificates. Use sctool.exe to manage the certificate database.
See “Configuring security profiles” for information about the various authentication levels you can establish for a client-EAServer connection.
Custom authentication You can code a service component 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.
EAServer provides a special user name, admin@system, for the EAServer Administrator login. Administrator authentication is performed independently of the authentication option you configure. By default, the admin@system user name has no password. Use the set-admin-password batch file located in the EAServer bin directory to establish the admin@system 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 admin@system password
and configuring the authentication mechanism of your choice. See “Administration
password and OS authentication” in the EAServer
System Administration Guide for more information.
For backwards compatibility, you can use “jagadmin” as an alias for “admin@system”. However by default you cannot have an empty password. To allow an empty password (which is not recommended) you must set the “minimum password length” property of the “default” Security Domain to “0”.
By default, the admin@system user name has no password. Use the set-admin-password batch file located in the EAServer bin subdirectory to establish the admin@system password, otherwise the server will not start.
The “admin@system” password must be the same for all members of a cluster.
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 7, “Creating and Using Custom Security Components.”
