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 apish 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, EJB, etc) 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.

Refer to the following to learn how to configure each file

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();