 | Level: Introductory Chetan J. Kothari (chetan_kothari@infosys.com), Principal Architect, Infosys Technologies Limited
25 Sep 2007 Security is an important consideration when architecting Software as a Service (SaaS) applications because data and processes may be housed outside of an organization's premises. In this article, learn about various security
requirements forJava™ 2 Platform Enterprise Edition (J2EE)-based,
multi-tenant, efficient SaaS applications, and explore mechanisms to
address requirements to achieve secure authentication and authorization of users.
Introduction
The Software as a Service (SaaS) business model, driven
by an effort to reduce IT cost and efforts, is garnering a lot of
interest in the software industry. In this model, application functionality is delivered through a
subscription model over the Internet. The business does not take
ownership of the software, but instead subscribes to a total solution that is delivered
remotely. With the SaaS model, you can reduce IT costs because you no longer need to
support multiple platforms and versions. However, because
data and processes are housed externally, security is a top priority in SaaS
architecture.
Because it is changing the way software is built, consumed, and delivered (compared
with traditional software development practices), SaaS is
proving to be a disruptive IT trend. One of the key differences between developing a SaaS application and
developing an enterprise application is that SaaS applications must be
multi-tenant. Other key SaaS requirements, such as security,
customization, Service-Oriented Architecture (SOA), and integration impact the SaaS application architecture.
SaaS is disruptive trend because it is
In this
article you learn various application-level security requirements of J2EE-based
multi-tenant SaaS applications and mechanisms to address these
requirements.
Security requirements for SaaS applications
A multi-tenant, efficient SaaS application has several security requirements
including:
- The system must provide security and control access to those functions based
on permissions.
- User data may reside in an on-premise environment.
The system should provide
mechanisms to authenticate users with user data residing in the on-premise environment,
and authorize with access control data residing in an on-demand environment.
- Because of strong data isolation and compliance requirements of the tenant,
user data may reside in a dedicated database in an on demand environment for each of
the tenants.
The system should provide a mechanism to authenticate and authorize
users against a separate database realm, configured for the tenant that the user
belongs to.
- User data may reside in shared a database:
- In an on-demand environment, but the database
schema may be different.
The system should provide a mechanism to authenticate
and authorize against a shared database, with a different database schema configured
for the tenant to which the user belongs.
- In a shared schema in an on-demand environment.
The system should provide a mechanism to authenticate and authorize users against a
shared database and shared schema used for all the tenants.
- User data may reside in a shared database.
- Provide a mechanism to enable each tenant's administrator to create, manage, and
delete user accounts for that tenant in the user account directory.
 |
Addressing the requirements
To address application-level security requirements of SaaS, your architecture should
address authentication and authorization requirements. Two scenarios in this article illustrate:
-
User account database in on-demand environment
In this scenario, the architecture should provide custom-built security services
to authenticate and authorize users against a centralized multi-tenant user
account database, as well as a tenant-specific dedicated database. The architecture
should also provide an interface to let tenants create, manage, and delete
user accounts for that tenant in the user account directory.
When single sign-on is not important for customers, this approach is
recommended. This approach can be targeted for consumer users.
-
User account database on premise
In this scenario, the tenant deploys a federation service that interfaces
with the tenant's own user directory service. When an end user tries to
access the application, the tenant's federation server authenticates the user
locally and negotiates with the SaaS federation server to provide the user
with a signed security token. The security token issued by the tenant's
federation server will be used by the SaaS provider for authorization.
This
approach is recommended when single sign-on (SSO) is important for customers. It can also be targeted for business users.
|
User account database in on-demand environment
Why should you custom build a security solution? A key technical requirement is that an SaaS application can enable housing of multiple tenants within one infrastructure. To
address this requirement, SaaS providers must have a mechanism to run a single
SaaS application instance to accommodate users from all the tenants supported by
the application.
Figure 1 shows how a single instance of an SaaS application supports users
of multiple tenants. Security Service uses default centralized
Database 1 for all users of Tenant 1 and Tenant 2. Concurrently, to address
strong data isolation and compliance requirements of Tenant 3 and Tenant 4, the Security
Service also must provide a mechanism to support dedicated Database 2 for all
users of Tenant 3 and dedicated Database 3 for all users of Tenant 4.
Figure 1. Supporting users of multiple tenants
A security framework needs to provide a separate realm
for each tenant and a mechanism to authenticate users using the realm configured
for the tenant to which the customer belongs, based on the context. In this case, context is
a combination of parameters (such as tenant, line of business, geographical
location, and so on) that decides the business operation and usage environment of the
application.
A J2EE container-based security framework has the limitation of supporting multiple
security realms active at a given time. Although all the leading J2EE containers
provide a mechanism to configure multiple realms, only one can be active at a time.
The J2EE security model is based on method permission, so it is impractical and
cumbersome for fine grained security access.
So, all you need to build a custom security service based on Java Authentication and Authorization Service (JAAS) to address the above
limitations. JAAS is a set of APIs
that enable services to authenticate and enforce access controls upon users. JAAS
simplifies Java security development by putting an abstraction layer between
application and disparate underlying authentication and authorization mechanisms.
Custom build a security service based on
JAAS
A security service based on JAAS should provide mechanisms to:
- Establish user identity before accessing any business functions.
- Provide functional and data entitlement by maintaining access control lists
of users.
- Support creation and maintenance of users, groups, and ACLs.
- Address multi-tenancy requirements of SaaS applications.
- Enable each tenant's administrator to create, manage, and delete user
accounts for that tenant in the user account directory.
A key difference in building security services for SaaS applications
compared to other enterprise applications is the support to handle multi-tenancy
requirements. To address this requirement, the security service should address the following items.
- A means to capture user context
Again, context is
a combination of parameters (such as tenant, line of business, geographical
location, and so on) that decides the business operation and usage environment of the SaaS
application.
- Provide three distinct approaches for creating multi-tenant data
architecture:
- Dedicated tenant database
- A dedicated database will be
given to each tenant. This approach is recommend when there is strong
data isolation requirements from customers.
- Shared database, separate schema
- A shared database is
used for all tenants, and each tenant has their own set of tables in a
separate schema created for the tenant. The database tables in Figure 2 can be used by a
security service to support this and a dedicated tenant database approach.
Figure 2. Dedicated database schema
- Shared database, shared schema
- A shared database and shared
schema will be used for all tenants. In this approach, in all tables the Tenant ID
column associates every record with the appropriate tenant. Figure 3 shows database
tables that can be used by a security service to support this approach.
Figure 3. Shared database schema
- Select the default data architecture strategy based on the requirements of the most tenants.
- Leverage a persistence framework that provides:
- A configuration driven mechanism that lets you use a multiple
database strategy to connect to a database.
- A mechanism to implement the persistence logic using an interface-based Data
Access Object (DAO) design pattern.
- A DAO Config XML configuration-driven mechanism to enable plugging
in different DAO implementations, with a mapping of the DAO logical name to the
implementation details.
- Need for a base XML configuration to interact with the database for default data
architecture strategy.
- Provide customized XML configuration to interact with the database for the tenant who
wants to go with other data architecture strategies.
- Provide a way to retrieve information that describes configurations and
extensions that are specific to each tenant, and plug in these customized
configurations at run time based on tenant context.
|
User account database on premise
An SaaS provider can leverage a commercial off-the-shelf (COTS) federated server for securely propagating
the federation token across applications located in different security domains. The SaaS provider needs to use a federated server, which is interoperable with
other SSO solutions used by enterprise customers in on demand
environments, for an SSO solution. A federation server residing in the
on-premise environment must have a trust relationship with a corresponding
federation server within the SaaS provider's network.
With the user account database on premise, you should also:
- Develop a servlet filter to retrieve authenticated user names that have been authenticated
using a federated server from an HTP header and create a valid principal/subject.
- Leverage a custom-built security service, based on Java Authentication and Authorization Service (JAAS), that addresses
multi-tenancy requirements of SaaS for authorization.
- Call the security service application program interface (API) from a servlet filter to authorize the user.
- Configure the servlet filter with Controller Servlet of Presentation Framework,
based on the model-view-controller (MVC) design pattern, to make sure that the incoming requests satisfy
the security requirements.
Summary
In this article you learned strategies to address application-level security
requirements of J2EE-based SaaS applications. These strategies can be used by an
SaaS provider to address security requirements of multi-tenant, efficient SaaS
applications.
Resources Learn
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational, Tivoli®, and WebSphere®.
Discuss
About the author | 
| | Chetan Kothari works as a principal architect at the Java™ 2 Platform, Enterprise Edition (J2EE) Center of Excellence
at Infosys Technologies Limited, a global leader in IT and business consulting
services. Chetan has more than nine years of experience, with expertise in J2EE application
framework development, defining, architecting and implementing large-scale,
mission-critical, IT solutions across a range of industries. Chetan holds a
Bachelor's degree in Electronics Engineering from Nagpur University. |
Rate this page
| |
