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.
In this article you learn various application-level security requirements of J2EE-based multi-tenant SaaS applications and mechanisms to address these requirements.
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 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.
- In an on-demand environment, but the database schema may be different.
- 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.
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.
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.
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
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.
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.
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.
"Architectural Strategies for Catching the Long Tail" (Microsoft Corporation, Apr 2006) discusses the software-as-a-service (SaaS) model for software delivery, a high-level description of the architecture of a SaaS application, and the challenges and benefits of developing and offering SaaS.
- Java Authentication and Authorization Overview provides more information about JAAS.
The Wikipedia discussion of
Software as a service covers the history, philosophy, key characteristic, and more.
- Find out about IBM Software Services for WebSphere.
- IBM offers leading-edge hardware, software, and infrastructure technologies to help
you get started with SaaS in addition to your existing business model.
- IBM on demand demos to learn about various software products and technologies from IBM.
- Stay current with
developerWorks Live! webcasts.
- developerWorks Live! Technical events and briefings
Get products and technologies
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational, Tivoli®, and WebSphere®.
- Participate in the discussion forum.
- Check out
get involved in the
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.