This chapter explains how to develop programs with the security system API to add user's own security features to user applications. For example, there is the registration Servlet (called "auto-registration") that automatically registers a new user to the JEUS security system by using an application.

Before developing a security service, application programmers should check whether the standard J2EE security model and the JEUS security services support the desired security features. Developing a program using the security API will decrease the compatibility between J2EE servers. It is recommended to use only the standard J2EE security interfaces to maintain the compatibility.

The security system API can be used to protect the JEUS system from malicious user code (Servlet or EJB) injections.

The security API can be used for user codes (Servlet or EJB) in the case when the Java security manager is used, or when the source code (Servlet, EJB) successfully logs in using the LoginService.login (Subject) method. In this case, the Subject is the subject of the user defined in the accounts.xml file in the target security domain and has the necessary JEUS Permission configured in the policies.xml file.

For more information about how to configure each file, refer to the following:

The following classes in the jeus.security.base package play an important role when working with the security system at the application programming level.

As well as the basic classes in the jeus.security.base package, the classes in the jeus.security.resource package also play an important role related to resources.

To communicate with the services that are the foundation of the security system, use the following SPI classes from the jeus.security.spi package.

The following shows how to develop a program with the security API.

// Login the CodeSubject so
    that security checks are // disabled (so that we can modify the Subject
    and Policy // stores) SecurityCommonService.loginCodeSubject(); // Make
    Subject with Principal “pete” Principal petePrincipal = new
    PrincipalImpl(“pete”); Subject pete = new Subject(petePrincipal); // Make
    password “petepw” for Subject “pete” PasswordFactory pf = new
    PasswordFactory(“petepw”); pete.getCredentialFactories().add(pf); // Add
    new Subject to the Subject store
    AuthenticationRepositoryService.addSubject(pete); // Make a new Policy
    Policy policy = new Policy(); // Make role “someRole” Role someRole = new
    RoleImpl(“someRole”); // Make a RolePermission for role “someRole”
    Permission rolePermission = new RolePermission(someRole); // Add the
    RolePermission for “someRole” to the Policy
    policy.getRolePolicy().addPermission( rolePermission, new Object[]
    {petePrincipal}, false, false); // Create a ResourcePermission for
    resource “rsc1” with actions // “action1” and “action2” Permission
    rscPermission = new ResourcePermission(“rsc1”, “action1,action2”); // Add
    the ResourcePermission to the Policy using // context id “ctx1”
    policy.getResourcePolicy(“ctx1”, true).addPermission( rscPermission, new
    Object[] {someRole}, false, false); // Add the new Policy to the Policy
    store AuthorizationRepositoryService.addPolicy(policy); // Logout the
    CodeSubject so that security checks are // enabled again
    SecurityCommonService.logout(); // Make a Subject to be logged in Subject
    pete2 = Subject.makeSubject(“pete”, “petepw”); // Login Subject “pete”
    (should succeed since we added // “pete” earlier)
    SecurityCommonService.loginDefault(pete2); // Check ResourcePermission
    “rsc1” for current Subject (“pete”) // Should succeed since we added
    Policy for this above SecurityCommonService.checkPermission( “ctx1”, new
    ResourcePermissin(“rsc1”, “action2”); // Print the name of the current
    Subject (“pete”) System.out.println(
    SecurityCommonService.getCurrentSubject().getPrincipal().getName()); //
    Logout “pete” SecurityCommonService.logout();