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:
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:
- Multiple security domains, for example, www.yourco.com and www.yourcopartner.com
- Multiple tiers, for example, a Web tier using WebSphere Portal Server and a choreography tier built using WebSphere Process Server
- 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:
- Only bank users with valid credentials should be allowed to access the Jivaro bank application.
- 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.
- Bank customers should not need to authenticate multiple times when accessing services provided by Jivaro bank partners hosted outside the Jivaro security domain.
- Bank service consumers should not be required to authenticate multiple times when accessing the Jivaro Bank portal from their internal portal.
- Bank customers for one bank should not be able to access the portal for another bank.
- 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.
- All failed and successful login attempts should be recorded in a log along with the time of the login attempt.
- 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:
- All sensitive messages to the Jivaro application should be encrypted for confidentiality
- All messages should be checked for integrity.
2.5 Identity management:
- Bank customers should be provided the ability to reset their passwords through self-service.
- 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.
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
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
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
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
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)..
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.
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.
- Participate in the discussion forum.
- Securing a composite business service delivered as a software-as-a-service, Part 2: Supporting federated and enterprise single sign-on (SSO) using Tivoli Access Manager and Federated Identity Manager, http://www-128.ibm.com/developerworks/webservices/library/ws-soa-composite/
- Building SOA composite business services, Part 1: Develop SOA composite applications to enable business services, http://www-128.ibm.com/developerworks/webservices/library/ws-soa-composite/
- Building SOA composite business services, Part 7: Support Multi Tenancy for Composite Business Services
- Software as a service, http://en.wikipedia.org/wiki/Software_as_a_Service
- Multi-tenancy, http://en.wikipedia.org/wiki/Multitenancy
- IBM Tivoli Security Management solutions, http://www-306.ibm.com/software/tivoli/solutions/security/
- Using multiple realms and user registries, WebSphere Portal V6.0 InfoCenter, http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/wmm_mltpl_realm.html
- Member Manager in WebSphere Portal Server, http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/cfg_wmm.html
- WebSphere Portal Access Control, http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/sec_man.html
- WebSphere Application Server Enterprise Process Choreographer: Staff Resolution Architecture, http://www-128.ibm.com/developerworks/websphere/library/techarticles/wasid/WPC_StaffArch/WPC_StaffArch.html
- Business Process Choreographer Samples, http://publib.boulder.ibm.com/bpcsamp
- "Connecting to Microsoft SQL Server using IBM Tivoli Directory Integrator" from http://www-128.ibm.com/developerworks/tivoli/library/t-sqlitdi/
- Web Services security with WebSphere Application Server V6 (5-part series), http://www.ibm.com/developerworks/views/websphere/libraryview.jsp?search_by=Web+services+security+with+WebSphere+Application+Server+V6+--+Part
- Tivoli Directory Integrator Reference Guide, http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDI.doc_6.1/referenceguide.htm
- Tivoli Software Information Center, IBM Tivoli Identity Manager V4.6, http://publib.boulder.ibm.com/tividd/td/IdentityManager4.6.html
Dig deeper into Security on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Pragmatic, intelligent, risk-based IT Security practices.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.