Welcome!

Java IoT Authors: Elizabeth White, Liz McMillan, Pat Romanski, Yeshim Deniz, Mehdi Daoudi

Related Topics: Java IoT, Cloud Security

Java IoT: Article

J2EE Application Security

J2EE Application Security

When designing Web-based applications, security is a critical component. Before the advent of J2EE, to implement a secure distributed application you had to code all of the security directly into the application.

J2EE introduced a powerful security infrastructure for applications that greatly assists developers and enterprises in securing their applications. When used properly, this infrastructure takes much of the burden of securing the application off of the developers, leaving them free to concentrate on implementing business logic.

The J2EE container-security services primarily address the security requirements of authentication and authorization. Authentication is the mechanism by which callers and service providers prove to each other that they are acting on behalf of specific users or systems. Authorization mechanisms provide control over what resources an identified user or system has access to. In simple terms, authentication provides the answer to "Who are you?" And authorization provides the answer to "What can you access?"

Authentication
The J2EE model supports several methods for authenticating users. These are basic, digest, form-based, and certificate-based authentications. In basic authentication, the Web server prompts the user for a user name and password, which is then transmitted to the server. Unless an SSL session has been established, this information is sent in the clear, so it's not very secure. Digest authentication improves the security a bit by sending a digest of the user name and password along with some session-specific information to the server instead of transmitting the clear text password.

Both of these methods result in a standard dialog being presented to the user for entering user name and password.

Form-based authentication allows the developer to create a custom log-in page using a form. Like basic authentication, the user name and password are sent in the clear, unless an SSL session has been established.

Finally, the most secure method of authentication is the certificate-based method. In this method, both client and server use X.509 certificates to prove their identities. This authentication always occurs over an SSL-protected channel.

The Web component deployment descriptor specifies which resources are protected, thus requiring user authentication. The actual step of authenticating the user is usually accomplished by looking the user up in a corporate directory or database.

After successfully proving a user's or service's identity, an authentication context is established. This allows the user or service to be authenticated to other entities - without repeating the authentication lookup step. A user may also delegate its authentication context to a component, allowing that component to call another component while impersonating the original caller.

The authentication mechanism is configured in the Web component deployment descriptor. Listing 1 shows an example of configuring digest authentication. Listing 2 shows an example of configuring form-based authentication. The error page specified in Listing 2 is a page presented to the user when authentication fails.

Authorization
J2EE employs a permissions-based authorization model. Each protected resource is listed in the deployment descriptor, along with a list of roles that are able to access the resource. These roles are mapped to specific users by the application deployer. Static pages, JSPs, and servlets are protected at the URL level and can be further protected down to GET or POST methods. Protection of EJBs can be specified down to specific-class methods. Specifying authorization information in the deployment descriptor is referred to as declarative authorization. Embedding authorization logic directly into an application is called programmatic authorization. The J2EE model supports both of these authorization models. Unless requirements demand it, declarative authorization is generally the preferred method.

Declarative Authorization
The authorization rules specified in the deployment descriptor are enforced by the J2EE container. This method of providing authorization frees the developer from worrying about implementing authorization, which is generally a good thing because it's an easy area for developers to introduce bugs that can lead to large security holes in the application. Applications that rely solely on this form of declarative authorization are sometimes referred to as security-unaware applications. The application code itself has no knowledge of the security that is wrapping it. Declarative authorization is a container-managed security service.

Listing 3 shows an example of applying declarative authorization to a servlet in the deployment descriptor. In this example, all servlets and other resources in the "restricted" directory will be protected. Only users assigned the role "AuthorizedUser" will be granted access to these resources. Listing 4 shows declarative authorization being applied to an EJB. This example applies protection to the UserInformation bean. Users assigned the "admin" role are granted rights to access all methods. Users assigned the "customer" role are granted the right to access the getDetails() method.

Programmatic Authorization
The J2EE model also provides support for extending the authorization model through programmatic authorization. There are four key methods developers can use. They are:

  • isCallerInRole() and getCallerPrinciple() for use by EJB code
  • isUserInRole() and getUserPrinciple() for use by Web components
These methods are typically used to provide finer-grain access control than what can be achieved through pure declarative authorization. Applications that employ programmatic authorization are referred to as security-aware applications. Programmatic security is also referred to as application-managed security.

A good example of where programmatic authorization is necessary is in protecting access to user account objects. Consider an application that manages some type of user accounts.

Let's say the developer designates two roles: one for users and the other for administrators. The users should have access only to their own account. The administrators should have access to all accounts. There is no way to enforce this policy using declarative authorization alone. This stems from the fact that access rules specified in the deployment descriptor are class-based, not instance-based. Specific users or roles can't be granted access to specific instances of an object while denying them access to other instances of an object.

A solution is to use programmatic authorization. In the account object, the developer would use the isUserInRole() method to determine if the user was an administrator. If so, the user would automatically be granted access to the account. If not, the developer would then use the method getUserPrinciple() and compare that to the account owner. If they are the same, access would be granted.

Implementing security inside each application greatly increases the chance of introducing a vulnerability that can be exposed by hackers. Programmatic authorization should be used only when the requirements can't be met through declarative authorization.

Confidentiality and Integrity
So far, I've covered the topics of authentication and authorization. The other important security requirement is message protection, specifically, employing the concepts of confidentiality and integrity.

Integrity ensures that a message hasn't been accidentally or intentionally modified. Confidentiality ensures the privacy of a message. Both of these services are provided through cryptographic techniques.

The J2EE security model doesn't provide a great deal of flexibility or support in this area. In the deployment descriptor, resources can be designated as requiring confidentiality. This permits them to be served only over SSL connections. Going beyond the pure J2EE security model, there's a great deal of support in Java for providing programmatic protection of messages.

Divided Responsibilities
One of the goals of the J2EE security model is to lessen the burden on the application developer for securing applications. To assist in achieving this goal, the J2EE model recognizes the three distinct roles played in bringing an application from concept to deployment. The roles are component provider, application assembler, and deployer.

Slight variations on these role names appear in various publications. The component provider is the developer, the person actually writing the Java code. The application assembler takes several components (beans, EJBs, JSPs, etc.) and assembles them into a complete application. Finally, the deployer is responsible for actually deploying the application into the production enterprise environment.

The component provider implements all programmatic security. In doing so, they define generic security role names for providing access control functionality. The application assembler defines logical roles, specifies which resources should be protected, and which roles are required to access those resources. The deployer then is responsible for mapping the logical roles to the specific enterprise environment. It should be noted that one individual or team may play multiple roles in bringing an application to production. It's not unusual for the component provider and the application assembler roles to be performed by the same team.

Container-Managed Security
Implementing modern security mechanisms such as confidentiality, authentication, and authorization requires a great deal of expertise in the security domain. Most application developers don't have the expertise needed to successfully implement these security services. This makes creating applications that are security-aware all the more challenging.

A better idea is to rely on the application-server vendors to implement the tough security services - and have your application make use of these container-managed services. This eliminates the necessity of having a security development engineer on every Web application project.

Having said this, the requirements must be the ultimate driver for whether or not programmatic security should be used. Some requirements, such as the account example given in this article, can't be satisfied using container-managed security alone. It should be noted that this example and the methods provided by J2EE specifically focus on authorization. It's best to always rely on container-managed authentication. Embedding authentication logic into each application creates a hard to manage authentication policy that has a high potential for security vulnerabilities.

Another advantage of relying on containermanaged services is that as authentication technology is upgraded within an enterprise, the applications don't have to be rewritten. Using programmatic authentication would require massive application rewrites if enterprise authentication technology were to change.

Relying predominantly on container-managed security also allows you to maintain a common security infrastructure as opposed to sprinkling security throughout all your Web applications. Container-managed security services allow for the centralization of security policies in a central repository. When using container-managed security, a change in security policy requires changes in application configuration, as opposed to coding changes in your applications.

More Stories By Timothy Fisher

Timothy Fisher has recognized expertise in the areas of Java, Ruby, Rails, Social Media, Web 2.0, and Enterprise 2.o. He has served in technical leadership and senior architecture roles with companies such as Motorola, Cyclone Commerce, and Compuware. He is the author of the Java Phrasebook, and the Ruby on Rails Bible. Currently he is employed as a senior web architect with Compuware in Detroit, Michigan.

Follow Timothy on Twitter at http://twitter.com/tfisher

Comments (3)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
DSR is a supplier of project management, consultancy services and IT solutions that increase effectiveness of a company's operations in the production sector. The company combines in-depth knowledge of international companies with expert knowledge utilising IT tools that support manufacturing and distribution processes. DSR ensures optimization and integration of internal processes which is necessary for companies to grow rapidly. The rapid growth is possible thanks, to specialized services an...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
Scala Hosting is trusted by 50 000 customers from 120 countries and hosting 700 000+ websites. The company has local presence in the United States and Europe and runs an internal R&D department which focuses on changing the status quo in the web hosting industry. Imagine every website owner running their online business on a fully managed cloud VPS platform at an affordable price that's very close to the price of shared hosting. The efforts of the R&D department in the last 3 years made that pos...