Java Reference
In-Depth Information
The decision whether an authenticated user has access to a resource is controlled by
another process, called
authorization
. Authorization seeks to answer this question:
“What can you do?” In other words, it tries to find out the operations that an authenti-
cated user can perform in the system. In a Java EE application, this mainly involves
protecting access to web resources such as JSPs. The user's principal is generally associ-
ated with one or more roles. Each role in turn is linked to a set of resources or operations.
The eInsure application had a sign-in form for users to supply a username and pass-
word combination to get authenticated. The supplied information was checked into the
database, and valid users were granted access to carry out different operations.
The database-driven authentication mechanism used in eInsure was rigid. It was
placed deep inside the application and cut across all the tiers. In other words, the
authentication logic was implemented just like any normal operation such as policy
underwriting. In a refactored eInsure system, this would mean the request for authenti-
cation would be intercepted by the front controller and passed on to a page controller.
This would be followed by the invocation of the business delegate, session facade, and
data access objects.
Ideally, authentication and security code should be applied transparently and need
not span tiers. eInsure was being implemented by clients who had an existing enterprise-
wide security policy and software in place. So, in most cases the database-driven
approach did not work. Instead, the application had to adapt itself to the customers'
existing security implementation such as Lightweight Directory Access Protocol (LDAP),
Single Sign On (SSO), or OpenID. This resulted in a lot of code changes and testing in dif-
ferent tiers to integrate with an alternate authentication implementation.
As shown in Listing 4-1 later in the chapter, the JSP controller used the user informa-
tion as well as the event code to check whether the user has the privileges to execute a
certain action. This check was also placed deep inside the presentation tier. Any changes
to the authorization helper methods would lead to changes across all the controllers.
Such deeply embedded authorization checks resulted in the mixing of security and pres-
entation concerns. The authorization code in eInsure would query the database for each
request to find out whether the user had the privileges to execute the action with the
given event code. This database trip for each request had a negative impact on perform-
ance. Last but not least, the event code was hard-coded in the view and controller JSPs as
well as maintained in the database. Any change to the event code value meant modifica-
tion in all the JSPs. This often would lead to minor bugs that were very difficult to detect.
Forces
• Only valid users are allowed entry into the application.
• All different entry points into an application should be guarded by authentication.
