|
|
|
JoshuaBranch AS - Features
|
|
General
|
|
JoshuaBranch AS (JB-AS) provides the primary features applications need to enable
user authentication and access control in an application. Out-of-the-box, you
have common requirements met such as role-based security, an easy to use web
front-end for security administration, and simple integration with applications.
This allows you to develop your business requirements in your applications while JB-AS
takes care of the complexity of user application security for you.
|
Features of JB-AS include:
- Rapid application development. Since JB-AS includes the components necessary
to implement user application security, the cost of developing user security in
your applications using it is a tiny fraction of a custom in-house solution.
Integrating new applications can take a day or so instead of weeks of development time.
- Role based security. A role is a named set of privileges. Roles privide an
easy way to group privileges in ways where you are likely to assign the
group as a whole to users. For example, you may have privileges for
creating and viewing individual reports. You can create a role that
gives a user the ability to view a group of reports and
grant the role to any of your users.
- Centralized application security. One JB-AS server installation can
provide user application security
service to an unlimited number of applications. User's have access to
any application where they are granted a role, since each role belongs
to an application. This also means that a single user account can access
multiple applications with the same user ID and password. If the user changes
the password, it changes for all the applications. You can administrate users
and their privileges via a single web administration console for all applications
using the same JB-AS server instance.
- Web administration console. The security administrator can manage user
access to applications via an easy to use web browser interface.
- Simplified application integration. JB-AS was created from the ground
up to simplify the coding necessary to integrate JB-AS with any of
your custom in-house applications. This allows developers to spend
their time on developing business functionality instead of developing
application security logic.
- Caching. JB-AS has caching features both in the components that integrate
with your J2EE applications as well as in the central service itself. This
minimizes database access, ensuring high performance for your applications.
Caching is automatic, so developers don't need to write any code
to use it.
- Unlimited privilege granularity. You define the data and actions you want to assign
privileges for as Application Modules. There is no limit to what you define
as a module, since JB-AS only uses the names you give it. This means
you can define privileges on as high or low of a conceptual level you need,
controlling access to just about anything with JB-AS.
- User IP logging. JB-AS stores the IP address the user logged in from, which can
be used to help prevent session hijacking, limit login locations, or detect unauthorized
access.
|
|
Administration
|
The easy to use administration client (JB-AS Administrator) includes many features
to empower the Security Administrator (SA):
- Web-based front-end. You can access JB-AS Administrator from any web browser in your network. No
need to install client software or create a security administration interface for your
each of your applications.
- Dynamic security. You can dynamically define users, user roles and
role privileges. Applications never directly reference roles or individual
users, so the SA can define them and their
relationships without having to coordinate with the development team.
JB-AS stores this data in a database, so Java code is never written against it.
The only information the JB-AS Administrator user coordinates with JB-AS Client application development
is the
name of the Application and security Application Modules, which are names you
give to
individual business concepts you will be granting privileges for to users (e.g.,
"customer data" and "invoice data" could be two application modules.)
- Unlimitted applications. You can administrate application
security for an unlimitted number of applications via your
JB-AS Administrator console. This permits
you to centralize application security for all the applications
in your enterprise, or select groups of applications to be
administered together. This consolidates your user lists, since
you can give a single user access to any of your JB-AS powered applications.
- Password policy. Define your corporate password policy, and
JB-AS will require users to conform whenever they change their password.
This includes the ability to set the required minimum length and
the use of numbers or special characters. You can also prevent users from
using their Login ID as their password.
- Remote JB-AS deploy. You can deploy the administration client into any J2EE server, or use
the default install which includes it where you install JB-AS. Like your applications,
JB-AS Administrator has the ability to connect remotely to JB-AS over the network.
- Drop down filters. You can limit the data you see on the screen
at any given moment. This permits the SA to focus on a single application,
for instance, even though the screens have the ability to display information
about all the applications using JB-AS.
- User status option. The SA can set a user's status to Requested,
Active, Suspended and Deleted modes. Only Active users can log in. Requested
mode is ideal for permitting users to create their own accounts, while requiring
those accounts to be activited by trusted personnel.
|
|
Development
|
JB-AS provides an easy to use interface for integrating your applications with the JB-AS
security service via Java utility jars
called JB-AS Client. You can use JB-AS Client to integrate application security
in any of your J2EE applications with ease using these features:
- Easy installation. To install JB-AS Client in your individual application, you simply
include the client utility jar files in your application. If you are
deploying your application to a different server than where the JB-AS service is running, then you simply
need to include a properties file telling it where
the JB-AS server is.
- Remote application deploy. Your applications can run in any J2EE container tested
to work with JB-AS, such as WebSphere or JBoss. A simple properties file only needs two lines of
text to tell it where the JB-AS server is.
- Quick log-in integration. JB-AS comes with a jsp login script you can include
as-is in your applications using the <jsp:include> tag. You then only need
two additional lines to turn on log-in ability for your application. This means
that you can integrate user log-in ability in a new application in minutes.
- Easy user access control. To apply access control, you simply inquire on the
access the current user has to a privilege. Thus, to determine the access a user has
to the INVOICE module, this code will return a CRUD object containing the boolean values for
the Create, Retrieve, Update and Delete privileges:
ESecurityWeb secWeb = ESecurityWeb.getInstance(request);
CRUD invoiceModuleAccess =
secWeb.getCachedSessionModuleCRUD( APPLICATION_NAME, MODULENAME_Invoice ) ;
if (invoiceModuleAccess.getCanRetrieve()) {
// The user can view invoice data
}
If no user is logged in, then the privileges of the CRUD object returned
are set to false.
- Privilege caching. In the previous example your application obtained the
privileges a user has to the INVOICE module. This information is automatically
cached, so you can code freely without concern for the performance impact of
using this for dynamically creating commonly accessed content such as menus.
If a user logs in or out, the cache is automatically reset.
|
|
| |
|
|
