Securing a composite business service delivered as a software-as-a-service: Part I, secure multi-tenancy with WebSphere Portal Server

Using Tivoli Directory Server and Tivoli Directory Integrator

A composite business service (CBS) introduces many new challenges (for example, multi-tenancy) for security in an SOA solution. In this two-article series, a few security scenarios are examined in a proof-of-concept CBS software-as-a-service (SaaS) application for banking called Jivaro, which helps to identify when and how to apply different IBM® Tivoli® security products.

Share:

Indrajit Poddar (ipoddar@us.ibm.com), Software Architect, IBM

Indrajit Poddar (IP) is a member of the Strategy, Technology, Architecture, and Incubation team at IBM Software Group Strategy, where he leads several integration PoCs for building composite business services.



Min Li (minli@cn.ibm.com), Software Architect, IBM

Min Li works in the China Emerging Technologies Institute, China Software Development Laboratory, where he has a team working on PoCs development for building composite business services. His interests include J2EE, SOA, MDA/MDD, AOP, RUP, and so on.



Qiang Wang (wangq@cn.ibm.com), Software Architect, IBM

Qiang Wang works as a software engineer in the China Emerging Technology Institute, China Software Development Laboratory. He concentrates on IBM Incubator projects and SOA-related topics. His interests include J2EE, SOA, MDA/MDD, AOP, RUP, and project management. He is currently working on a SOA pilot named composite business services (CBS).



Ying Chun Guo (guoyingc@cn.ibm.com), Software Architect, IBM

Ying Chun Guo works as a software engineer in China Technology Institute, China Software Development Laboratory. She is working on CBS and SOA this year.



Zhi Gan (ganzhi@cn.ibm.com), Software Architect, IBM

Zhi Gan is a software engineer at the IBM China Development Lab. He joined IBM after receiving a Ph.D. in computer security from Shanghai JiaoTong University. He has extensive experience in SOA, AOP, and Eclipse. Now he primarily focuses on model-driven development with patterns.



12 September 2007

Introduction

A composite business service (CBS) integrates a set of fine-grained services with a business process using an service oriented architecture (SOA). A CBS is often delivered as a software-as-a-service (SaaS) (see the Resources section for more details on SaaS). A CBS delivered as a SaaS introduces many new challenges for security, for example, multi-tenancy (see the Resources section for more details on multi-tenancy).

In Part 1, new security considerations are discussed for a CBS delivered as a SaaS. Example non-functional security requirements are examined in the context of the Jivaro CBS SaaS application built using IBM WebSphere® Portal Server and WebSphere Process Server. Techniques for meeting the multi-tenancy security requirements in Jivaro using Tivoli Directory Server and Tivoli Directory Integrator are discussed.

In Part 2, Tivoli Access Manager, Tivoli Federated Identity Manager (including the Security Token Service) and Tivoli Federated Identity Manager Business Gateway are shown being used for implementing additional security scenarios in the Jivaro proof-of-concept (PoC) CBS SaaS application.

1. What makes security considerations for a CBS delivered as a SaaS different?

Securing a CBS delivered as a SaaS involves consideration of additional security concerns. For example:

1.1 Multi-tenancy

Multi-tenancy is an architectural principle often associated with SaaS architectures. Multi-tenancy requires supporting users from multiple tenant organizations in a single instance of a running application. Securing such an application involves applying access control to all resources shared between tenant organizations. Example resources include portal pages, portlets, Web services, SCA modules, BPEL processes, and so on.

1.2 Propagation of identities

With integration of services in a CBS, the identity of the end-user cannot remain confined to one service. It needs to be propagated between services, which are part of the CBS. An identity in a CBS might need to traverse:

  1. Multiple security domains, for example, www.yourco.com and www.yourcopartner.com
  2. Multiple tiers, for example, a Web tier using WebSphere Portal Server and a choreography tier built using WebSphere Process Server
  3. Legacy systems, for example, an IBM CICS® Transaction Server

Users of a CBS should not be inconvenienced by multiple log ins. The format of the identity might need to change, for example, from SAML to WebSphere LTPA and sometimes the identity itself might change, for example, identity mapping of user “A” in www.yourcopartner.com to user “B” in www.yourco.com. Also it should be noted that if the identity of the end user is not propagated to all components, audit requirements might not be properly met.

1.3 Integration of multiple sources of user identity

Integration of services from different service providers often requires aggregation of user identity and credential information from different sources. For example, consider two departments (Dept A and Dept B) in an enterprise which keep their customer information in different data stores. Let’s say Dept A uses an IBM DB2® Database and Dept B uses an LDAP repository. If you want to create a CBS with constituent services from Dept A and Dept B, and make the CBS available to both Dept A's and Dept B's customers, then one way of solving this problem is to aggregate (physically move) Dept A's and Dept B's customer information from a DB2 and an LDAP data store, respectively, to a common user registry with the help of automated migration tools.

1.4 Management of fine-grained authorization policies for different types of service components

Authorization policies for CBS components in different tiers (for example, a Web tier and workflow tier) are often fine-grained and distributed at multiple policy enforcement points. This can potentially cause inconsistencies and difficulties in policy management.

1.5 Protection for data passed between service invocation

Service invocations in a CBS requires transmission of data to multiple service providers over networks, which might not share the same level of transport layer security. Also, intermediate tiers of a CBS might not be trusted. Hence message level security might need to be enforced.

2. Sample security requirements in a fictitious CBS application

As a proof-of-concept, a fictitious multi-tenant banking application called Jivaro was built. It includes composite business services hosted in WebSphere Portal Server and WebSphere Process Server. An earlier article titled: "Building SOA composite business services, Part 1: Develop SOA composite applications to enable business services", introduces some scenarios supported by the Jivaro banking application.

For securing the Jivaro CBS application for banking, the following security related non-functional requirements need to be met:

2.1 Authentication:

  1. Only bank users with valid credentials should be allowed to access the Jivaro bank application.
  2. Bank customers should not need to authenticate multiple times when accessing components in different tiers of a composite business service within the Jivaro security domain.
  3. Bank customers should not need to authenticate multiple times when accessing services provided by Jivaro bank partners hosted outside the Jivaro security domain.
  4. Bank service consumers should not be required to authenticate multiple times when accessing the Jivaro Bank portal from their internal portal.

2.2 Authorization:

  1. Bank customers for one bank should not be able to access the portal for another bank.
  2. Access to portlets, Web services and SCA components in a Jivaro composite business service should be protected by pre-defined roles and all bank customers should be assigned one or more roles.

2.3 Audit:

  1. All failed and successful login attempts should be recorded in a log along with the time of the login attempt.
  2. The identity of the end-user should be logged when invoking a service (directly or indirectly through an intermediate service) in any tier (for example, portal, process or database) of a CBS.

2.4 Integrity and confidentiality:

  1. All sensitive messages to the Jivaro application should be encrypted for confidentiality
  2. All messages should be checked for integrity.

2.5 Identity management:

  1. Bank customers should be provided the ability to reset their passwords through self-service.
  2. All passwords should conform to a standard set of policies (for example, passwords must be greater than 8 characters in length).

3. Tivoli Security Products mapped to the requirements

The following Tivoli security products were identified for meeting the above requirements in the Jivaro application:

  • IBM Tivoli Directory Server (TDS) V6.1
  • IBM Tivoli Directory Integrator (TDI) V6.1
  • IBM Tivoli Access Manager (TAM) for e-Business including WebSEAL 6.0.3
  • IBM Tivoli Federated Identity Manager (TFIM) V6.1.1, including the Security Token Service (STS) component
  • IBM Tivoli Federated Identity Manager Business Gateway (TFIM BG) V6.1.1
  • IBM Tivoli Identity Manager (TIM) V4.6

TDS was used to support requirements 2.1.1 and 2.1.2 and to build a multi-realm LDAP user registry for multiple tenant banks in the Jivaro application. Virtual portals and multi-realm security in WebSphere Portal Server V6.0 were used in conjunction with TDS to support requirement 2.2.1. More details on our multi-tenant security architecture are presented in section 4.1.

TDI was used to support requirements 2.1.1 and 2.1.2 by migrating user information from different sources into our multi-realm user registry. More details are presented in section 4.2.

The TAM WebSEAL component was used to support requirements 2.1.1 and 2.1.2 and to build a DMZ perimeter around the Jivaro application. More details on our DMZ architecture are presented in section 1.1 of the second part of this series (see the Resources section).

The TFIM STS component was used to support requirement 2.1.2 by transforming tokens from one format to another when accessing legacy backend services. More details are in section 1.2 of the second part of this series (see the Resources section).

The TAM Policy manager was used to support requirement 2.2 by storing fine-grained and role-based access control policies in a central policy decision point. More details are in section 1.3 of the second part of this series (see the Resources section).

TFIM and TFIM BG were used to support requirement 2.1.3 and 2.1.4 by building a trust federation between Jivaro bank and its business partners. More details are in sections 1.4 and 1.5 of the second part of this series (see the Resources section).

Audit requirements (section 2.3 ) were met through the audit functions available in TAM (and all other Tivoli products). Identity propagation, implemented with TAM and TFIM was used to meet requirement 2.3.1

All Jivaro bank services expose Web services interfaces and hence support the integrity and confidentiality requirements (section 2.4 ) through the support for ws-security in WebSphere Application Server. For more details, please refer to the five-part series on "Web Services security with WebSphere Application Server V6" in the Resources section.

TIM can be used to meet identity management requirements in section 2.5. TIM was not in the scope of our PoC. For more information on TIM, please see the Tivoli Software Information Center in the Resources section.

Figure 1 shows an overview of all the Tivoli security products applied in the Jivaro security architecture

Figure 1. Tivoli security products applied in the Jivaro bank security architecture
Tivoli Security Products applied in the Jivaro bank

4. Supporting multi-tenancy and multiple sources of user information in the Jivaro SaaS for CBS

4.1 Multi-tenant user registry using Tivoli Directory Server and WebSphere Portal Member Manager

Figure 2. Jivaro multi-tenant LDAP user registry
Jivaro multi-tenant LDAP user registry

The Jivaro banking application is a multi-tenant CBS application (see more details in Building SOA composite business services, Part 7: Support Multi Tenancy for Composite Business Services). It uses virtual portals in WebSphere Portal Server to provide a shared presentation layer for different tenant banks. Each virtual portal provides a different URL for each bank's portal, for example, for bank1: http://jivaro.com:10038/wps/myportal/bank1 and for bank2 http://jivaro.com:10038/wps/myportal/bank2.

In the Jivaro multi-tenant application, subscriber isolation was provided by using multiple security realms in WebSphere Portal Server with the help of its Member Manager (MM) component. Each realm is mapped to the virtual portal for a bank. For more details on configuring multiple realms, see the WebSphere Portal V6.0 Infocenter article: Using multiple realms and user registries. With subscriber isolation, the user population for one tenant (for example, user b1a1 in Figure 2) can only authenticate to its own virtual portal (http://jivaro.com:10038/wps/myportal/bank1) and cannot authenticate to the virtual portal for a different tenant (e.g. http://jivaro.com:10038/wps/myportal/bank2).

The user populations for different realms are stored in a TDS LDAP user registry under different sub-trees, as shown in Figure 3. Different LDAP suffixes were assigned to the different bank realms (also called WMM nodes), for example, a base DN of dc=bank1, dc=com for Bank1 and a base DN of dc=bank2, dc=com for Bank2.

Figure 3. Jivaro LDAP suffixes for different banks
Jivaro LDAP suffixes for different banks

For each realm in Figure 3, a WebSphere Portal Member Manager node was created in the wmmur.xml configuration file in WebSphere Portal as shown in Listing 1:

Listing 1. WebSphere Portal Member Manager user registry configuration file for multi-realm security (wmmur.xml)
<?xml version="1.0" encoding="UTF-8" ?>
<wmmur>
	<realms>
		<realm id="portal" delimiter="@" default="true">
			<node wmmnode="dc=banks,dc=com" /> 
			<node wmmnode="dc=bank1,dc=com" />
			<node wmmnode="dc=bank2,dc=com" />
			<node wmmnode="dc=bank3,dc=com" />
			<node wmmnode="cn=users,dc=banks,dc=com" defaultParent="Person" />
			<node wmmnode="cn=groups,dc=banks,dc=com" defaultParent="Group" /> 
			<node wmmnode="cn=users,dc=bank1,dc=com" defaultParent="Person" />
			<node wmmnode="cn=groups,dc=bank1,dc=com" defaultParent="Group" />
			<node wmmnode="cn=users,dc=bank2,dc=com" defaultParent="Person" />
			<node wmmnode="cn=groups,dc=bank2,dc=com" defaultParent="Group" />
			<node wmmnode="cn=users,dc=bank3,dc=com" defaultParent="Person" />
			<node wmmnode="cn=groups,dc=bank3,dc=com" defaultParent="Group" />
			<node wmmnode="uid=wpsadmin,cn=users,dc=banks,dc=com" />
		</realm>
		<realm id="bank1" delimiter="@" default="false">
			<node wmmnode="dc=bank1,dc=com" />
			<node wmmnode="cn=users,dc=bank1,dc=com" defaultParent="Person" />
			<node wmmnode="cn=groups,dc=bank1,dc=com" defaultParent="Group" />
			<node wmmnode="uid=wpsadmin,cn=users,dc=banks,dc=com" />
		</realm>
		<realm id="bank2" delimiter="@" default="false">
			<node wmmnode="dc=bank2,dc=com" />
			<node wmmnode="cn=users,dc=bank2,dc=com" defaultParent="Person" /> 
			<node wmmnode="cn=groups,dc=bank2,dc=com" defaultParent="Group" /> 
			<node wmmnode="uid=wpsadmin,cn=users,dc=banks,dc=com" />
		</realm>
		<realm id="bank3" delimiter="@" default="false">
			<node wmmnode="dc=bank3,dc=com" />
			<node wmmnode="cn=users,dc=bank3,dc=com" defaultParent="Person" />
			<node wmmnode="cn=groups,dc=bank3,dc=com" defaultParent="Group" />
			<node wmmnode="uid=wpsadmin,cn=users,dc=banks,dc=com" />
		</realm>
	</realms>
</wmmur>

Access control features in WebSphere Portal were used to ensure that only roles specific to a particular tenant gets access to the portal pages and portlets intended for that tenant. For example, only the role bank1admin was allowed to access the portal page, "Bank Administration" in the virtual portal for bank1. For more details on Portal Access Control, see the Resources section.

The same LDAP server was used as the user registry for enabling authentication to the back-end WebSphere Process Server. In addition, all business processes with human tasks in the back-end WebSphere Process Server used the same LDAP server instance with the LDAP Staff Resolution plug-in in WPS for assigning human tasks to the appropriate owner. More details on the LDAP Staff Resolution plug-in are in the article titled: "WebSphere Application Server Enterprise Process Choreographer: Staff Resolution Architecture" and the "Business Process Choreographer Samples" (under Process Modeling Techniques->Authorization) in the Resources section.

A recorded demo showing multi-tenant security features in the Jivaro application can be accessed from the Animated Demos section .

4.2 Assembly lines for moving user information between different sources using Tivoli Directory Integrator

TDI was used to build a meta-directory with assembly lines for moving, copying and transforming user data among multiple data sources.

In the Jivaro multi-tenant application, TDI was used in a scenario where two Jivaro tenant banks are merged (that is, Bank2 is acquired by Bank1). In this scenario, the user data of one bank (bank2) needed to be migrated with the user data of another bank (bank1) in the Jivaro common user registry. Figure 4 describes the major steps in this process. Step 1 and 2 are carried out in a batch Extract Transform Load (ETL) mode. In between steps 1 and 2, TDI performs user data transformation on all bank2's user data, for example changing the DN of bank2 users to the DN of bank1 users, with the help of custom scripts.

TDI can be also used to source user information from a wide variety of user registries, for example, Microsoft SQL server as described in the article: "Connecting to Microsoft SQL Server using IBM Tivoli Directory Integrator" in the Resources section. For more information on the built in connectors available ready to use TDI, please refer to the Tivoli Directory Integrator Reference Guide in the Resources section

Figure 4. Jivaro multi-tenant meta-directory with Tivoli Directory Integrator
Jivaro multi-tenant meta-directory with Tivoli Directory Integrator

Five more scenarios (including federated, enterprise and legacy single sign-on and authorization) are discussed in the second part of this series (see the Resources section)..

Conclusions

In conclusion, new security considerations for supporting composite business services delivered as software-as-a-service (SaaS) were explored. These considerations were described in the context of several scenarios from a PoC CBS for banking built using WebSphere Portal Server and Process Server. It shows how the security considerations of multi-tenancy and multiple sources of user information in a CBS SaaS can be supported using features in WebSphere Portal Server, WebSphere Process Server, Tivoli Directory Server and Tivoli Directory Integrator. In the second part of this article series, additional scenarios are described for supporting propagation of user identities and management of authorization policies.


Animated demos

See a demo of Secure multi-tenancy in composite business services using WebSphere Portal Server and Tivoli Directory Server

Show me (6:30 min)

Download Adobe Flash Player.

If this is your first encounter with a developerWorks article that includes demos, here are a few things you might want to know: Demos are an optional way to see the same steps described in this article. To see an animated demo, click the Show me icon. The demo opens in a new browser window. Each demo contains a navigation bar at the bottom of the screen. Use the navigation bar to to pause, exit, rewind, or fast forward portions of the demo. The demos are 800 x 600 pixels. If this is the maximum resolution of your screen or if your resolution is lower than this, you will have to scroll to see some areas of the demo. JavaScript must be enabled in your browser and Macromedia Flash Player 6 or later must be installed.


Acknowledgements

The authors would like to acknowledge Nataraj Nagaratnam, Distinguished Engineer, IBM Tivoli for contributing to the security considerations for a CBS. The authors would also like to acknowledge Neil Readshaw, Senior Software Engineer, IBM Tivoli for reviewing this article and helping to improve its contents.

Resources

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 Security on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security
ArticleID=252342
ArticleTitle=Securing a composite business service delivered as a software-as-a-service: Part I, secure multi-tenancy with WebSphere Portal Server
publish-date=09122007