Tymeac ships with login security suppressed. Security is a touchy subject.
It also requires an in-depth knowledge of Java based SSL security. The Java
API has a section (.../docs/guide/security/index.html) on how Java security is
set up and how to use it.
If you are not interested in SSL security, skip the next section, SSL, and
go to Tymeac Basic Security.
SSL
We supply KeyStores, a Trust Store and the certificates used to create the trust store,
pass word files and login configurations just to get you up and running for SSL
security. You naturally must set up your own files in accordance with your needs
(including Kerberos). The supplied files are:
KeyStores:
tymeacclient.keystore - password is tyclient
tymeacserver.keystore - password is tyserver
tymeacreggie.keystore - password is tyreggie
tymeacphoenix.keystore - password is typhoenix
TrustStore:
tymeac.truststore - password is tytrust
SelfCertificates exported from the above KeyStores:
tymeacclient.cer
tymeacserver.cer
tymeacreggie.cere
tymeacphoenix.cer
Un-encrypted Password files for the above:
tymeacclient.password - password is tyclient
tymeacserver.password - password is tyserver
tymeacreggie.password - password is tyreggie
tymeacphoenix.password - password is typhoenix
Login configurations:
tymeac-ssl-server.login
tymeac-jini-ssl-server.login
tymeac-ssl-client.login
tymeac-jini-ssl-client.login
To turn on login security:
- For the RMI, CSF and IIOP Servers --
- StandAlone Mode -- use the TymeacUserVariables GUI or
enter the login context String "com.tymeac.TymeacServer" in the
TymeacUserVariables Class (and recompile.)
- DBMS Mode -- use the Tymeac ConfigurationData
(java.util.prefs.Preferences or GUI.)
- For the non-jini Clients -- enter the String "com.tymeac.TymeacClient" in the
Class
com.tymeac.client.ClientSecurityModule
- // put your login context here
private static final String myContext = "com.tymeac.TymeacClient";
- For the Jini Servers and Clients -- edit the configuration files (.config) in the config
directory and
for the Servers, remove the comment characters /* */
/* loginContext = new
LoginContext("com.tymeac.TymeacServer"); */
for the Clients, remove the comment characters /* */
/* loginContext = new
LoginContext("com.tymeac.TymeacClient"); */
As noted below in issues, Tymeac uses only basic security
methods. There is a login for the Server but no logout. Each Client GUI/Non-GUI button
access requires a separate login and there is no logout.
To alter the base security environment you may alter the security modules Tymeac uses
for Servers and Clients by putting your own code in the security modules and recompiling.
com.tymeac.base.ServerSecurityModule
com.tymeac.client.ClientSecurityModule
com.tymeac.jini.base.JiniSecurityModule
For the demonstration system:
com.tymeac.demo.SecurityModule
Server Side LoginContext
You may specify a login context in the Tymeac Cfg file (when
using a DBMS) or in the User Classes (when using the
stand alone mode). We ship the product with a login context suppressed in the User Class
as: com.tymeac.TymeacServer. The login configurations are as below.
The Jini modules use a net.jini.config.Configuration file in place of the above.
You may alter this before running the application.
When Tymeac finds a non-null login context String, it tries to login. You must specify
the authorization within the Java properties.
-Djava.security.auth.login.config=config\tymeac-ssl-server.login
-Djavax.net.ssl.trustStore=config\tymeac.truststore
We supply a basic ssl login in file tymeac-ssl-server.login (The clients are the same
with the word "client" in place of "server".)
com.tymeac.TymeacServer {
com.sun.security.auth.module.KeyStoreLoginModule required
keyStoreAlias="tymeacserver"
keyStoreURL="file:config/tymeacserver.keystore"
keyStorePasswordURL="file:config/tymeacserver.password";
};
Client Side LoginContext
The client is outside the scope of the package. How one protects against outsiders is
beyond what we can know. We provide examples in the com.tymeac.demo and
com.tymeac.jini.client directories for accessing Tymeac Server with security. See the note above for turning on login checking.
They use a command line option: -secure to initiate login and require
the same Java properties as for the Server Side. The login for clients requires a password
response to a pop-up Dialog box. The password is: tyclient as mentioned above in the
KeyStore section.
The Jini modules use a net.jini.config.Configuration file in place of the above.
You may alter this at run time.
Just to demonstrate this, we ship the shut down script for Tymeac Server with a command
line including -secure.
Tymeac Basic Security
- Tymeac Server security options are compatible with SDK1.4.2 +
- Tymeac Server only loads local classes with a findSystemClass() or a URLClassLoader.
- The notification system and user classes doing
recursion, within the Tymeac Server, act as a Tymeac Clients. This can be
an interesting situation if part of the Server needs to use Client
parameters.
- We supply SSL login security
- We do not supply Kerberos login security.
For the RMI Registry invocation, the Tymeac Server attempts to
load the class: TyServerRMISecMgr. This class is in the Processing
Application Class (com.tymeac.serveruser) directory.
Two exceptions are caught:
- Exception: The exception message prints/logs and Tymeac Server
aborts the start up.
- java.lang.ClassNotFoundException: The exception message
prints/logs and Tymeac Server continues the start up.
This means that you may eliminate the TyServerRMISecMgr.class file from the Server-User directory and Tymeac Server continues.
However, no security manager is in effect.
You set the security requirements for your installation. We supply the source code for the TyServerRMISecMgr class. You may code
this in any way you wish.
For Tymeac Installation Verification, we supply a "grant all permissions"
policy file in the Security directory.
One simple way to login to the RMI Server is by using a front end login
remote object.
The RMI Server builds it's regular remote object and exports
it to the run time. The RMI Server also builds a login remote object that
implements a simple interface with one method: login(). The RMI Server binds
that remote object to the RMI Registry. When a client retrieves the remote
object using the standard name, the client gets the login remote object. The
client sends login information to the login method of the Server. If the
Server approves, the server then returns the regular remote object to the
client. The client then communicates normally with the Server. This bypasses
the problem, raised above in basic security, item 3, of recursive calls to
Tymeac.
That sounds simple enough, but the set up is a little complicated. We
provide a demonstration.
A major issue is how to secure resources on the Server from unauthorized access by a
Client. This is an issue only you can resolve. There are many options. One is to have each
Client pass a "Subject Object" to the Processing Application Class and have that
class authorize the request. Another is JERI (Jini Extensible Remote Invocation) where you
intercept the request at one of the Client or Server levels (invocation
handler/dispatcher, etc.)
The second big issue is the reverse of the secure Server; how to protect the Client.
Once again, this is an issue only you can resolve. JERI is leading the way.
The following is a list of Tymeac features as they relate to security: