Meeting security requirements of Software as a Service (SaaS) applications

Secure authentication and authorization with multiple tenants

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.

Chetan J. Kothari, Principal Architect, Infosys Technologies Limited

Author1 photoChetan 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.



25 September 2007

Also available in Chinese Russian Japanese Spanish

Introduction

Develop skills on this topic

This content is part of progressive knowledge paths for advancing your skills. See:

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.

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
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
    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
    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

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=257921
ArticleTitle=Meeting security requirements of Software as a Service (SaaS) applications
publish-date=09252007