Authenticating a SAP login ticket in Tivoli Access Manager e-business WebSEAL

Using the external authentication C API

This article describes how to build an implementation of an authentication service using the IBM® Tivoli® Access Manager for e-business (TAMeb) WebSEAL External Authentication C API. The implementation of the authentication service extracts and validates the user name in an SAP Login Ticket (an HTTP cookie), then passes the user name to WebSEAL in order to build a credential. This article provides the source code and binary code of a prototype implementation.

Share:

Peter Tuton (ptuton@au1.ibm.com), Software Engineer, IBM

Peter TutonPeter Tuton is a Software Engineer in the Tivoli Security Integration Factory Team based on the Gold Coast, Australia. In this role, Peter is the Technical Lead for the team developing integration solutions for Tivoli Access Manager and Tivoli Federated Identity Manager. Peter has been involved in the certification of a number of IBM integration solutions with leading software companies, including Siebel, PeopleSoft and SAP.



Yaqian Fang (yaqfang@au1.ibm.com), Software Engineer, IBM

Yaqian FangYaqian Fang is a Software Engineer in the Tivoli Security Integration Factory Team based on the Gold Coast, Australia. Yaqian worked in QA team to test integration solutions for Tivoli Access Manager, Tivoli Federated Identity Manager, Tivoli Identity Manager and Tivoli Directory Integrator. Since July 2007, Yaqian has been working on development of data movement mechanism using Tivoli Directory Integrator for the ITSAS project.



07 May 2008

Introduction

With the growth of extensive networks, it is common for organizations to connect many dispersed systems with different security configurations into an intranet or extranet. Network users expect to navigate through the available systems without having to authenticate multiple times. Network administrators are required to configure systems to reduce the number of authentication requests. One typical example of such an environment is where multiple SAP systems are remotely located to each other (managed by separate departments) and are required to provide an uninterrupted user authentication experience.

TAMeb WebSEAL provides a flexible framework with functions that handle authentication operations that can be easily modified, extended and replaced. Two common options include the External Authentication C API and the External Authentication Interface (EAI). Chris Choi and Peter Cogill describe a comparison between these two mechanisms. This article describes how to make use of the External Authentication C API to customize the authentication process of users of such remotely connected SAP systems.

Scenario

This article considers two scenarios, as outlined below. After considering each scenario, the benefit of implementing an authentication service to customize the WebSEAL authentication process that allows for the processing of the SAP Login Ticket will be realized.

Two SAP systems are common to both scenarios: SAP-Europe and SAP-Asia. SAP-Europe is protected by TAMeb WebSEAL; while SAP-Asia is a stand-alone SAP system without external security policy management. Global users are required to access both systems in order to perform their duties.

Scenario 1: First accessing SAP-Europe via WebSEAL, and then accessing SAP-Asia

In this scenario, the user first accesses the SAP-Europe portal, which is protected by WebSEAL. The user then attempts to access the SAP-Asia portal. Trust has been configured between the SAP systems using documented SAP trust mechanisms.

Please refer to the SAP documentation: Configuring the system for issuing SAP logon tickets for more detail. Please refer to SAP documentation: Usage of SAP logon tickets for more detail about logon tickets. (You will need a valid SAP Marketplace account and the Adobe Reader).

Figure 1. Scenario 1 - Accessing SAP-Europe via WebSEAL first, then accessing SAP-Asia
Accessing SAP-Europe via WebSEAL first, then accessing SAP-Asia
  1. The user sends a browser request to the SAP-Europe portal through WebSEAL.
  2. WebSEAL intercepts the request and, if required, prompts the user for authentication credentials then authenticates the user against its user registry.
  3. WebSEAL forwards the request to SAP-Europe, with an HTTP header containing the username of the authenticated user.
  4. SAP-Europe validates the supplied user against its user registry, creating an SAP login ticket upon success.
  5. SAP-Europe generates the appropriate response and returns it to WebSEAL, along with the SAP login ticket (in the form of an HTTP cookie).
  6. WebSEAL performs filtering in accordance with the junction configuration and returns the response to the browser, including the SAP login ticket.
  7. The user then requires content from the SAP-Asia portal, which results in the browser sending another request; this time to SAP-Asia portal.
  8. SAP-Asia validates the SAP login ticket and authenticates the user against its user registry.
  9. Upon successful validation, the requested content is returned to the browser.

This scenario describes a solution that does not require the user to present authentication credentials more than one time. However, this is only possible when the user always first authenticates to WebSEAL that is protecting the SAP-Europe portal. This might not be an acceptable requirement.

This scenario makes use of the IBM developed and supported integration package available from IBM.

Scenario 2: First accessing SAP-Asia, and then accessing SAP-Europe via WebSEAL

This scenario considers the access order the other way around, that is, the user first authenticates to the SAP-Asia portal, and then requests content from the SAP-Europe portal via WebSEAL. As per the previous scenario, trust has been configured between the SAP systems using SAP trust mechanisms.

Figure 2. Scenario 2 - First accessing SAP-Asia, and then accessing SAP-Europe via WebSEAL
Accessing SAP-Asia first, then SAP-Europe via WebSEAL
  1. The user sends a browser request to SAP-Asia portal.
  2. The SAP-Asia portal accepts the request and, if required, prompts the user for authentication credentials then authenticates against its user registry; creating a SAP login ticket upon success.
  3. The content is returned to the browser along with the SAP login ticket (in the form of an HTTP cookie).
  4. The user now requires content from the SAP-Europe portal, resulting in the browser sending another request; this time to SAP-Europe portal. The request is intercepted by WebSEAL.
  5. WebSEAL prompts the user for authentication credentials and authenticates the user against its user registry.
  6. WebSEAL forwards the request to the SAP-Europe portal.
  7. SAP-Europe validates the user against its user registry.
  8. Upon successful validation, the content is returned along with the SAP login ticket.
  9. The requested content is returned to the browser, including the SAP login ticket.

Unfortunately, even with the inclusion of the IBM integration package, this scenario requires that the user enter authentication credentials two times; one time in Step 2 and again in Step 5. Ideally, the SAP login ticket created by the SAP-Asia portal can be trusted by WebSEAL in order to authenticate the request; therefore not requiring another prompt for authentication credentials.

Solution

The ideal solution addresses both scenarios by combining an integration solution between WebSEAL and the SAP-Europe system , which provides the SAP-Europe system with authentication credentials from WebSEAL - along with an implementation of a WebSEAL authentication service, to provide WebSEAL with authentication credentials from the SAP login ticket issued by SAP-Asia.

The integration solutions between WebSEAL and a SAP system are well documented in the IBM developed and supported integration packages. The integration solution between WebSEAL and SAP Netweaver Application Server ABAP 2004s is available at http://www-1.ibm.com/support/docview.wss?uid=swg24007296 and the integration solution between WebSEAL and SAP Netweaver Application Server Java™ is available at http://www-1.ibm.com/support/docview.wss?uid=swg24014570.

The authentication service uses the External Authentication C API to extract the SAP login ticket from the HTTP headers. This is done in conjunction with the WebSEAL cookie authentication functionality (added in version 6.0 Fixpack 3) that allows WebSEAL to extract an HTTP cookie from an incoming request and use its contents to create a credential. Additionally, the implementation makes use of the SAP-provided libraries allowing for the validation details contained in the SAP login ticket.

Note that the authentication service can use either the External Authentication C API or the EAI to provide the required functionality. However, SAP provides native C libraries to validate the SAP login ticket, therefore it makes sense to use the External Authentication C API. An equally valid solution can be implemented using an EAI approach.

An overview of the solution is illustrated in Figure 3. The accompanying text for Figure 3 describes scenario two; the steps for scenario one do not change.

Figure 3. Solution - Accessing SAP-Asia first, then SAP-Europe via WebSEAL using the External Authentication C API
Accessing SAP-Asia first, then SAP-Europe via WebSEAL using the External Authentication C API.
  1. The user sends a browser request to SAP-Asia portal.
  2. The SAP-Asia portal accepts the request and, if required, prompts the user for authentication credentials then authenticates against its user registry; creating a SAP login ticket upon success.
  3. The content is returned to the browser along with the SAP login ticket (in the form of an HTTP cookie).
  4. The user now requires content from the SAP-Europe portal, which results in the browser sending another request; this time to the SAP-Europe portal. The SAP login ticket created by SAP-Asia is included in the request. The request is intercepted by WebSEAL.
  5. WebSEAL determines that the request requires authentication, therefore calling the authentication service to process the request.
  6. The SAP login ticket is validated by the authentication service, the user name is extracted, and is passed to WebSEAL.
  7. WebSEAL validates the user exists in its user registry and creates a credential.
  8. Now that WebSEAL has a valid credential, it forwards the request to the SAP-Europe portal.
  9. SAP-Europe validates the user against its user registry.
  10. Upon successful validation, the content is returned along with the SAP login ticket.
  11. The requested content is returned to the browser, including the SAP login ticket.

The remaining sections of this article describe how to create and configure the software components in order to support the solution outlined above.


Implementation of the authentication service using the External Authentication C API

This section outlines the steps required to implement the authentication service using the External Authentication C API that extracts and validates the SAP login ticket, returning the username contained within it.

A prototype implementation has been provided with this article in the Downloads section.

Note:

The article assumes that the reader is familiar with the implementation of an external authentication mechanism. For complete details on the External Authentication C API, refer to the Tivoli Access Manager for e-business Web Security Developer Reference.

Initialization

During the authentication service initialization phase, the SAP-provided libraries for external SSO and security functionality must be loaded and initialized. Ideally, the parameters required for initializing the libraries should be passed to the authentication service xauthn_initialize() function.

Listing 1 provides a sample code snippet illustrating the gathering of required parameters and library initialization.

Listing 1. Fragment of the xauthn_initialize() function
xauthn_status_t xauthn_initialize (int argc,
	                          const char **argv)
{
  ...

  // Get the configuration data
  while (argc >= 1)
  {
    // Look for the SAP security library
    if (0 == strcmp ("-l", *argv))
    {
      if (--argc <= 0)
      {
        PrintHelp ();
        goto exception;
      }
      tConfigInfo.pszSecuLib = *(++argv);
    }

    //Look for the public key file
    else if (0 == strcmp ("-p", *argv))
    {
      if (--argc <= 0)
      {
        PrintHelp ();
        goto exception;
      }
      tConfigInfo.pszSecuLib = *(++argv);
    }

    // Look for the public key file password
    else if (0 == strcmp ("-w", *argv))
    {
      if (--argc <= 0)
      {
        PrintHelp ();
        goto exception;
      }
      tConfigInfo.pszPubKeyFilePassword = *(++argv);
    }

    //Look for the SAP security extension shared library
    else if (0 == strcmp ("-s", *argv))
    {
      if (--argc <= 0)
      {
        PrintHelp ();
        goto exception;
      }
      tConfigInfo.pszSSOExtFile = *(++argv);
    }
    argc--; argv++;
  }

  ...

  // Load the SAP security library
  if ( GetSsoLibrary(&tConfigInfo, &tITicketFunctions)
  {
    //Failed...
  }

  // Initialize the SAP security extensions library
  if ( SAP_O_K != (sap_status = tITicketFunctions.Initialize(tConfigInfo.pszSecuLib)))
  {
    printf ("Initialize function failed. ");
    printf ("The standard error code is %d. The SSF error code is %d.\n",
          GET_STD_ERROR(sap_status), GET_SSF_ERROR(sap_status));
    goto exception;
  }

  ...

  return XAUTHN_S_COMPLETE;
}

Authentication

The authentication service authentication phase is where the identity contained within the SAP login ticket is validated and returned to WebSEAL. At the very least, the SAP login ticket username should be returned to WebSEAL. Other attributes can be returned to WebSEAL in the form of extended attributes, details of which are in the Future work section.

Listing 2 provides a sample code snippet illustrating the authentication phase validating the SAP login ticket and returning the username to WebSEAL.

Listing 2. Fragment of the xauthn_authentication function
xauthn_status_t xauthn_authenticate(xnvlist_t *authnInfo,
                                    xauthn_identity_t *ident)
{
  ...

  // Init the ticket variable
  pszTicket = (char*)malloc(TICKET_BUFFER_LEN);
  if (pszTicket == NULL)
  {
    st = XAUTHN_S_OUT_OF_MEMORY;
    goto exception;
  }
  memset (pszTicket, 0, sizeof(TICKET_BUFFER_LEN));

  // Get the value of the cookie
  if ( XAUTHN_S_COMPLETE != (st = xnvlist_get(authnInfo,
      DEFAULT_COOKIE_NAME, &pszTicket, &nTicketLength)) )
  {
    printf ("Failed to get the value of the cookie.\n");
    goto exception;
  }

  // Validate the cookie/ticket
  if ( 0 != PerformValidation (&tConfigInfo, pszTicket, &tTicketData,
                               &tITicketFunctions) )
  {
    printf ("PerformValidation function failed with error: \n%s\n",
    GetExceptionBuffer());
    goto exception;
  }

  ...

  name = &ident->prin.data.dn;

  // Get the username
  if (0 != strlen(tTicketData.pszUserID))
    strcpy(username, tTicketData.pszUserID);
  else if (0 != strlen(tTicketData.pszPortalUser))
    strcpy(username, tTicketData.pszPortalUser);
  else
  {
    printf ("Failed to get the value of the username.\n");
    goto exception;
  }

  // Set the identities username
  *name = (char*)username;
  ident->prin.prin_type = principalType;

  ...

  return XAUTHN_S_COMPLETE;
}

Shutdown

The authentication service shutdown phase is the ideal location to shut down the SAP security library.

Listing 3 provides sample code illustrating the shutdown phase.

Listing 3. Fragment of the xauthn_shutdown functio.
xauthn_status_t xauthn_shutdown(int argc, const char **argv )
{
  printf("ENTER: xauthn_shutdown()\n");

  // Shutdown the SAP library
  tITicketFunctions.Shutdown();

  // Return complete
  printf("Exit: xauthn_shutdown()\n");
  return XAUTHN_S_COMPLETE;
}

Configuring the environment

This section outlines the process required to configure the solution environment in order to allow WebSEAL to accept and process the SAP login ticket.

Download the SAP libraries

As mentioned, a couple of SAP-provided libraries are required to implement the solution. The SAP libraries are available for download from the SAP Web site from the following location:

SAP Security Library and SAP SSOEXT Library

  1. Navigate to the SAP Software Distribution Center: https://websmp209.sap-ag.de/swdc. You will need a valid SAP account.
  2. On the left pane, select Download to expand the menu.
  3. Select Support Packages and Patches to expand the menu.
  4. Select Entry by Application Group.
  5. In the right pane, select Additional Components.
  6. From the list of components, select SAPSECULIB and then SAPSECULIB5.4.
  7. Select Download the Library for Your Platform.
  8. Back to Additional Components.
  9. From the list of components, select SAPSSOEXT.
  10. Select Download the Library for Your Platform.

Obtain the SAP issuing system’s public key

It is required that the public key of the SAP system that creates and issues the SAP Login Ticket be accessible to the authentication service. The SAP Web site contains detailed information on how to obtain the public key. The method differs for each SAP system.

If the issuing system is a SAP Portal (as per the scenarios), the following steps can be used to obtain the public key file:

  1. In the SAP Portal, choose System Administration -> System Configuration -> Keystore Administration.
  2. Choose Content.
  3. Scroll to the bottom of the screen.
  4. Choose to download verify.pse file.

Enabling HTTP header authentication

In order for WebSEAL to extract the SAP login ticket, in the form of an HTTP cookie, WebSEAL is required to be configured for cookie authentication.

Note:

Cookie authentication is available in WebSEAL 6.0 Fixpack 03.

Perform the following actions to configure WebSEAL for HTTP header authentication:

  1. Open the WebSEAL configuration file. For example, with a default installation of WebSEAL, the configuration file is located at WebSEAL_root/etc/webseald-default.conf.
  2. Locate the [http-headers] stanza.
  3. Specify the protocols to support in your network environment, for example, "http", "https", or "both".
  4. Create a new stanza named [auth-cookies].
  5. Create a new parameter within the new stanza called cookie.
  6. Set the value of the new parameter to MYSAPSSO.
  7. Within the [authentication-mechanisms] stanza, locate the http-request parameter.
  8. Set the http-request parameter to the value of the authentication service, ensuring that the parameters are appropriately passed, including:
    • a. The authentication service binary
    • b. The SAP Security library
    • c. The SAP public key file and
    • d. The SAP SSOEXT library

      For example: C:\Progra~1\Tivoli\PDWebRTE\Supp\authsaptoken.dll & -l [C:\Progra~1\Tivoli\PDWebRTE\Supp\sapsecu.dll] -p [C:\Progra~1\Tivoli\PDWebRTE\Supp\verify.pse] -s [C:\Progra~1\Tivoli\PDWebRTE\Supp\sapssoext.dll]

  9. Save the changes and restart WebSEAL.

In summary, the configuration file should contain the settings as per Listing 4.

Listing 4. WebSEAL configuration settings.
[authentication-mechanisms]
...
http-request = C:\Progra~1\Tivoli\PDWebRTE\Supp\authsaptoken.dll &
-l [C:\Progra~1\Tivoli\PDWebRTE\Supp\sapsecu.dll]
-p [C:\Progra~1\Tivoli\PDWebRTE\Supp\verify.pse]
-s [C:\Progra~1\Tivoli\PDWebRTE\Supp\sapssoext.dll]

[http-headers]
...
http-headers-auth = both

[auth-cookies]
...
cookie = MYSAPSSO

Testing the configuration

The most simple method for testing successful configuration is to login to a SAP issuing system, then attempt to login to WebSEAL. The user should not be prompted for authentication to WebSEAL.

An alternate method is to obtain an SAP login ticket from the SAP issuing system (by authenticating the SAP issuing system and capturing the MYSAPSSO2 cookie) and use a command line utility, such as cUrl to pass the cookie to WebSEAL.

Taking the cUrl application as an example, enter the following on the command line:

curl --cookie MYSAPSSO2=cookie_contents http://webseal-host/

Run WebSEAL in the foreground to obtain debug information from the authentication service. For example, at the command prompt, type:

C:\>webseald -foreground

Successful result

The expected result upon successful implementation and configuration should be similar to Listing 5.

Listing 5. Sample output of successful authentication
ENTER: xauthn_initialize()
xauthn_initialize() Parameters:
param[0] = -l
param[1] = C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\sapsecu.dll
param[2] = -p
param[3] = C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\verify.pse
param[4] = -s
param[5] = C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\sapssoext.dll
SecuLib:        C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\sapsecu.dll
PubKeyFile:     C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\verify.pse
PubKeyFilePW:   (null)
SSOExtFile:     C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\sapssoext.dll
EXIT: xauthn_initialize()
ENTER: xauthn_authenticate()
ENTER: PerformValidation()
EXIT: PerformValidation()
***********************************************

The ticket

AjExMDAgABRwb3J0YWw6QWRtaW5pc3RyYXRvcogAE2Jhc2ljYXV0aGVudGljYXRpb24BAAACAAMwMDA
AANKMkUEAAwyMDA3MTIxMjIzMjkFAAQAAAAICgAA%2FwD2MIHzBgkqhkiG9w0BBwKggeUwgeICAQExC
AJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGBwjCBvwIBATATMA4xDDAKBgNVBAMTA0oyRQIBADAJBgUrD
MCGgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMjEyMjMyO
AyWjAjBgkqhkiG9w0BCQQxFgQUM7RZp2uKhhr7rpU7WV9TyTNjWlAwCQYHKoZIzjgEAwQwMC4CFQDTd
7DbHzIEHCuY8ly201CXUVJzQIVAIJAFzECBsOVgSJbW8NX2QX6wXyo

was successfully validated.
User     :
Ident of ticket issuing system:
Sysid    : J2E
Client   : 000
External ident of user:
PortalUsr: Administrator
Auth     : basicauthentication
Ticket validity in seconds:
Valid (s): 453840
Certificate data of issuing system:
Subject  : CN=J2E
Issuer   : CN=J2E

***********************************************

username: Administrator

Troubleshooting

This section describes the troubleshooting methods for the output of the authentication service prototype. Three example failure cases are described: An expired ticket, a misplaced library file, and an invalid public key file.

Note: the standard error code and SSF error code

Definitions of the standard error code and SSF error code is in the sapssoext.h file from the SAPSSOEXT library package.

In most error cases, a problem has occurred in the SAP libraries. In such cases, the error is reported using a combination of two error codes - the "standard error code" and the "SSF error code". The remaining error cases are reported using an appropriate WebSEAL error code.

Expired ticket

The expected result upon an expired ticket should be similar to Listing 6.

Solution: Renew your SAP login ticket.

Listing 6. Sample output of expired ticket
DPWWA1125W   The data contained in the HTTP header MYSAPSSO2 failed authentication
ENTER: xauthn_authenticate()
ENTER: PerformValidation()
EXIT: PerformValidation()
PerformValidation function failed with error:
The SAP logon ticket could not be verified. The standard error code is 4. The SSF error code is 0.
2008-12-08-11:32:28.953+10:00I-----
0x13212073 webseald ERROR ias general e:\am600\src\libivacl\azn_authn.cpp 290 0x000005fc
HPDIA0115E   Unknown identity type.
2008-12-08-11:32:28.953+10:00I-----
0x38CF0465 webseald WARNING wwa http
s:\amweb600\src\pdweb\webseald\authn\framework\authn-getcreds.cpp 373 0x000005fc
DPWWA1125W   The data contained in the HTTP header MYSAPSSO2 failed authentication

Misplaced library file

The expected result upon a misplaced library file should be similar to Listing 7.

Solution: Examine your WebSEAL configuration file. Make sure that the correct path is supplied in the http-request parameter within the [authentication-mechanisms] stanza.

Listing 7. Sample output of misplaced library file
HPDIA0122E   Unable to open shared library 
C:\Progra~1\Tivoli\PDWebRTE\CreateDll\src\authsaptoken.dll: 126.
2007-12-08-11:29:02.078+10:00I-----
	0x13212066 webseald ERROR ias general e:\am600\src\ivauthn\ivpam.c 594 0x00000c2c
HPDIA0102E   Unable to open shared library.
2007-12-08-11:29:02.078+10:00I-----
	0x38CF013B webseald FATAL wwa server
	s:\amweb600\src\pdweb\webseald\daemon\webseald.cpp 709 0x00000c2c
DPWWA0315E   Initialization of authentication layer failed:
HPDIA0102E   Unable to open shared library.

Invalid public key file

The expected results upon an invalid public key file should be similar to Listing 8.

Solution: Examine your WebSEAL configuration file. Make sure that the correct path is supplied in thehttp-request parameter within the [authentication-mechanisms] stanza. Also make sure the PSE file is obtained from the right SAP system that you are using.

Listing 8. Sample output of invalid public key file
ENTER: xauthn_initialize()
xauthn_initialize() Parameters:
param[0] = -l
param[1] = C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\sapsecu.dll
param[2] = -p
param[3] = C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\verify.pse
param[4] = -s
param[5] = C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\sapssoext.dll
SecuLib:        C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\sapsecu.dll
PubKeyFile:     C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\verify.pse
PubKeyFilePW:   (null)
SSOExtFile:     C:\Program Files\Tivoli\PDWebRTE\CreateDll\src\sapssoext.dll
EXIT: xauthn_initialize()
ENTER: xauthn_authenticate()
ENTER: PerformValidation()
EXIT: PerformValidation()
PerformValidation function failed with error:
The SAP logon ticket could not be verified.The standard error code is 20. The SSF error code is 7.
2007-12-08-11:31:29.375+10:00I-----
0x13212073 webseald ERROR ias general e:\am600\src\libivacl\azn_authn.cpp 290 0x0000047c
HPDIA0115E   Unknown identity type.
2007-12-08-11:31:29.375+10:00I-----
0x38CF0465 webseald WARNING wwa http
s:\amweb600\src\pdweb\webseald\authn\framework\authn-getcreds.cpp 373 0x0000047c
DPWWA1125W   The data contained in the HTTP header MYSAPSSO2 failed authentication

Future work

Extending the WebSEAL credential

This article focuses on simply providing WebSEAL with the username contained in the SAP login ticket. However, a number of other attributes are available in the SAP login ticket that can be used for authorization purposes. The authenticate phase of the authentication service can be extended to include code that adds the additional attributes to the WebSEAL credential.

Additional attributes are added to the WebSEAL credential using the client identity that is returned to WebSEAL (xauthn_identity_t). Specifically, extended attributes are added to the xattr_list_t data structure. For complete details on how to extend xauthn_identity_t using the xattr_list_t data structure, refer to the Tivoli Access Manager for e-business Web Security Developer Reference.

The additional attributes that are available from the SAP login ticket include:

AttributeDescription
UserIDThe user ID used to authenticate to the SAP system (non-portal). This value is blank when the user authenticates to a SAP Portal system.
ClientThe SAP client number of the ticket issuing system to where the user authenticated.
SysidThe SAP sysid of the ticket issuing system to where the user authenticated.
PortalUserThe user name of the SAP portal user registry. Use this when the issuing system is an SAP Portal system.
AuthSchemeThe method of authentication to the SAP issuing system (defined in SAP as an "authentication scheme").
ValidityThe time, in seconds, of the ticket validity.
CertificateThe public certificate of the SAP issuing system. The certificate is Asn1 encoded, and any certificate information can be obtained.

Conclusion

This article describes how to build an implementation of an authentication service using the External Authentication C API that allows WebSEAL to authenticate a SAP login ticket, supplied by an SAP system. Moreover, it describes how to test and troubleshoot such an implementation. Finally, the article briefly describes how the authentication service can be extended to provide extended attributes that are contained in the SAP login ticket, therefore enhancing the authorization capabilities of WebSEAL.

The WebSEAL flexible authentication framework allows for environments with multiple authentication mechanisms to provide users with an uninterrupted authentication experience. In an environment with both WebSEAL and SAP systems, combining the WebSEAL authentication framework with SAP's login ticket validation libraries gives WebSEAL the ability to authenticate a user that was previously authenticated by an SAP system. Likewise, the WebSEAL ability to provide an SAP system with an authenticated user ID ensures that the user experience remains uninterrupted as the user traverses the company's network.


Downloads

DescriptionNameSize
Prototype implementation – source1authsaptoken_src.zip15KB
Prototype implementation – binaryauthsaptoken_bin.zip6KB

Note

  1. The sample source does not provide sapssoext.h and ssoload.c files. Both are required to build the binary code. These files are available in the ssosample folder in the SAPSSOEXT library package. Refer to the section "Download the SAP Libraries".

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 (service management), Tivoli
ArticleID=297874
ArticleTitle=Authenticating a SAP login ticket in Tivoli Access Manager e-business WebSEAL
publish-date=05072008