There are all kinds of scenarios on using JReport solution. However, they can all be categorized into two types according to the location of the JReport Enterprise Server instance:
In this scenario, the application includes JReport Enterprise Server JAR files into the same JVM, and it also includes JReport built-in servlets and JSPs which handle DHTML and other reporting services, for example, scheduling report sets.
Description of the illustration
In this scenario, the client (HTTP client) most of time will send a request to the portal, JSP or Servlet of the web application, and the web application can either call the public server API to the server instance directly to run a report set and output a report set result to file system, or it can re-direct the request to the JReport services provided by the JReport JSPs and Servlets, for example the DHTML JSP and Servlet. JReport JSPs/Servlets will first make sure the request is authenticated and authorized. After which, it will call the internal API method against the JReport Enterprise Server Instance in the same JVM to fulfill the requirement and return suitable information to the client via JSPs or internally generated output steam.
In the illustration above, you can see that the HTTP client can send a request directly to the application JSP/Servlets or JReport JSPs/Servlets. Before a response is made by the JReport JSP and Servlet, an Auth Check is performed to authenticate the session and then authorize the action. Normally, the built-in authenticator and authorization instance of JReport Enterprise Server (Instance) is called to perform these checking actions. However, if the application wants to control the process, the web application developer can set up the configuration to ensure that the customized authenticator and authorization instance is used instead.
Pay attention to the RED box: External Authorized instance. This Java class implements JReport jet.server.api.http.HttpExternalAuthorized to provide the authenticated user ID from the session. If this Instance returns a user ID, JReport will pass it to its authenticator to check if it is valid. If the user ID is valid for JReport, JReport will qualify the session of the request, and will not ask for a login again. If this external authorized instance does not return a user ID, JReport will respond the request by asking for a login.
The other RED box - Authenticator and Authorizer instance, can be provided by implementing two other interfaces:
jet.server.api.custom.security.AuthenticationProvider and jet.server.api.custom.security.AuthorizationProvider.
The AuthenticationProvider is used to authenticate the user ID, including whether or not the user ID is valid. The AuthorizationProvider is used to check the privileges of the user against the action that the user requests.
During the auth check process, if the external authorized instance returns a user ID of the session, JReport auth check will continue to send the user ID to the AuthenticatorProvider to check if it is valid or not. If the user is valid, the auth check will qualify the session of the request, and then continue to check if the action is valid for the user by asking the AuthorizationProvider instance.
In general, there is an authentication callback via the implemented interface of External Authorized. Two security check providers can be implemented to seamlessly integrate JReport security into the application.
From the web application itself, the architecture is not changed. However, the way that it uses the JReport solution is different since the JReport Enterprise Server Instance is outside of the Web application server. Inside of the Web Application, the instance is RMI server being called by the web application server or JReport built-in JSP/Servlets for the RMI solution.