Package com.objectwave.appArch.security

Provide a unix style security that can very easily be added and removed from a system.

See:
Description

Interface Summary

Prototypes	This external definition of "Prototypes" is for VAJava only.
SecurityListener	By extending the prototypes, any implementer of this class can directly access constants like OWNER, WRITE, WORLD

Class Summary

SecurityController	Essentially, this is just a centralized class for registering security listeners.
SecuritySupport	If you wish to provide support for security checks, you can use this class.
SecurityType	Similar to Unix's o g w model.
UserType

Package com.objectwave.appArch.security Description

Provide a unix style security that can very easily be added and removed from a system. Security has many meanings to different people. Hence it is often diffucult to generalize security support for an application. Our security framework supports the plugging in of application specific security and provided a general mechanism for implementing security.

The framework's implementation is inspired by the event based mechanisms used in the JDK1.1 event model. There is a centralized object (SecurityController) that all security implmentations register with as SecurityListeners. When a secured action is to take place the application will query the SecurityController to determine if access is granted to perform the specified action. The result the check is a boolean value indicating if the user may or may not proceed with the requested action.

com.objectwave.appArch.security.SecurityController is our centralized object. It is with this object that all security listeners must register. Typically this is done with
SecurityController.getDefaultManager().addSecurityListener(aSecurList);

com.objectwave.appArch.security.SecurityListener is the interface used for each SecurityListener implementation. There is only one required method for a security listener.
public SecurityType getAccessRights(Object action, Object user);
The parameters to this method are Objects so a User or an Action can be anything specific to your security implementation. But wait, how does this one method support read, write, execute access, along with user, group, and world settings? That's why we have a SecurityType.

com.objectwave.appArch.security.SecurityType will be used to determine our ability to perform a given action. A security type defines access at three access methods. Read, Write, and Execute will be associated with the necessary user levels of User, Group, and World. A security type is assembled using the predefined security types representing the user levels and access methods. An Example:
OWNER.has(ALL).and(GROUP.has(READ));
This definition is saying that a user of "OWNER" has access to READ, WRITE, and EXECUTE functionallity. Additionally, a user of "GROUP" would have access to "READ" functionallity, but this same user would fail a security check on "WRITE" functionallity. A user of "WORLD" would have no rights what so ever.
Additionally, a security listener may, or may not, set the current user level. Some SecurityListeners may know that it should set the current user to be "GROUP" based off of a Logon value (or an entry in a file, or as a result of being an applet or an application, etc.....) but may decide not to contribute any other value other than the user value. This would be done by the following line.
SecurityType type = OWNER.has(NONE);
type.setUser(GROUP);
When the access is finally being check, the access will be at a user level of "GROUP".

Every SecurityListener can participate in every security check, however, it is more likely that many of the SecurityListener's will only participate in a few security checks. One SecurityListener may manage screen navigation, while another may protect access to particular data fields. When a SecurityListener is participating it will return a SecurityType as a result from the getAccessRights method call. These rights are 'or'ed with any rights granted by other security listeners, with the end result being the most rights granted by all security listeners, and user level being the highest order level. The default user is "WORLD", next is "GROUP", and finally is "OWNER". Another example:
We have three SecurityListeners. The first:
OWNER.has(ALL).and(GROUP.has(READ));
The Second
GROUP.has(NONE);
The Third
SecurityType type = WORLD.has(READ);
type.setUser(GROUP);

In this senario, the end security type would look like the following:
OWNER.has(ALL).and(GROUP.has(READ)).and(WORLD.has(READ));
The user level would be "GROUP". If the desired action was a write, the request would be denied. If it was a read, then the request would be granted.

In the event that not a single SecurityListener contributes to the security check, all access is granted. It is easy enough to change this simply by having one SecurityListener set access to NONE for every possible security check.