1 High level components and interaction

1.1 solution architecture for telecom mobile portal

Telecom gateways (i-mode, WAP 2.0/GPRS/3G gateways) have their own user authentication mechanisms. This means that the HTTP traffic coming from these gateways should already be authenticated. On the other hand, the telecom mobile portal also has its own user authentication mechanism. Thus, it becomes a problem if the mobile portal challenges and asks the user from the telecom gateways to sign on again. This problem cannot be neglected, as it is not convenient for users to input user ID and password on their handsets. In this article, we will propose an SSO solution to solve this problem. Our solution is based on WebSEAL. Figure 1 is the overall architecture.

There are three kinds of HTTP traffic. These traffic flows are described as follows: :

1. The HTTP traffic from some WAP 2.0 gateways is already authenticated and will carry the mobile phone number in the HTTP header. WebSEAL will trust these gateways, extract the mobile phone number from the HTTP header, and use the mobile phone number to sign on the mobile portal automatically. This traffic flow is marked with red dotted lines in Figure 1.
2. The HTTP traffic from i-mode, or some WAP 2.0 gateways carries the mobile phone number in other places instead of HTTP headers such as the URL query string, or the mobile phone number in the HTTP request will need to be preprocessed.(For example, Converting the hexadecimal ASCII codes to decimal string.) This kind of traffic needs to go through the HTTP header-preprocessing module (an integration plug-in provided in this article) This module extracts the mobile phone number and adds it to the HTTP header that will be used for SSO by WebSEAL. This traffic flow is marked with lines of blue dashes in Figure 1.
3. The HTTP traffic from the PC browsers will go to the HTTP header preprocessing module directly. Because no user identity is in the HTTP header, WebSEAL will challenge and authenticate this kind of traffic. This traffic flow is marked with green solid lines in Figure 1.

In the following sections, we will introduce:

• How the WebSEAL HTTP header SSO works.
• How i-mode and WAP 2.0 gateways carry the user identity with the HTTP traffic.
• How to configure WebSEAL to have SSO function for the HTTP traffic that has been already authenticated by the i-mode and WAP 2.0 gateways.
• How to build the solution described in Figure 1 by using WebSEAL.
• How to develop the HTTP header-preprocessing module for the traffic from the gateways that carries the mobile phone number in the places other than HTTP headers.

In the last section, we provide the alternative solutions by using TAMeb Web Server Plug-ins.

1.2 HTTP traffic flow from mobile devices to the mobile portal

Now let's see how the HTTP traffic flows from the 2/2.5/3 G mobile devices to the mobile portal:

1. The mobile devices will send the authentication request to the WAP gateway via RADIUS protocol.
2. The WAP gateway will perform the user authentication through the RADIUS server.
3. If it is a valid user, the connection is created and the handset can start sending the HTTP requests. When the WAP/GPRS/3G gateway receives the HTTP traffic, it inserts the mobile phone number into the HTTP cookies or HTTP headers and pass the HTTP traffic to the backend portal.

The i-mode Gateway is similar to the WAP gateway; however, the i-mode Gateway inserts the mobile phone number into the HTTP query string. An overall HTTP traffic flow is shown in Figure 2.

1.3 User authentication of WAP gateway

WAP gateway is used to convert the WAP (Wireless Application Protocol) traffic to HTTP traffic. Typically it uses a RADIUS server to perform the user authentication and accounting. A SIM card or Subscriber Identity Module is a portable memory chip used in some models of mobile phones. The SIM card contains personal identity information, cell phone number, phone book, and other data. The telephone numbers used to make and receive calls to the mobile phone is known as MSISDN, Mobile Station International Subscriber Directory Number. Since SIM is a user/subscriber identity, when the handsets connect to the WAP/GPRS/3G gateway successfully, it means the handsets have already passed the gateway's user authentication. Figure 3 is the architecture of user authentication of WAP gateway.

1.4 WebSEAL HTTP header SSO

The HTTP traffic might have already been authenticated before arriving at WebSEAL, such as the HTTP traffic coming from WAP/GPRS/3G or i-mode Gateway. In this case, we don't want WebSEAL to ask the users to sign on again. So, we need to have a SSO mechanism. Figure 4 shows a SSO scenario, in which, login information is embedded inside the HTTP header. This happens when the client has already been authenticated by other trusted gateways. Instead of having the user to input the credentials again, the login information can be put into the HTTP header for SSO purpose.

1. A client sends a HTTP request to access the resource on the protected web space, mobile portal.
2. The i-mode/WAP gateway receives the HTTP request. The gateways will check the authority of the client. In this case, the client has the authority.
3. The i-mode/WAP gateway inserts the client's mobile number into the HTTP request. The HTTP request is than forwarded to WebSEAL.
4. WebSEAL receives the HTTP request, and checks if the login session exists for the client. The login session is not found in this case. However, the SSO information can be extracted from the HTTP header. WebSEAL sends the SSO information to the authorization service.
5. The authorization service checks the protecting object policy (POP) to see if the client's IP is in the trust IP list. In this case, because the IP is the gateway's IP, it is in the trust IP list.
6. Authorization service recommends granting the access.
7. A login session is created.
8. WebSEAL redirects the request to the mobile portal.

Back to top

2 Identity information propagated by the mobile gateways

As we mentioned earlier, the mobile phone number, or MSISDN, is the user identity of the mobile handset. The WAP/GPRS/3G gateway or the i-mode Gateway stores the mobile phone number in the HTTP header, cookies, or query string respectively. It is important to know how the formats of these user identities are stored in the HTTP requests, so that we can retrieve them later for SSO authentication. In this section, we will show you the user identity of the Ericsson WAP Gateway, OpenWave WAP Gateway and i-mode Gateway.

2.1 User identity of Ericsson WAP gateway

The Ericsson WAP Gateway inserts the MSISDN into the HTTP_COOKIE header. The HTTP header value for Ericsson WAP Gateway 1.0 and for Ericsson WAP Gateway 3.0 is slightly different. As shown in Table 1, the MSISDN value is stored with the hex code format. For example, if the MSISDN is 88693974543, then User-Identity-Forward-msisdn=3838363933393734353433. We demonstrate how to extract the MSISDN number from the hex code format in the section "Develop a HTTP preprocessing module".

                
                 Ericsson WAP Gateway 1.0 (a comma at the end of the mobile phone number) 
   User-Identity-Forward-msisdn=383836393339373436353433,

 Ericsson WAP Gateway 3.0 (a semicolon at the end of the mobile phone number) 
   $Version=0;User-Identity-Forward-msisdn=383836393339373436353433;
      

2.2 User identity of OpenWave WAP Gateway

OpenWave WAP Gateway inserts the MSISDN in the HTTP_x-up-calling-line-id header. Unlike the Ericsson WAP Gateway, the value stored in the HTTP_x-up-calling-line-id is straightforward. For example, if the MSISDN is 886939746543, then HTTP_x-up-calling-line-id=886939746543, as shown in Table 2.

                

   HTTP_x-up-calling-line-id=886939746543
      

2.3 User identity of the i-mode Gateway

The i-mode Gateway inserts the MSISDN in the query string. As shown in Table 3, the query string contains multiple name-value pair attributes that are separated by "&" as the delimiter. The attribute name for the mobile phone number is "PN".

                
                 Query string 
    
 ...&PN=886939746543&parameter1=value1&...

      

Back to top

3 Develop and Configure the Solution

3.1 Develop a WebSphere Edge Component HTTP preprocessing module

As we mentioned earlier, the IBM WebSphere® Edge component provides the plug-in feature that allows users to write their own program to process the intercepted HTTP request. In this section, we demonstrate how to develop the dWork plug-in. We design a pre-processing plug-in that extracts the user identity, MSISDN, from each gateway's HTTP request and sets this user identity to the WebSEAL SSO HTTP header. You can download the source codes from the downloads section of this article. The plug-in was developed for running on the AIX® platform. So, if you want to revise the source codes, you need to prepare the IBM XL C/C++ V8.0 for AIX. For more information about XL C/C++, please refer to http://www-306.ibm.com/software/awdtools/xlcpp/ for more details. You are required to apply the latest fix packs after installing XL C/C++ 8.0; otherwise a linking error is generated (http://www-1.ibm.com/support/docview.wss?uid=swg1IY91535 ) when compiling the dWork plug-in. To compile, you need to copy the source code to the /home/dWork directory and execute the ./build.sh script. The dWork plug-in shared library will be successfully generated under the /home/dWork/lib directory. For more details about how to develop the Caching Proxy plug-in, refer to http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp the WebSphere Application Server InfoCenter, and search "Edge component". The detailed description for the source code list of the dWork plug-in is in Table 4.

We will go through the more detailed descriptions of the logic in the source codes. The snippet of dWork plug-in is shown as Example 3. Let's take a closer look at how the dWork plug-in works if we use Ericsson WAP Gateway as an example.

1. In Step 1, it gets the values of the HTTP_COOKIE because Ericsson WAP Gateway puts the mobile phone number there.
2. In Step 2, it extracts the raw MSISDN from the HTTP header HTTP_COOKIE inserted by Ericsson WAP gateway. In Example 4, you can easily observe that the TAMeb SSO HTTP header is prepared by extracting the MSISDN string from HTTP_COOKIE and cascading it with a TAMeb realm name.
3. In Step 3, it inserts the MSISDN that prepared in the previous step to the HTTP header for WebSEAL SSO HTTP header. If the HTTP traffic does not come from the gateways, we need to remove the HTTP header for WebSEAL SSO HTTP header.

With these three steps, a general mobile SSO plug-in for telecom mobile portal is almost complete. If you want to support other types of gateways, you can revise the codes base on the characteristics of the gateways. In some cases, if the user identities in the TAMeb are not users' mobile phone numbers, you can easily revise the codes to map the mobile phone number to the TAMeb user identities.

                

//Entry point of the Caching Proxy plugin
extern "C" void HTTPD_LINKAGE mobileSSO(unsigned char *handle, long *return_code) {

    occurrence = 0;
<Step 1>
                httpcookievalue = httpd_getvar(handle, (unsigned char *)HTTP_COOKIE, &occurrence);
remoteAddress = httpd_getvar(handle, (unsigned char *)REMOTE_ADDR, &occurrence);
...
...
...

      //Ericsson WAP 2.0 Gateway
    } else if ( !strcmp((const char*)remoteAddress, ProfileData::ERICSSON_GATEWAY_IP)) {
	      .....
<Step 2>
                result=getEricssonMSISDN(httpcookievalue,MSISDN);
...
...
...
} else {
	printf("The HTTP traffic comes from non-Gateway IP %s.\n",(const char*)remoteAddress);
	result = 500;
}
if (result==0) {
	//insert the MSISDN to the HTTP header for WebSEAL Sign Token into HTTP header
<Step 3>
                returnValue = httpd_setvar(handle, 
                                                  (unsigned char*)TAM_SSO_TOKEN,
                                                  (unsigned char *)(const char *)MSISDN,
                                                  (unsigned long*)HTTPD_SETVAR_REPLACE_ADD);
...
...
...
} else {
            //Need to remove the TAM_SSO_TOKEN if the HTTP traffic is not from the
                            //i-mode or WAP gateway. This is to prevent the hackers to send the
                            //HTTP request and insert the TAM_SSO_TOKEN.
                            printf("Can't get the MSISDN for SSO. The reason code is %d.\n", result);
                            printf("Remove %s for security reason.\n", (unsigned char*)TAM_SSO_TOKEN);
                            returnValue = httpd_setvar(handle, (unsigned char*)TAM_SSO_TOKEN,
                                     (unsigned char *)blank, (unsigned long*)HTTPD_SETVAR_REMOVE_ALL);
	}
}

      

In the next section, we use the Ericsson WAP Gateway as an example to explain how to get the MSISDN. If you want to know more about how it works on OpenWave and i-mode gateways, please refer to the source codes provided in this article.

3.1.1 Ericsson WAP Gateway

As we mentioned earlier, the Ericsson WAP Gateway inserts the MSISDN in the HTTP_COOKIE header. Since the HTTP_COOKIE value is with the hex code format, we use Example 4 as an example to demonstrate how to extract the MSISDN value for Ericsson. The major codes used to extract the mobile phone number are marked with boldface text.

                
int getEricssonMSISDN(const unsigned char *longStr, char *MSISDN) {
   ...
   ...
   ...
   msisdnStr=strstr((char *)longStr,
                                   (const char *)"User-Identity-Forward-msisdn");
   if (msisdnStr==NULL) {
       printf("Can't find MSISDN in the %s.\n", HTTP_COOKIE);
       return 102;  
   }
   //If we could find "User-Identity-Forward-msisdn" in the HTTP_COOKIE,
   //continue to parse the cookie with delimiter ";" or ","
   //EricssonWG 1.0 uses "," and 3.0 uses ";" as the delimiter 
   msisdnStr=strtok(msisdnStr,(const char *)",;");
   if (msisdnStr==NULL){
       printf("Can't find the correct MSISDN format string in the %s.\n", HTTP_COOKIE);
       return 103;
   }
   //Continue to parse the cookie with delimeter "="
   msisdnStr=strtok(msisdnStr,(const char *)"=");
   if (msisdnStr==NULL){
       printf("Can't find the correct MSISDN format string in the %.\n",HTTP_COOKIE);
       return 104;
   } 
   //Extract the string before the delimeter "="  
   msisdnStr=strtok(NULL,(const char *)"=");
   if (msisdnStr==NULL) {
	   printf("Can't find the correct MSISDN format string in the %s.\n", HTTP_COOKIE);
       return 105;
   }
   ...
   ...
   ...
   //Extract the MSISDN from the hex code format. We could just simply extract
   //the even digit of the string
   for (i=1; i<length; i=i+2){
                       MSISDN[j++]=msisdnStr[i];
                   }
                   MSISDN[j]=0x0;                  //Null end of String
   strcat(MSISDN,ProfileData::TAM_REALM_NAME);
   return 0;                       //return 0 if the processing is successful.
}

      

3.2 Configure the dWork plug-in to Caching Proxy

After showing you how to build the dWork plug-in, we now show you how to configure the dWork plug-in in the Caching Proxy.

1. Copy /home/dWork/lib/dWorkPlugin.so to /usr/lib. Make sure the file has the readable permission. (Use chmod +r /usr/lib/dWorkPlugin.so command.)
2. Copy /home/dWork/etc/dWork.conf to /etc/dWork.conf. Make sure the file has the readable permission. (Use chmod +r /etc/dWork.conf)
3. Check the configurations of /etc/dWork.conf. Make sure the IP addresses of the gateways are correct.
4. Revise the Caching Proxy configuration file /etc/ibmproxy.conf as follows. (Before revising the file, we suggest that you back it up.)
5. Restart the Caching Proxy (Use "stopsrc -s ibmproxy" to stop the Caching Proxy; Use "startsrc -s ibmproxy" to start the Caching Proxy )

                

### Following are the configurations for dWork plug-in ###
### These configurations should be in the ibmproxy.conf file. ###
# ===================================================================== #
#API directives:
# ===================================================================== #
### dWork Plug-in configurations ###
ServerInit /usr/lib/dWorkPlugin.so:InitdWork /etc/dWork.conf
PreExit /usr/lib/dWorkPlugin.so:mobileSSO
...
...
...

# ===================================================================== #
#
#        Mapping rules
#
# ===================================================================== #
...
...
...
### Define the mapping rule to route the request to WebSEAL server.           ###
                ### For example: Assume the host name of the caching proxy is server0.ibm.com ###
                ### The host name of WebSEAL is server1.tw.ibm.com                            ###
                ### The http request http://server0.ibm.com/webseal/webservice1               ###
                ### will be routed to http://server1.ibm.com/webservice1                      ###
                Proxy /webseal/*	http://server1.ibm.com/*
            

3.3 Configuration of WebSEAL

3.3.1 Configuration of header authentication

In this section, we show you how to configure the WebSEAL HTTP header authentication. It is configured through the WebSEAL configuration file, webseald-instance_name.conf. The file is located in one of the following directories.

                
On Linux and UNIX:
/opt/pdweb/etc

On Windows:
<WebSEAL home directory>\etc

      

To define HTTP header authentication, we need to find and change the following parameters. In Example 1, we use X-IBM-PVC-User as the trusted HTTP header.

                

ba-auth = none
...
mpa = no
...
require-mpa = no
...
ssl-id-sessions = no 
...
[session-http-headers]
X-IBM-PVC-User  = http
X-IBM-PVC-User = https
...
[http-headers]
http-headers-auth = both
...
[auth-headers]
header = X-IBM-PVC-User
...
[authentication-mechanisms]
http-request = <Your customized XAUTHN module (see the note below).
############## For example: /usr/lib/libauthn.so #################

   

3.3.2 Restrict access to WebSEAL

Since we only allow mobile gateways to access WebSEAL, we need to define a trust IP list. The trust IP list restricts access, so that only allows trusted clients can perform authentication and authorization with the WebSEAL server. This can be achieved by attaching protecting object policy (POP) to the objects in TAMeb object space. To define a trust IP list, we need to login into the pdadmin utility with an administrator account. Then, follow the steps in Example 2. In this example, we attach the protecting object policy to the root of the WebSEAL object space. The IP address of the i-mode, WAP 2.0/GRPS/3G gateways should be defined in the trust IP list.

                
pdadmin sec_master> pop create poptest1
pdadmin sec_master> pop modify poptest1 set ipauth anyothernw forbidden
pdadmin sec_master> pop modify poptest1 set ipauth add <trusted client IP>
255.255.255.255 0
pdadmin sec_master> pop attach /WebSEAL poptest1
   

In order to make sure the protecting object policy works properly, we need to make sure the user account does not have the "R" (bypass pop rule) action bit set in the ACL. Following are the commands to find the action bits of the user account:

1. Use the object show <object name> command to find out the attached ACL on the object.
2. Use acl show <acl name> to find the action bits of the users or groups in ACL.

3.3.3 Test the WebSEAL SSO

An easy way to test the SSO is to use the Linux® curl command. "curl" allows users to send HTTP requests with customized HTTP headers and cookies. If the junction setting is not set up correctly, you will get the sign-on page. Since we are using the curl command to simulate the HTTP traffic from the i-mode/WAP 2.0/GPRS/3G gateways, we need to set the IP address of the machine used to run the curl command to the trust IP list.

                
# curl -H "X-IBM-PVC-User: sec_master" http://server1.ibm.com/webservice1
      

Where sec_master is the default administrator user ID for Tivoli Access Manager. The URL http://server1.ibm.com/webservice1 is mapped to the page http://server2.ibm.com.

3.4 Testing the integrated solution

This section shows an end-to-end HTTP traffic flow test of the SSO between Ericsson/OpenWave/i-mode gateway and WebSEAL. If you don't have real WAP or i-mode gateways for the test, you can simulate the HTTP traffic by using the curl command. Before starting the test, you need to create users in TAMeb by using the mobile phone number as the user ID. For example, you can create a user ID 886939746543 in TAMeb. The HTTP traffic initiated from the curl test machine (assume the IP of the curl test machine is 172.16.136.126) goes through the caching proxy. Therefore, you need to make sure the caching proxy's IP is correctly configured as the WebSEAL trust IP POP, as described in section "Restrict Access to WebSEAL". This gateway IP (172.16.136.126) needs to be updated in the /etc/dWork.conf file, too. We will use the Ericsson WAP Gateway as an example to demonstrate the testing procedures step by step.

1. Update the /etc/dWork.conf file and make sure that 172.16.136.126 is the IP address for Ericsson WAP Gateway.
   
   Example 6. Sample /etc/dWork.conf file for Ericsson WAP Gateway
   

   IMODE_GATEWAY_IP 10.10.1.1 ERICSSON_GATEWAY_IP 172.16.136.126 OPENWAVE_GATEWAY_IP 10.10.1.3 TAM_REALM_NAME @IBM

   
   
2. Restart the Caching Proxy to make the change in /etc/dWork.conf effective.
3. Make sure the caching proxy's IP is correctly configured as the WebSEAL trust IP POP.
4. Use the curl command to simulate HTTP traffic from the Ericsson/OpenWave/i-mode WAP gateway

   // Assume server0.ibm.com is the caching proxy. // For HTTP traffic from Ericsson WAP Gateway # curl -b "User-Identity-Forward-msisdn=383836393339373436353433" http://server0.ibm.com/webseal/webservice1 // For HTTP traffic from OpenWave WAP 2.0 Gateway # curl -H "x-up-calling-line-id:886939746543" http://server0.ibm.com/webseal/webservice1 // For HTTP traffic from i-mode Gateway # curl http://server0.ibm.com/webseal/webservice1?PN=886939746543

   
   
5. Make sure the response contents are not in login form.

Back to top

4 Alternative solution using TAMeb Web Server Plug-in

Like WebSEAL, Plug-in for Web Servers is the alternative resource manager that also supports HTTP header authentication and authorization. Similar configuration concepts can be applied to their configuration files as the case with webseald-instance_name.conf. The following sections will show you the architecture and configurations when using TAMeb plug-in for Web Servers.

4.1 component architecture

Figure 5 is the overall architecture if we use the TAMeb plug-in for Web Servers to replace WebSEAL as the authentication and authorization resource manager.

4.2 Configuration of HTTP header authentication

1. Stop TAMeb Plug-in for Web Servers
2. Locate the TAMeb Plug-in for Web Servers configuration file. It is named pdwebpi.conf.
3. Find the common-modules stanza, and set the value of the authentication parameter to http-hdr as shown below.

   [common-modules] authentication = http-hdr

   
   
4. Find the modules stanza, and set the value of the http-hdr parameter to pdwpi-httphdr-module as seen below

   [modules] http-hdr = pdwpi-httphdr-module

   
   
5. Below the modules stanza, add an http-hdr stanza. Set the value of the header parameter to the header name of your choice as seen below.

   [http-hdr] header = <header name> ## In this article, we use X-IBM-PVC-User ##

   
   
6. Find the authentication-mechanisms stanza, and set the value of the http-request parameter to the location of your customized XAUTHN module.
   
   For example:
   

   [authentication-mechanisms] http-request = <the location of your customized XAUTHN module> ## In this article, we use /usr/lib/libauthn.so ##

   
   
7. Start the TAMeb Plug-in for Web Servers.

Back to top

5 Summary

In this article, we have shown you an SSO solution of TAMeb and WAP/GPRS/3G or i-mode gateways. The solution can be used to build telecom mobile portals for multiple devices. We use Ericsson, OpenWave WAP 2.0 Gateway and i-mode Gateway as examples to develop a Caching Proxy plug-in for SSO with WebSEAL or TAMeb plug-in. This solution can be a good reference for the telecom mobile portal solution architect. The sample implementation will be a very useful solution asset that can be easily revised for different kinds of gateways (for example, it could be revised for Nokia WAP gateway). After reading this article, you can easily revise the source codes to fit the requirements of your mobile portal.

Back to top

Downloads

Information about download methods

Resources

Learn

• Get more information about Tivoli Access Manager from the Tivoli Access Manager Infocenter.
  
  
• Get more information about Tivoli Access Manager WebSEAL Administration Guide from the Tivoli Access Manager Infocenter.
  
  
• Learn more about how to write XAUTHN module from Tivoli Access Manager for e-business Web Security Developer Reference from the Tivoli Access Manager Infocenter.
  
  
• Get more information about "WebSphere Application Server" from the WebSphere Application Server 6.1 Infocenter.
  
  
• Get more information about WebSphere Application Server Edge Component from WebSphere Application Server Edge Component Infocenter.
  
  
• Get more information about curl from curl command man page.
  
  
• Learn more information about Ericsson WAP Gateway.
  
  
• Learn more information about OpenWave Mobile Access Gateway.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM XL C/C++ v8.0 for AIX and IBM XL C/C++ v8.0 for AIX APAR Fix
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Rick Wu is a Software Engineering Manager at IBM China Software Development in Taipei, Taiwan. His areas of expertise include pervasive computing, telecom solutions, and RFID solutions. He is now working on Lotus Expeditor development and test.

Rebecca Chen is a Staff Software Engineer at IBM China Software Development Lab in Taipei, Taiwan. Her areas of expertise include pervasive computing, telecom solutions, and RFID solutions. She leads a team of Software Engineers working on performance tuning for IBM Telecom solution products.

Andrew Tsai is a Software Engineer at IBM China Software Development Lab in Taipei, Taiwan. He is now working on GUI automation testing tools and process deployment, Globalization Verification Testing (GVT), Translation Verification Testing (TVT), and Lab-Based Service (LBS) support for telecom solutions.

Deepak Kaul is a Staff Software Engineer with ISL Pune, He is CISSP Certified and has been Certified by IBM as Advanced Deployment Professional Tivoli Security Management Solution. He has been Working with Information Security Products from Last 7 years. He has been with IBM from last 3 years working on Security Products like Tivoli Access Manager and Tivoli Identity Manager.Deepak holds a Bachelors Degree for Computer Engineering from University of Mumbai.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• 1 High level components and interaction
• 2 Identity information propagated by the mobile gateways
• 3 Develop and Configure the Solution
• 4 Alternative solution using TAMeb Web Server Plug-in
• 5 Summary
• Downloads
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Tivoli Access Manager for Enterprise Single Sign-on
• Briefing: Introduction to Tivoli service management environment
• Buy: Tivoli Access Manager for Enterprise Single Sign-on

My developerWorks community

Dig deeper into Tivoli on developerWorks

Cloud computing for developers

Virtual workshop: Learn how to build a cloud infrastructure and develop/deploy cloud-based applications. (6-8 Apr 2010)

Special offers