Securing a composite business service delivered as a software-as-a-service: Part II, Supporting identity propagation (enterprise and federated SSO) and authorization

Using Tivoli Access Manager and Tivoli Federated Identity Manager

A composite business service (CBS) introduces many new challenges for security in an SOA solution. In this two-article series, a few security scenarios are examined in a proof-of-concept (PoC) CBS software-as-a-service (SaaS) application for banking called Jivaro. These scenarios help to identify when and how to apply different IBM Tivoli security products. In particular, scenarios for using IBM® Tivoli® Access Manager and Tivoli Federated Identity Manager (TFIM) for meeting SSO requirements in a CBS are described.

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 Engineer, 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), Staff Software Engineer, 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).



Zhi Gan (ganzhi@cn.ibm.com), Staff Software Engineer, 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.



Ying Chun Guo (guoyingc@cn.ibm.com), Software Engineer, 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.



27 September 2007

Introduction

A composite business service (CBS) integrates a set of fine-grained services with a business process using a Service Oriented Architecture (SOA). A CBS is often delivered as a software-as-a-service (SaaS). A CBS delivered as a SaaS introduces many new challenges for security, for example identity propagation across services spanning multiple tiers, security domains, and legacy applications.

Part 1 presented example non-functional security requirements for the Jivaro CBS SaaS application. And it demonstrated how multi-tenancy security requirements in Jivaro can be met using Tivoli Directory Server and Directory Integrator.

In Part 2, Tivoli Access Manager, Tivoli Federated Identity Manager (TFIM) (including the Security Token Service), and Tivoli Federated Identity Manager Business Gateway are being used to implement additional security (identity propagation and authorization) scenarios in the Jivaro proof of concept (PoC) SaaS application.

Supporting single sign-on for composite business services

Non-functional security requirements for a CBS often require consideration of identity propagation across different tiers of an application, across different security domains, and across legacy systems. Tivoli Access Manager (TAM) and Federated Identity Manager include several components that can be used to meet these requirements.

Single sign-on within the enterprise with Tivoli Access Manager

Figure 1. SSO with LTPA tokens generated by TAM WebSEAL
SSO with LTPA tokens generated by TAM WebSEAL

The Jivaro application is a typical Internet facing web application. It is protected with the help of a perimeter network (the De-militarized Zone DMZ) between the public Internet and the private intranet (as shown in Figure 1). The DMZ enforces the defense-in-depth principle of network design (see Defense in Depth, Wikipedia, in the Resources section). The Tivoli Access Manager (TAM) WebSEAL component was used in the DMZ to serve two purposes:

  1. Act as a reverse-proxy HTTP server
  2. Generate single sign-on tokens for IBM WebSphere® Portal Server and Process Server authentication

Figure 1 also shows the generation and flow of a WebSphere LTPA SSO token through the different tiers of the Jivaro CBS application:

  1. Step 1, a Jivaro Bank user logs in to the Jivaro portal. The request comes in through the DMZ to the TAM WebSEAL component.
  2. Step 2, TAM WebSEAL authenticates the user against the Jivaro LDAP user registry.
  3. Step 3, TAM WebSEAL generates a WebSphere LTPA token.
  4. Step 4, the token is sent to the Jivaro Portal in WebSphere Portal Server.
  5. In step 5, the token is validated by a TAM Trust Association Interceptor (TAI) configured in the Jivaro Portal Server against the common LDAP user registry. For more information on how to configure TAM WebSEAL with WebSphere Portal Server, please see: "Setting up WebSEAL" and "Configuring Tivoli Access Manager to perform Authentication only" in the Resources section.

Portlets in the Jivaro Portal Server were configured to propagate the LTPA token upon all invocations to back-end Web services in WebSphere Process Server. The ws:binarySecurityToken element in Web services portlet clients is used to pass the LTPA token. With WebSphere Portal Server V6.0, it is no longer necessary to use the credential vault to store credentials for back-end services, if the back-end is capable of accepting LTPA tokens (for example, WebSphere Process Server). Figure 2 and Figure 3 below show how to specify the use of an LTPA token for a portlet in Rational Application Developer.

Generate an LTPA token from a WebSphere Portlet for a back-end Web services invocation
Generate a LTPA token from a WebSphere Portlet for a back-end Web Services invocation
Figure 3. Generate an LTPA token from a WebSphere Portlet using IBM Rational® Application Developer
Generate a LTPA token from a WebSphere Portlet using Rational Application Developer

Extending single sign-on to legacy IBM CICS® applications using the TFIM STS component and the CICS Transaction Gateway

Composite business services often require secure integration with legacy components. The Tivoli Federated Identity Manager Security Token Service (TFIM STS) component and its integration with the CICS Transaction Gateway component were used to perform single sign-on to a backend legacy system such as a CICS transaction server. TFIM STS implements the Web Services Trust Language (WS-Trust) standard protocol for exchanging security tokens. TFIM STS can validate and issue a variety of security token types, including Security Assertion Markup Language (SAML) assertions and RACF Passtickets. It also supports conversion between token types using mapping rules written in XSLT. This enables security credentials encapsulated in different token formats to pass through different security domains.

In the Jivaro Bank, one of the bank accounts (Overseas account) is serviced in a legacy application in an IBM z/OS®-based CICS transaction server. Hence the Jivaro user's identity must be authenticated by the IBM z/OS Resource Access Control Facility (RACF®) before providing access to the financial information. With TFIM STS, the Jivaro user ID, b1u1, is mapped to a RACF used identity (for example, DNET618) and a RACF ticket (for example, 4UZ5PX9A) is issued.

When bank user John tries to view the corporate bank account balances, a SOAP request with an LTPA token is sent from the Jivaro WebSphere Portal to an EJB™- based application in the middle-tier WebSphere Portal Server (WPS). When the EJB tries to communicate with the CICS transaction server-based legacy application, a custom JAAS login module is used to communicate with TFIM STS and perform a token exchange. The user b1u1's credential, which is encapsulated in an LTPA token, is used as the basis for creating a new token, mapping the user's b1u1 identity for a RACF identity (DNET518), and creating the appropriate RACF Passticket. The RACF ID and Passticket allow the EJB application to communicate securely with the CICS application and get the account balances on John's behalf. Because this approach has allowed the invocation of the account balance application with a user-specific RACF ID, it is now possible to audit this event and tie it back to the user, John. These steps are depicted from left to right in Figure 9 from left to right.

For downloading the TFIM CICS Integration Pack and for more information on the STS component, see the article titled "End-to-end identity management for Web-based access to relational databases" in the Resources section.

Figure 9. Schematic showing SSO to legacy CICS transaction server using TFIM STS
Schematic showing SSO to legacy CICS transaction server using TFIM STS

Authorization for WebSphere Portal Server and Process Server components using Tivoli Access Manager

Figure 4. Centralized authorization policies in Tivoli Access Manager
Centralized authorization policies in Tivoli Access Manager

A Composite Business Service includes fine-grained components hosted in different tiers. The policy manager component in Tivoli Access Manager is used to externalize authorization policies for CBS components in WebSphere Portal and WebSphere Process Server, as described in Figure 4, to a centralized administration point. Externalizing authorization policies to a centralized policy administration point provides ease of management as well as consistency in security policies.

Authorization policies for WebSphere Portal Server components are defined in terms of RoleType@Resource. There is a set of predefined role types , for example, administrator, editor, and viewer. Resources are portlets or portal pages. For more details, see "External Authorization in Portal Server" in the Resources section.

Authorization policies for Service Component Architecture (SCA) components (for example, BPEL workflows) and Web services running in WebSphere Process Server are defined in terms of security roles. An SCA component exporting a Web service interface with a SOAP over HTTP binding is deployed to WebSphere Process Server in the form of session EJBs. Also all stand-alone Web services in the Jivaro Bank were implemented as session EJBs. For more information on Service Component Architecture, see the Resources section.

J2EE™ Role-Based Access Control (RBAC) policies were applied to secure our EJB implementations. A security role in J2EE RBAC is a collection of permissions. A permission specifies what action can be performed on which resource. A resource can be a J2EE EJB, which implements a Web service interface. An action can be any method defined in the component's interface, for example, an EJB method. For more information on J2EE RBAC, please see: "Security Role references in WebSphere Application Server" in the Resources section.

All protected CBS resources within the Jivaro security domain can be viewed using a virtual representation called the protected object space in the centralized TAM administration console. The protected object space is the logical and hierarchical portrayal of resources belonging to a security domain. Figure 5 below shows the protected object space for Portal Server and Process Server CBS components in the Jivaro security domain.

Figure 5. The Tivoli Access Manager protected object space for WebSphere Portal Server portlets (under portal) and WebSphere Process Server roles
The Tivoli Access Manager protected object space for WebSphere Portal Server and Process Server roles and portlets

The EJB Role ViewTransactions in the TAM protected object space

You can find more details on how to externalize Portal authorization policies to TAM in the Resource "External Authorization in WebSphere Portal Server".

The TAM Java Authorization Contract for Containers (JACC) provider was used to externalize the policy decision point for WebSphere Process Server to the TAM policy decision point. Details on how to export authorization policies and runtime policy decisions from WebSphere Process Server to Tivoli Access Manager can be found in the Resources section: "Propagating security policy of installed applications to a JACC provider".

Federated single sign-on for services in different security domains using Tivoli Federated Identity Manager

Federated single sign-on allows users to authenticate only one time when accessing resources in multiple security domains (for example,. yourService.com and yourPartnerService.com) within a trust boundary. The trust boundary encompasses an identity provider (IdP) and one or more service providers (SPs). A trust boundary is established with the help of business agreements, technology agreements and policies between the IdP and the SPs.

An identity assertion is created by the identity provider and carried one time on to the service provider when the user visits a service provider link in the identity provider's Web site. The assertion is used to determine who the user is, after which the service provider sets up its own form of "user recognition/session state management", usually with an SP-scoped HTTP cookie.

In the Jivaro Bank, third party services (for example, Credit Check Service) are provided to Jivaro Bank employees on the "Jivaro Information Center" intranet portal (see Figure 6)). Only authenticated Jivaro Bank employees are authorized to access this portal. When a bank employee, for example, John Smith, accesses a third party service from the portal, which participates in a trust federation with the Jivaro Bank, the employee does not need to authenticate again.

Figure 6. Trust federation between the Jivaro Bank and its business partners
Trust federation between the Jivaro bank and its business partners

TFIM is configured in the Jivaro Bank as the Identity Provider site. Therefore, S&R Ratings Service doesn't need to know explicitly about John Smith other than that he is an employee of Jivaro Bank and is authorized by Jivaro Bank to access S&R under their joint business agreements. When accessing "S&R Rating Services" from the Jivaro Bank, all user identities were mapped to the group user:"Jivaro_Emp" in S&R's Web site.

The following sequence of events (see Figure 7) takes place behind the scenes to allow John Smith to access Standard and Roop's third party Web site from the Jivaro Bank information center. Please note that the IdP (the blue-box in the left-most column) and the SP (blue box on the right-most column) are logically and physically separated TAM and TFIM environments. The Security Assertion Markup Language (SAML) v1.1 Browser Artifact profile standard was used for the F-SSO messages between the IdP and the SP (for more details on SAML, see the Resources section). Although this scenario depicts the usage of TAM and TFIM on both the IdP site and the SP site, it is important to note that it should be possible to interoperate with the SAML v1.1 standard-compliant IdP or SP implementations from other vendors.

Figure 7. Federated SSO between the Jivaro Bank IdP and the Standard and Roop Credit Check Service (SP) using the SAML v1.1 Browser Artifact profile
Federated SSO between the Jivaro bank IdP and the Standard and Roop Credit Check Service (SP) using the SAML v1.1 Browser Artifact profile
  1. Step 1, John Smith logs in to the Jivaro Bank Information Center which is the Identity Provider (IdP). This Web site is protected by the Tivoli Access Manager (TAM) WebSEAL component,
  2. Step 2, after successful authentication, the TAM Token is cached and the Jivaro Bank Information Center is displayed to John Smith.
  3. Step 3, John clicks on the "Standard and Roop's Credit Check Service", the Service Provider link (SP), in the Jivaro Bank Information Center portal. This is a special link, which doesn't connect to the Standard and Roop's Credit Check Service site (SP) directly. The request is actually sent to the IDP with a query string pointing to the SP target URL. This IDP site is sometimes referred to as the "Inter Site Transfer Service"
  4. Step 4, the IDP gets the request and creates an Identity Assertion for the SP target based on the identifier asserted by TAM in Step 2. The IdP stores this Identity Assertion with an "Artifact" pointer in the cache pool. Then, IDP returns a re-direct response to the client browser, which includes the "Artifact" pointer.
  5. Step 5, the browser is redirected to the SP with the "Artifact".
  6. Step 6, the SP gets this request and contacts the IDP with the "artifact" to request the real identity assertion through a Server-to-Server SOAP and HTTP back channel.
  7. Step 7, the IDP gets the request, and looks up the entry in the cache table of identity assertions using the "artifact" as an index. Upon finding the entry, it creates an actual identity assertion in SAML token format, which it sends back to the SP as a SOAP and HTTP response.
  8. Step 8, the SP extracts the user information from the received identity assertion. Based on John's role as a Jivaro employee and other attributes included in the assertion, the Standard and Roops credit check service identifies John as user:guest with an attribute of "JohnSmith" and another attribute/group membership of "Jivaro". A new token is created for TAM authentication on the SP site. Finally, after the local authentication succeeds, John Smith is allowed to access the "Standard&Roop CreditCheck" SP's service.

By using Tivoli Federated Identity Manager it is possible to provide:

  • Improved user experience because of single sign-on between CBS components residing in different security domains.
  • Seamless and secure integration for CBS.
  • Reduced cost of identity management for service providers, because each service provider needs to maintain only the attributes needed for their own service.

For more details on how to configure TFIM components at the identity provider site and at the service provider site, please refer to the resource: Tivoli Federated Identity Manager Configuration Guide.

Federated Single Sign-on for small service consumers using TFIM Business Gateway

Small- and medium-sized business partners often act as service consumers for Jivaro Bank services. TFIM Business Gateway (BG) was used for small service consumers and service providers to participate in federated single sign-on to services provided from the Jivaro Portal. TFIM BG v6.1.1 supports SAML v1.1 (not SAML v2.0) standard-based identity assertions. TFIM BG does not require a TAM infrastructure, and it is designed to integrate more closely with the existing native security configuration in the existing application environment. It also offers many other entry-level features for small- and medium-sized businesses (SMBs) for implementing federated single sign-on.

In an example scenario, employees of an SMB company, called PRC Checks Co. Ltd., were shown accessing their online corporate bank account through the Jivaro Bank Portal after authenticating only one time to the PRC Checks Co's local user registry. This scenario is depicted in Figure 8.

This scenario is similar to the TFIM scenario described in the section “Federated single sign-on for services in different security domains using Tivoli Federated Identity Manager” with the exception that, in this case, TFIM BG provides the lightweight identity provider solution applicable to SMB partners. This allows SMB partners to participate in a broader federation arrangement, for example allowing federated access from PRC Check Co to Jivaro Bank services.

Figure 8. Federated Single sign-on for small- and medium-sized businesses using TFIM Business Gateway
Federated Single sign-on for small and medium sized businesses using TFIM Business Gateway

For more details on how to configure TFIM BG, please refer to the resource: Tivoli Federated Identity Manager Business Gateway administration Guide.

Conclusions

In conclusion, the use of Tivoli Security Products was demonstrated for securing composite business services. In particular, new security issues surrounding identity propagation and single sign-on (both within a security domain and across multiple security domains) and centralization of authorization policies supporting secure composite business services were explored. It was also shown how these issues can be addressed at an architectural level by using the Tivoli security products: TAM and TFIM.


Animated demos

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 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 Heather Hinton, Senior Technical Staff Member, IBM Tivoli for contributing to the use cases for scenario and providing many helpful review comments. 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, Tivoli
ArticleID=254798
ArticleTitle=Securing a composite business service delivered as a software-as-a-service: Part II, Supporting identity propagation (enterprise and federated SSO) and authorization
publish-date=09272007