web server - Borland Technical Publications

System Contracts
Security Management
In compliance with the Connectors 1.0 specification, VisiConnect supports both
container-managed and component-managed sign-on. At runtime, VisiConnect
determines the selected sign-on mechanism based on information specified in
deployment descriptor of the invoking component. If VisiConnect is unable to
determine the sign-on mechanism requested by the component (most often due to an
improper JNDI lookup of the Resource Adapter connection factory), VisiConnect will
attempt container-managed sign-on. If the component has specified explicit security
information, this will be presented in the call to obtain the connection, even in the case
of container-managed sign-on.
Component-Managed Sign-on
When employing component-managed sign-on, the component provides all the
required security information - most commonly a username and a password - when
requesting to obtain a connection to an EIS. The application server provides no
additional security processing other than to pass the security information along on the
request for the connection. The Resource Adapter uses the component-provided
security information to perform EIS sign-on in an implementation-specific manner.
Container-Managed Sign-on
When employing container-managed sign-on, the component does not present any
security information, and the container must determine the necessary sign-on
information, providing this information to the Resource Adapter in the request to obtain
a connection. The container must determine an appropriate resource principal and
provide this resource principal information to the Resource Adapter in the form of a
Java Authentication and Authorization Service (JAAS) Subject object.
EIS-Managed Sign-on
When employing EIS-managed sign-on, the Resource Adapter internally obtains all of
its EIS connections with a pre-configured, hard-coded set of security information. In
this scenario the Resource Adapter does not depend upon the security information
passed to it in the invoking component's requests for new connections.
Authentication Mechanisms
Borland Enterprise Server user must be authenticated whenever they request access
to a protected Borland Enterprise Server resource. For this reason, each user is
required to provide a credential (a username/password pair or a digital certificate) to
Borland Enterprise Server. The following types of authentication mechanisms are
supported by Borland Enterprise Server:
■
■
■
Password authentication a user ID and password are requested from the user and
sent to Borland Enterprise Server in clear text. Borland Enterprise Server checks the
information and if it is trustworthy, grants access to the protected resource.
The SSL (or HTTPS) protocol can be used to provide an additional level of security
to password authentication. Because the SSL protocol encrypts the data transferred
between the client and Borland Enterprise Server, the user ID and password of the
user do not flow in the clear. Therefore, Borland Enterprise Server can authenticate
the user without compromising the confidentiality of the user's ID and password.
Certificate authentication: when an SSL or HTTPS client request is initiated, Borland
Enterprise Server responds by presenting its digital certificate to the client. The
client then verifies the digital certificate and an SSL connection is established. The
CertAuthenticator class then extracts data from the client's digital certificate to
determine which Borland Enterprise Server User owns the certificate and then
retrieves the authenticated User from the Borland Enterprise Server security realm.
250 BES Developer’s Guide