Extending Jaas
Guosheng Huang, PHD, IS A Seniorsoftware Developer WITHWYSDOM Inc. He Has over 15Years of Experience In Software Engineering and Technical Architecture. Gorsenhuang@yahoo.com
Translation: Green wildflower 2003/10
User authentication and access control are important security scales for most Java applications, especially J2EE applications. Java certification and permission service (ie JAAS), JAAS, J2SE 1.4, and 1.5 core APIs depict new security standards. It provides a pluggable and flexible framework (Flexible) framework (Flexible) allows developers to mix different security mechanisms and rich resources that have existence of various security.
With the release of the upcoming J2SE1.5 version, it contains many such as encryption technology, XML security, public key mechanism (PKI), Kerberos (is a network attachment system / protocol, allowing users to pass through a security server Services to verify ourselves. The services of the distal login, remote copy, system inter-mail copy and other high-risk tasks will become fairly safe and controlled.) And the Federating Identity is enhanced! JaaS will play a more important role in J2EE implementation.
Jaas aerial view
Certification
Certification is the process of checking a user with permissions that have been identified by the enterprise user registration agency. Jaa's certification mechanism is based on a set of pluggable modules (see Figure 1). JAAS allows different verification models to be swapped at runtime. Custom applications always interact with JaAs by logging in the context object.
The certification process is typically the steps to pass through:
1, generate a logincontext object. This logincontext looks for configuration files to decide to use that loginmodule. Similarly, you can choose to pass a CallbackHandler to LogInContext.
2. Perform authentication by calling LoginContext's Login method, which loads predefined loginmodule to verify that users can be authenticated.
3. If the user is authenticated, it is associated with the rules and identity and its items.
4, or ran a loginexception in the event of the landing failed
5. Use logincontext's logout method to log out
In JaaS, login is a two-stage (Two-Phase) process. The first phase is "login" phase (just as described above). The only task at this stage is to authenticate. As long as the processing process successfully passed this phase, the authentication process entered the "commit" phase (as follows 3), this phase LoginModule's commit method is called to associate the subkey related rules and identities.
One subkey in JaaS represents an authentication entity, such as a person or a device. It contains a complete set of rules and security-related properties such as passwords and encryption keys. In the JaAs architecture, the associated permissions of the subkey and their attachments play an important role in the certification process. Among all authentication modules, LoginModule is an excuse of the fact that the actual authentication mechanism. Although LoginModule has not received the opportunity to call customer application, he provides a specific type of authentication via a pluggable module, which implements the authentication algorithm and determines how the actual authentication process is executed.
Sun offers several default LoginModule implementations, in the sun.com.security.auth.module package, such as JNDiloginModule, Krb2LoginModule, UnixLoginModule, and NTLoginModule. Because the JAAS login structure system is scalable, you can almost all in any LoginModule module in the configuration file. As the following is an example of a configuration file:
Mysample {
com.sample.module.myloginmodule required debug = true;
}
Here MySample is the name of the login context. When you generate a new LogInContext, it will be incompatible in the constructor of LogInTex. According to the configuration block prompt, the text block reminds JaaS to be used to perform authentication during the login process. In addition, for loginmodule, any option regarding him can also be specified here. During the step of performing the steps of logging in, the CallbackHandler class is used by the LoginModule class to communicate with the user has facilitated authentication information. CallbackHandler class handles three types of callbacks: NameCallback, prompting users to enter a username; PasswordCallCack, prompt to enter a password; TextOutputCallback, report error, warning, or send some other information.
Authorize
Authorization is to determine whether the user can perform some actions, such as accessing a resource. Because JaAs is based on the existing Java security model, this process is based on the policy. The policy configuration file has essentially contains a series of portions such as "KeyStore" and / or "GRANT".
The GRANT entry contains all permissions, and he is granted by an authentication code or a law that can be securely sensitive, such as accessing a specific web page or a local file. JAAS supports the rule-based strategic entrance, the basic format of the entrance is as follows:
Grant CodeBase "CodeBase_URL" Signed "signer_name,"
Principal Principal_class_name "Principal_Name",
Principal Principal_class_name "Principal_Name",
... {
Permission permission_class_name "target_name", "action",
Permission permission_class_name "target_name", "action",
...
}
"Action" in the above format may be required or may be ignored to depend on the permissions type.
In the JAAS architecture, the policy object expresses a system security policy for a Java application environment and at any time in fact there is only one policy object. According to Java2 SDK documents, the default policy implementation is Sun.Security.Provider.PolicyFile, where the policy is specified in one or more policy configuration files.
As long as the user is authenticated, authorize the occurrence of the Subject.doas method, or from the Subject class's static method doasprivileged, the DOAS method uses the current AccessControlContext dynamic and child, and also calls the RUN method to perform the action, he leads to security verification. The permission verification process passes the following steps in Figure 2:
Just like LoginModule, the strategy is also a pluggable model. You can hang other policies implementation by changing "policy.provider = sun.security.provider.policyfile" to a policy class that you use in the Java.Provider = Sun.Security.Provider.PolicyFile.
Extend jaas
JAAS is built at the top of the existing Java security model, which is implemented based on "CODesource" and flat text format policy files. This may be insufficient to enterprise applications, you might want to use customizable security warehouses. For JaaS, such as LDAP (light directory access protocol), database or other file system, it can be done by writing your own customizable module, thanks to JaaS's pluggable features. However, this requires a perfect understanding of the process in the module and JaAs, and you have to do many coded to overwrite the associated classes, and handle both configurations and policies.
Ideally, we are willing to extend JAAS in a more easy way to make it only to develop and insert these different small hours whenever a customizable safety knowledge base or different access control mechanisms or different access control mechanisms. Modules (ie, adapters) adapt to these new changes and needs, and in the best case, do not understand and familiarize with the details of the JaAs processing process, we are also willing to do these changes only by changing a profile . Another goal is that our JaaS extension component can be used in different J2EE applications - independent or Web. Figure 3 depicts the design intent of the JAAS extension component. Our JaaS extension group takes advantage of the JAAS plug-in architecture when achieving customizable LoginModule and policy modules. In these modules, we delegate a data request to the adapter. Each of these adapters is isolated for simple tasks such as data retrieving, so you can quickly use different security knowledge or algorithms to develop different adapters instead of trying to implement different loginmodule or policy modules, they are more complicated and needed. More efforts.
You can come from www.sys-con.com/java/sourcec.cfm. Under complete source.
Authorized Authloginmodule class
The AuthloginModule class is our custom LoginModule implementation. The LoginModule class is a pluggable component in Jaas and serves two purposes:
1. Identification of certified users
2. If you certify your public, use the relevant person in charge or the certificate update theme.
LoginModule has 5 ways to implement, let us pay attention to the login () method. This method is called to authenticate the theme and make two things:
1, including username and password, typically, loginmodule to call the CallbackHandler class Handle method to get username and password
2, passing the comparison password in the data source. LoginModule Remove the user name and password from Callbacks. (It defaults to a sort of user interfaces), this is a simple demonstration or in the command line, but he is not practical for a J2EE application, for example, for most web applications, usernames and passwords. The relatively typical is read from an Form. In this case, it is difficult to use Jaas certification. Consider using LoginModule directly, the solution is to implement a customizable CallbackHandler class, and he will receive the username and password and then submit them to loginmodule, so he doesn't have to prompt the user to enter information.
The following example shows how user information passes from JSP or Servlet:
String UserName = Request.getParameter ("User");
String password = Request.getParameter ("password");
LoginContext CONTEXT = New LoginContext ("MySample", New AuthcallbackHandler (Username, Password);
Once the username and password are in the hand, the Authloginmodule class, our LoginModule class custom implementation is instantiated via loginsourceadapterfactory, and the actual authentication process to the resource adapter will be applied via loginsourceadapterfactory. The adapter is just a simple class that receives user information from a specific data adapter (such as a database or LDAP, or some other system). In the "Submit" phase, the AuthloginModule class retrieves the relevant information from the LoginsourceAdapter class and associates them with the topic.
LoginsourceAdapter class
The LoginsourceAdapter class is an interface of a resource adapter for authentication purposes, which has 4 methods that need to be implemented:
1, Void Initialize: The initialized method is called to initialize the adapter in the relevant parameter. This method is called immediately after the object is generated and is preferred in any call to other methods.
2, Boolean Authenticate (String UserName, CHAR [] Password): This authentication method is called to authenticate the user.
3. String [] getGroupnames: getGroupNames method is called to get the relevant main information after the authentication is successful.
4. Void Terminate (): This method is called after the LoginModule class is executed, which makes some cleaning work for the adapter.
Authpolicy class
Under the JaAs architecture, the security policy is processed by the Java.SecureTy.Policy class, which proves to assign a specific code source or a number of permissions. Just as discussed in the previous paragraph, Sun.secureTy.Provider.PolicyFile is its default implementation. PolicyFile class uses a flat text file to prove the correspondence between permissions and code sources, which may not be too good for enterprise-class applications. A focal system such as a relationship database that supports role-based security will be better. Obviously, extended JAAS authorization to handle different security tags of different sources, we need to write our own strategy implementation.
The steps to generate a custom strategy implementation are as follows:
• Expand the java.secureTy.Policy class
• Implement getPermissions () method
• Implement the refresh () method.
If you see the implementation of our custom policy class, you may notice our AuthPolicy class derived in sun.security.provider.policyfile instead of java.security.policy. Why? First, I want to implement the AuthPolicy class as a generic POLICY class, which can handle the default policy class does not need to be intervene in any adapter. By from the PolicyFile class, we do not need to implement policy file resolution and other related code. At the same time, if the party application runs in a safe manager, some permissions, such as the DOASPRIVILEGED AUTHPERMISION class, and the FILEPERMISSION (in order to load the configuration file), need to be empower to perform JAAs.
Of course, these permissions can be stored in the data source, but they may be more advantageous in placing them in a standard Java security policy file. However, for regular development, you should implement an adapter to cope with these things. The same design mode is followed when expanding authentication. Our strategy entrusted permission request
PermisssionAdapter class.
In the authority class, different permissions are saved in their own PermissionCollection class instance. If you create a custom permission class, you need to generate your own PermissionCollection class type, otherwise you cannot guarantee that your permissions will be referred to confirmation. PermissionAdapter class
The PermissionAdapter class is an interface for the authentication process pluggable module in our JaaS extension component. It evaluates policies from a specific data source and distributes a PERMISSIONCOLECTION class that contains a set of permissions that has been given. The PermissionAdapter class interface has the following method:
• Void Initialize: The initialize method is called to initialize the adapter with the relevant parameter. This method is immediately called and is preferred in any other method. At the same time, it will also be called after the refresh method of the Policy class.
• Permissioncollection getPermissions (ProtectionDomain
Domain: This method will be called as long as some subject permissions are requested.
As an example, let's see how to implement a role-based PermissionAdapter class. Suppose there are three roles: administrators, users, and guests have different permissions, and all permissions information is stored in the database.
First, in the Initialize method, we will get all roles of rights information from the data and assemble into a collection class, such as HashTable. Next, in the getPerMissions method, we will collect rights related to the relevant subjects (this is only Some will involve role-based access controls and returns them. Note that we can get the relevant subject by calling the GetPrincipals method for the ProtectedDomain class. It is so simple, isn't it?
Jaasutil class
For our JaaS extension component JaaSUTIL class is the primary link, and it has a constructor to get the username and password. There are two key ways:
1. Boolean Authenticate ()
2. Boolean Checkpermission (Subject Subject, Final Permission Perm)
The JaAsutil class actually delays the login request for the LoginContext class and the permission check step for the SecurityManager class. Listing 1 shows how to use the JaAsUtil class. This code first acquires username and password from the HTTTPServletRequest class and try to authenticate users. Then it detects whether the user has permission to access "EditReg.jsp".
Configure
Now we have our own custom LoginModule, Policy and other related modules. These modules can entrust relevant data requests to the appropriate adapter; this is a good thing. However, in the JAAS structure, the LoginModule class and the Policy class will never be called directly by the application, so how do we know that the adapter should be firm and how to transfer the required parameters or information, such as data connection, give the adapter? The answer is that the adapter can be dynamically configured by updating an XML configuration file. This XML configuration file consists of two main data segments:
1,
2,
You can develop which LoginsourceAdapter class and PermissionAdapter classes that use it. It is also possible to deliver additional information in the configuration file. Let the Jaasutil class know that there are two ways to find a configuration file:
1. Develop a configuration file via the command line attribute switch: -dcon.auth.config2, call the JaaSutil.SetConfigfile (configfile) method.
This custom security policy class file must be added to the Java JRE / LIB directory when you deploy JAAS extension components, which will cause policy class files to load their load by the Bootstrap class. Otherwise, even if you place the policy file in your Java classpath, it will not be checked out and the SUN defaults the policy class provided will be replaced.
to sum up
Extending Jaas is not difficult. The JAAS structure is provided to customize the flexibility of implementing authentication and authorization processes. Understanding how these processes work is to know how to replace your own implementation. In this article, we revisit JaaS foundation and check how to extend JAAS to make a framework that makes a more dynamic, flexible, and scale-up feature. With this expansion framework, you can easily generate your own login and access control mechanisms to support your own enterprise level security needs, you can also support emerging security standards, or balance your existing or custom security model as an adapter, then Hot swaps them into Jaas. This should be able to give your business app to provide a standard-based highly customized authentication and authorization process.
References
• Jaas Reference Guide for the Java 2 SDK, Standard Edition,
v 1.4: http://java.sun.com/j2se/
1.4.1
/ DOCS / Guide / Security /
Jaas / jaasrefguide.html # policy
• Jaas LoginModule Developer Guide:
http://java.sun.com/j2se/
1.4.1
/ DOCS / Guide / Security / JaaS /
Jaaslmdevguide.html # login
• LAI, C., ET Al. "User Authentication and Authorization in
Java Platform. "Proceedings of the 15th Annual Computer
Security Application Conference,
Phoenix
AZ. DecEmber
1999: http://java.sun.com/security/jaas/doc/acsac.html
• Sun Microsystems, Inc. "Default Policy Implementation
And Policy File Syntax. "Technical Report:
http://java.sun.com/j2se/
1.4.1
/ DOCS / Guide / Security / Policy
FILES.HTML
