Customized implementation of the Security API
JReport Server provides a set of Security APIs which you can implement in order to build your preferred security system. This section discusses the basic rules and implementation of the Security API.
Partial Implementation of the Security API
The Security API can meet various requirements for seamlessly integrating the JReport security system into an existing external security system.
By implementing all interfaces, you provide full functions to the JReport Server security system. However, if you do not want to provide a complete security system to your JReport Server, but only to use part of the functions available, you can achieve this by implementing the interfaces that meet your requirements.
Here are some examples:
Example 1
Requirements: You only want to customize authentication and authorization.
The following interfaces are required to be implemented:
- AuthenticationProvider
- AuthorizationProvider
Example 2
Requirements: You want to customize authentication and users, while the JReport Server maintains other functions of the security system.
The following interfaces are required to be implemented:
- AuthenticationProvider
- UserProvider
Example 3
Requirements: For CLS/RLS scenario, you must provide user/role information.
The following interfaces are required to be implemented:
- AuthenticationProvider
- UserProvider
- RoleProvider
- RoleUserRelationProvider
Implementing the Security API using an .xml file
You can specify a customized implementation of the Security API in a .xml file. The JReport Server loads classes according to this file.
The file is customizedAPI.xml in <install_root>\bin
. Specify the content in the .xml file as follows:
<?xml version="1.0" encoding="UTF-8"?>
<jreport-customized-api>
<security>
<authentication-provider>
com.customer.security.AuthenticationProviderImpl
</authentication-provider>
<authorization-provider>
com.customer.security.AuthorizationProviderImpl
</authorization-provider>
<user>
<provider>
com.customer.security.user.UserProviderImpl
</provider>
<permission-provider>
com.customer.security.user.UserPermissionProviderImpl
</permission-provider>
<privilege-provider>
com.customer.security.user.UserPrivilegeProviderImpl
</privilege-provider>
</user>
<group>
<provider>
com.customer.security.group.GroupProviderImpl
</provider>
<permission-provider>
com.customer.security.group.GroupPermissionProviderImpl
</permission-provider>
<privilege-provider>
com.customer.security.group.GroupPrivilegeProviderImpl
</privilege-provider>
</group>
<role>
<provider>
com.customer.security.role.RoleProviderImpl
</provider>
<permission-provider>
com.customer.security.role.RolePermissionProviderImpl
</permission-provider>
<privilege-provider>
com.customer.security.role.RolePrivilegeProviderImpl
</privilege-provider>
</role>
<relation>
<role-group>
com.customer.security.relation.RoleGroupRelationProviderImpl
</role-group>
<role-user>
com.customer.security.relation.RoleUserRelationProviderImpl
</role-user>
<group-user>
com.customer.security.relation.GroupUserRelationProviderImpl
</group-user>
</relation>
</security>
</jreport-customized-api>
|
Rules for applying customized Security API
The following are rules for applying customized Security API:
- AuthenticationProvider is a core interface and must be implemented. It is first loaded when JReport Server loads a customized Security API.
- There are dependency relationships among some interfaces:
Interfaces PermissionProvider and PrivilegeProvider depend on the corresponding principal interface provider. For example, the prerequisite for applying a customized UserPermissionProvider is that a customized UserProvider has been applied.
Interface RelationProvider depends on both the corresponding principal interfaces. For example, the prerequisite for applying a customized GroupUserRelationProvider is that a customized UserProvider and GroupProvider have been applied.
- If you partly implement the Security API, the JReport Server will automatically provide implementation of some missed but required interfaces, in order to build an integrated security system. Below are the rules:
- If customized implementations of Providers have not been applied, the JReport Server will apply built-in implementations of these Providers, including: AuthorizationProvider, UserProvider, GroupProvider, RoleProvider, GroupUserRelationProvider, RoleGroupRelationProvider, and RoleUserRelationProvider.
- If you have applied a PermissionProvider or PrivilegeProvider, but not applied an AuthorizationProvider, the JReport Server will apply the built-in implementation of the AuthorizationProvider.
- If you have applied an AuthorizationProvider, but not applied a PermissionProvider or PrivilegeProvider, for example, UserPermissionProvider or UserPrivilegeProvider, the JReport Server will not apply the built-in implementation of the PermissionProvider or PrivilegeProvider.
Notes:
- For details about the Security API, see the
jet.server.api.custom.security
package in the JReport Javadoc in
<install_root>\help\api
.
- Demo references available in
<install_root>\help\samples\APISecurity
:
- DemoAuthenticationProvider.java
Demo for implementation of the jet.server.api.custom.security.AuthenticationProvider interface.
- DemoAuthorizationProvider.java
Demo for implementation of the jet.server.api.custom.security.AuthorizationProvider interface.
- In V8, two new methods addSecurityListener() and isEnableEdit() are added into the API jet.server.api.custom.security.AuthenticationProvider. If you have upgraded your JReport Server from V7 to a higher version, and have applied customized implementation of AuthenticationProvider in V7, you need implement the new methods in the API.
- JReport Server provides the ability to use customized user authentication scheme by the implementation of the two interfaces jet.server.api.custom.security.AuthenticationProvider and jet.server.api.custom.security.AuthorizationProvider.