In the JEUS security system, a login process is simply associating a Subject with an execution thread (Java thread). This concept is thus different from the concept of authentication. In general, authentication occurs before the Subject is associated with an execution thread. If the authentication is successful, login will proceed as normal, but if the authentication fails, login will also fail.

After a Subject has logged in successfully, all authorization will be performed with respect to this Subject. The login concept may thus be seen as an umbrella that spans both authentication and authorization. The opposite of the login operation is the logout operation, which disassociates the current Subject from the execution thread.

Note that the implementation of the login concept requires a stack-based operation. Several Subjects can be logged in at any time with each new Subject being pushed onto the top of the stack. Only the Subject on top of the stack is used for authorization. When the Subject logs out, the top Subject is simply removed from the stack, and the next Subject at the top of the stack is activated.

This mechanism is shown in the following.

In the JEUS security system, identities are always represented as principals that are defined by the java.security.Principal interface.

The following is a UML diagram for a JEUS Subject.

Authorization happens at the system level by, for example, allowing only certain Subjects (usually administrators) to boot or shut down the JEUS server. Authorization also happens at the application level when a JEUS engine checks whether a remote caller should be allowed to access a particular application component, such as a specific EJB method or a certain Servlet.

The role R may have permission to access the resource JNDI and execute the lookup action.

These concepts are illustrated in the following figure.

Moreover, apart from the basic Permission-based mappings, every Permission in the authorization system belongs to one of the following three categories.

A few examples to illustrate these ideas will be shown later.

Each PermissionMap contains the 3 aforementioned Permission types, excluded, unchecked and checked permissions. In the case of checked permissions, Permission and role PermissionMap are combined through a principal or Role. Policy and Resource PermissionMap are combined through a context id, which indicates the authorization scope.

All the information is summarized in the following figure.

The elliptical bubbles inside the boxes represent the actual Permission instances (Name: Action) with Name and Action variables.

Assuming that a Subject, with context ID A and the principal user1, wants to access JNDI to perform the action "modify", will user1 be able to perform this action?

The authorization system (actually the Policy implementation) would process this authorization query as follows:

In this process, although user1 is mapped to the role Administrator, since Administrator is also in the excluded set, no one (not even user1) will be in the role Administrator. This is because excluded Permissions have higher precedence over both unchecked and checked Permissions.

Using the previous figure and following the step-by-step instructions above, you should be able to work out the following authorization queries.

The JEUS security system features a simple yet flexible auditing mechanism using security events. Whenever something significant happens in the system, such as a failed authentication, a failed authorization, or something else that may be of interest, an Event will be posted to a set of registered event handlers.

The handler implementations, which may be fully customized, responds with an appropriate action, such as locking a Subject's credential in case authentication failed too many times in a row.

All instances of Services in the security system are treated individually as independent entities whose services are called as needed. However, it is also quite common for a Service implementation to make calls to another SPI, and some dependency may exist among different Services. In order to initialize Services. All Services receives a key–value pair property value used to initialize the Service. The configuration data of a Service can also be saved in a configuration file.

All Services may also optionally define a JMX bean that will be exported to the JEUS management system. The JMX MBean is normally created based on a MBeanInfo instance returned by the Service.getMBeanInfo() method.

All Services have two states, created state and destroyed state. The create() and destroy() methods are called to transition between the two states. Calling these methods will invoke doCreate() and doDestroy() abstract methods. These abstract methods should be implemented by Service sub-classes for service initialization and management.

For example, the JEUS server could be set up to use a special domain. In this case, it's call the SYSTEM_DOMAIN. This domain contains Subjects and Policies that are used to manage the JEUS server. For example, the SYSTEM_DOMAIN contains the user information for a main Subject called administrator, which can be used to boot or shut down the server.

Another domain, let's call it APP_DOMAIN, could be used by a deployed J2EE application. That domain might also contain a user information for a Subject called administrator, which is different from the JEUS server administrator. You could also configure a different repository mechanism for each domain. While the SYSTEM_DOMAIN can be configured to use a simple XML file to store Subject information, the APP_DOMAIN can be configured to use a remote database to read and write Subject information.

The domain concept is illustrated in the following figure.