Title: Design of J2EE Universal Access Control System Based on WebLogic Security Framework
[comment]
Summary: A practical application system needs to focus on functional needs, and there is also a very important aspect of a lot of non-functional demand, security is a very important aspect. Access control is an indispensable part of almost all applications. Although the J2EE architecture provides a security mechanism to help the application achieve access control, it is too rough control granularity to make its use value is almost zero, and each application system has to develop its own access control module. However, each application system has many adverse effects separately using the access control modules of their respective development. This article will describe a J2EE universal access control module based on open WebLogic Security Framework, which can also improve the application speed of application system and reduce enterprises to waste in user management.
Directory: First, Background 2, Design Target III, System Design 1. Architecture Overview 2. Entity relationship 3. Design 4 of the application system interface layer. Design of management tools 5. Design of API layer 6. Design 7 of the data access layer. Data storage layer design four, insufficient and problem five, summary 6, reference documentation about the author
I. A conventional application system In addition to the need to focus on functional requirements, it is necessary to consider a lot of non-functional demand, security is one of the very important aspects. Access control is an indispensable part of almost all applications. Although the J2EE architecture provides a security mechanism to help the application achieve access control, it is too rough control granularity to make its use value is almost zero, and each application system has to develop its own access control module. However, each application system has many adverse effects separately using the access control modules of their respective development, 1. It is not conducive to the construction speed of the application system. Every development of a new system needs to revisit an access control module. 2. Not conducive to business centralized management of accounts and privileges. Each application system uses its respective access control modules to enable companies to maintain numerous user information, and on the one hand, information redundancy is caused, and the other hand is also difficult to maintain user information, bring hidden dangers for security. Therefore, it is necessary to create a universal access control module, which can also improve the application speed of the application system can also reduce the company's waste in user management.
Second, the design goal (directory) 1. Support user authentication and authorization, user information management. 2. Versatility. The module should be easily employed by different J2EE applications, making multiple systems to accomplish access control with the same set of user authentication and authorization mechanisms. 3. Centralized management is combined with grading management. All user information and access control related settings should be centrally controlled while allowing different levels of administrators to manage resources within their respective ranges. 4. Scalability. This module should be able to extend new access control properties. 5. Low invasive. With a declarative access control, there is no need to add an access control statement in the service code. However, for some local access control, programming access control is available. 6. Easy to use. This module should be easily understood and used by developers and managers.
Third, the system design (directory) 1. Architecture Overview In this universal access control module, the API layer (blue) is the core, which is responsible for querying data storage, responding to the application system interface layer (black) query and operation on access control information. Applications may also interact with the API layer by programming access control.
The application system interface layer (black) is provided to the application system. The application system uses this level of function to complete the access control of specific resources. At this level, some tools are also provided to manage and configure access control information for resources.
Data Access Layer (Pink) is responsible for accessing specific data storage, such as LDAP Server, Database, XML file, etc., you can plug in different data accessors at this level to accommodate different data storage forms. The data storage layer (green) is a physical carrier actually saved access control information.
2. Entity relationship (directory)
We divide the entities involved in an application system permission into three parts: resources, applications, and users. Resources are divided into functional resources and business resources, functional resources refer to a functional component of a certain business method such as a URL or EJB. Business resources are data or other objects operating in the application. A collection of all resource consigned a Domain constructed. In Domain, a collection of resource ACL (access control list) constitutes a Realm. An application can subscribe to a Realm resource to implement control of resource access.
The main body of the application part is Application, Vendor as an Application provider can be used to organize Application. Application can be divided into several modules, each module corresponds to a number of Actions, defining the ACL (access control list) on the resource (access control list) defines the demand relationship between the resource and the Action. The Role defined under Module is an organization mode of the action under this module.
The user part from Organization to Department to User is organized by the actual administrative division. Group is a supplementary logic division. The connection between User and Role is the specific implementation of RBAC (Role Based Access Control Based on Role Control). RBAC is an effective means to solve complex and variable enterprise rights management, which can reduce the complexity of permission management and can be flexibly customize and change security policies, which have good scalability. The connection between Role and Group is not a stable connection, which needs to be implemented via User, providing this role and group contact is to facilitate the equivalent of ROLE and revoke. Organization enables users and operations by subscribing to Application.
3. Application System Interface Layer Design (Contents) Traditional web applications Access control can be done by intercepting requests using the Servlet Filter. For web applications, this method is very good, but for non-Web resources, such as EJB, this way does not play a role.
For EJB, you can also use some kind of proxy way to access to implement access control, but this way has invasive application, and the application must explicitly use Proxy. The limitations of the above two ways are only the role of access control only. No access control is performed in a unified manner in a unified manner.
WebLogic Security Framework is an open, flexible security framework, in addition to applications in Web resources and EJB, you can also act on all J2EE resources such as JDBC Connection Pools, JMS Destinations, JNDI, and JCA Adapters. The most important thing is that it not only provides a unified security interface to the application, but also provides an expansion mechanism that allows you to customize your access control rules.
The architecture of WebLogic Security Framework is shown below (Source: BEA White Paper - Bea WebLogic Security Framework: Working with your security eco-system)
When accessing protected resources, WebLogic Security Framework will be activated, so our access control system can be enabled by defining protected resources in the deployment descriptor through standard J2EE security mechanism. For example, the statement as follows in Web.xml defines protect.jsp to be protected resources, and WebLogic Security Framework will be triggered when accessing this resource.
Of course, due to the use of its custom Security Provider, the Role-Name involved in these resource limits is just a dummy value, which will be ignored, and use the user defined in our data store corresponds to the Role correspondence. The login-error-page set in Web.xml will also be replaced according to the settings. When the verification fails, the user will see more customized information.
The following figure shows the authorization mechanism triggered when a user logs in. (Source: E-DOCS.BEA.com Developing Security Providers for WebLogic Server)
The following figure shows how a protected resource is interactive with WebLogic Security Framework, and how the Security Provider is acting.
(Source: E-DOCS.BEA.com Developing Security Providers for WebLogic Server)
Our own access control can be implemented by replacing WebLogic default Security Provider for custom Security Provider. In this system, it is basically able to meet the requirements of Authentication Provider and Authorization Provider.
4. The design (directory) of the management tool (directory) In addition to developing a separate application to manage all access control resources, WebLogic also provides a use of the Administration Console Extension mechanism, allowing us to embed the application into the console of WebLogic. Although it is indeed very Cool, it is not conducive to mandate hierarchical management, so a separate management tool is still necessary. 5. The design (catalog) of the API layer is in the API layer, in addition to the implementation of the real entity, it is necessary to design the API provided to the application system interface layer, including two parts, part of the API used to implement management, which is the increase of the physical classes, deletion. , change and query; another part of the API for user authentication and authorization, at least in this part of the need for the following API, AuthenticateManager.authenticateUser (String userNmae, String password): UserInfo for verifying the user's login AuthorizationManager.isProtectedResource (String resourceId) : Boolean is used to test whether the resource is required to access authorization AuthorizationManager.isaccessallowed (String ResourceId, String UserName): Boolean is used to test whether the resource can be accessed by the user
6. Data Access Layer Design (Directory) Data Access Layer must allow different data accessors to accommodate different data storage forms, which can use Bridge mode abstract factory model to achieve this.
Data management classes, such as UserInfOManager, get a specific AccessorFactory based on the external setpoint, such as LDAPAccessoryFactory, then use this specific LDAPACCESSORYFACTORY to create the corresponding Accessor to access physical storage.
7. Design (directory) of the data storage layer, although multiple storage methods can be used to save access control information, LDAP is undoubtedly the most suitable storage. Our design will provide an LDAP-based solution. A LDAP Server is embedded in WebLogic Server, but its function is too simple, does not support the extension of LDAP Schema, so we do not meet our needs. So here we will use a full-featured LDAP Server - SunOne Directory Server to express your design, of course you can transplant it to other LDAP Server, such as free OpenLDAP Server.
Create the following AttributedJrole DirectoryString MultivaluedJaction DirectoryString MultivaluedJsubscribedApp DirectoryString MultivaluedJsubscribedRealm DirectoryString
Create the following object classdjapplication parent top required attribute cn allowed attribute djsubscribedrealmdjappmodule parent top allowed attribute djrole, djactiondjdepartment parent organizationalunitdjdomain parent organizationalunitdjgroup parent organizationalunit attribute djroledjorganization parent organizationalunit allowed attribute djsubscribedappdjrealm parent top required attribute cndjresource parent top required attribute cn allowed attribute djactiondjuser parent inetorgperson allowed attribute DjroledJvendor Parent OrganizationalUnit This Schema can only meet the most basic needs, and can further expand the properties of each Object Class as needed.
The following figure is a Directory Information Tree created in SunOne Directory Server 5.2. The Object Class corresponding to each entry is labeled in the figure.
Fourth, insufficient and problem (directory) use WebLogic Security Framework to intercept the call to protected resources, the response received by the client side can only be issued by WebLogic Security Framework. When processing EJB call, if the authorization fails, the client is only available. Receive a java.rmi.accessException, we cannot give more clear information to prompt the client, which will hinder the functional extension of this permission control system. The user authentication section only supports the username and password, which may need to extend further to support more authentication methods. In addition, this system has not included auditing parts, and audit is also an important part of security management. In fact, WebLogic Security Framework also provides an extension of auditing and can be added when needed.
5. Summary (directory) WebLogic Security Framework provides powerful support for the achievement of such a general J2EE privilege management system before an unprecedented openness and flexibility. This article covers a corner of the iceberg, more powerful features still need to be excavated. Due to the relationship of time, it is not possible to complete a running system, just have some verification prototype, so it is temporarily unable to share a set of runoffs. Maybe in the near future, everyone will see an open source system based on this article.
6. Reference document (directory) [1] developing security provoders for WebLogic Server http://e-docs.bea.com/wls/docs81/dvspisec/index.html[2]bea WebLogic Security Framework http: // www. BEA.com/content/news_events/ White_papers / BEA_WL_SERVER_TECHSECURITY_WP.PDF
