The authentication model described is only an authentication that the client application is allowed to create a Domain Manager client session via RMI and, through this session, gain access to the Domain Manager's RMI Controller APIs. The model also includes continual validation of the authenticated session through transaction verification. It does NOT authenticate the user name other than insuring it is a valid user defined in the database. The user name must have been previously authenticated using the native operating system login authentication by the client application.
Access to the RMI Controller APIs is limited to clients running on the same system as
the Insight Systems Manager Central Managment Server (CMS). This access is protected
by a secure RMI interface. The local mx.properties
file contains
properties defining the hostname and port number where the RMI registry is
running. The Domain Manager process is bootstrapped via the MxSecureRMIImpl
class to initialize the individual managers, controllers, and database access and to
register a single "SecureRMI" service with the RMI registry. This service provides
only a single public method, "getSessionMgrIfc()
", used to retrieve
a client session interface through a signed request. The returned MxSessionManagerIfc
instance provides the methods to get the client session object, MxClientSession
, and
get any of the RMI Controller API interfaces. The client session object is required in order to
retrieve the MxTransaction
instances required to get the RMI Controller API interfaces and
to call the RMI Controller API methods. A new transaction object is required for each method call.
The RMI Controller APIs in the "com.hp.mx.core.controllers
" package use the
Session Manager interface to provide access the RMI Controller APIs. Each RMI Controller class
must have a "get
" method defined and implemented in the MxSessionManagerIfc
interface class and the MxSessionManagerImpl
implementation class.
The RMI Client APIs in the "com.hp.mx.core.client
" package use the Session Manager
interface to start a client session and access the RMI Controller APIs. A request for the remote
Session Manager interface must be correctly signed by the client using the CMS private key and will be
authenticated by the MxSecureRMIImpl
code using the CMS private key before returning an
interface for a remote Session Manager instance.
The client provides the user name to open a session as, the current date and
time stamp, a message digest created by using the hash of the using the user name and the current date
and time stamp as the data encrypted with the CMS private key, and a Locale
describing the preferred language to use for all text output to the client session.
The authentication process can be a full encrypted message digest comparison
or a simple lite authentication that verifies the remote request is coming from
the same host that the Domain Manager is running on. This is
controlled by a global property installed in the mx.properties
file.
By default, full encrypted message digest comparison is done.
The steps for authenticating a client session request:
SecureRMI
" service
verifies the message digest using the provided user name and date+time stamp by using the CMS public key.With the Session Manager interface the client can: get the Client Session object associated with the requested user session, access the controller interfaces which provide access to all the functionality available to the client, and close the session.
Every method call by the client is authenticated in the Domain Manager by requiring a transaction object to accompany it. The Client Session object is used to get each transaction object required for the next method call. The transaction objects contain information that identifies the session user making the method call and sequencing data to insure the transaction came from the same client session. This sequencing data is randomly initialized on the first request for the Client Session object and cannot be reset or changed. So, once the first transaction object has been requested and used to make a method call the client application must continue to use that instance of the Client Session for all future transaction requests. Any attempt to get a new client session object will result in transaction sequencing data that will fail to be authenticated by the Domain Manager.
There is also a time out associated with a Client Session. If no transactions occur on a Client Session for a period of 2 minutes (configurable with a global property) the session lease will expire and the next transaction will throw an exception.
The classes which implement the RMI Client APIs being provided for client applications will
hide the entire RMI authentication process described here. The authentication complexity
will be implemented internally by the local MxClientSessionImpl
client class.
And, the classes derived from the MxClientImpl
base class will completely hide the
transaction authentication model described here.
NOTE: In order to do the message digest authentication the client application executable (which bootstraps the client JVM) must have the set UID bit set or the JVM process must be executing as root. This is required in order to read the private key file on the CMS.