How-to Guide How-to Guide SAP NetWeaver ‘04 SAP NetWeaver ‘04

How to Configure

How to Configure Single Sign-On in a Complex System Landscape Version 1.00 – Jan 2005 Applicable Releases: SAP NetWeaver ’04

© Copyright 2004 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. SAP NetWeaver “How-to” Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, clarification or support, please refer to SAP Consulting.

1 BUSINESS SCENARIO.............................................................................1

2 INTRODUCTION .....................................................................................1

3 CONFIGURATION FOR ACCEPTING SSO ............................................2

3.1 SAP WebAS J2EE....................................................................................................................2 3.1.1 Configuring the J2EE Engine to Accept Logon Tickets........................................................2 3.1.2 Java Application ....................................................................................................................5

3.1.2.1 Typical Java Application .............................................................................................6 3.1.2.2 WebDynpro..................................................................................................................6 3.1.2.3 Web Services ...............................................................................................................7

3.2 SAP Web AS ABAP .................................................................................................................7

4 CONFIGURATION FOR SENDING SSO ...............................................10

4.1 SAP Enterprise Portal ...........................................................................................................10

4.2 SAP Web AS J2EE.................................................................................................................10 4.2.1 Setting up a Web Dynpro Application for a Logon Ticket..................................................10 4.2.2 Configuring the Web Service Destination to Send SAP Logon Ticket ...............................12 4.2.3 Configuring the HTTP Destination to Send SAP Logon Ticket..........................................14 4.2.4 Manual (Code) Connections................................................................................................15

4.2.4.1 HTTP .........................................................................................................................15 4.2.4.2 JCO ............................................................................................................................16

4.3 SAP Web AS ABAP ...............................................................................................................16

5 APPENDIX .............................................................................................18

5.1 SSO Cross Domain.................................................................................................................18

5.2 SAP XI.....................................................................................................................................18

1 Business Scenario

Many applications are distributed on two or more SAP NetWeaver components. It is becoming essential for users who authenticate against one system for his credentials to propagate to all others so that he won't have to re-authenticate in every other system. For security reasons, storing password information in the user session is not recommended. In many cases, the password of the user in one system is not the same as the password in other systems. Some solutions offer connections of "System User" to other systems, passing the original user as a parameter; but because of authorization, logging, and legal issues (Sarbanes-Oxley Act of 2002), this solution is not always possible. The solution is Single Sign-On (SSO). With SSO, a token is passed between all trusted systems that have been configured as such; each system is then able to identify the user and authenticate him without a password.

2 Introduction

In a complex system landscape with several components, the only way of guaranteeing SSO between all the components is to use the SAP logon ticket. When setting up SSO with logon tickets, you need to identify one system as the ticket issuer. After a user logs on to a system using a supported authentication mechanism, the system issues the user an SAP logon ticket. It is recommended that you identify one system in your system landscape as the ticket-issuing system, then configure all other systems to accept tickets from this system. For example, if you have a portal in your system landscape, you could define this system to be the ticket-issuing system and, as a result, users would have to access all applications and services through the portal to ensure Single Sign-On. Once you have defined one system to be the ticket-issuing system, you can configure all other components in the system landscape to accept tickets from this system. In rare situations, two systems can be made the ticket-issuing systems, so that all other systems need to be configured to accept tickets from both servers.

3 Configuration for Accepting SSO

In order to configure a system to work with SSO, a trust relationship has to be established between the systems involved. This section will cover the configuration of Web AS J2EE and Web AS ABAP systems as a receiving side.

3.1 SAP WebAS J2EE

3.1.1 Configuring the J2EE Engine to Accept Logon Tickets

Use To check the validity of a user’s logon ticket, the J2EE Engine must be able to verify the issuing server’s digital signature. If the J2EE Engine is both the ticket-issuing server as well as the accepting server, then it can automatically verify its own digital signature. However, if the ticket-issuing server is a different one, then you must import this server’s public-key certificate (or its issuing CA’s root certificate) into the keystore view that the J2EE Engine uses for verifying logon tickets. In addition, the J2EE Engine should only accept logon tickets issued from a trusted server. To specify another server as a trusted ticket-issuing server, you must enter its identity in the login module options on the J2EE Engine.

As a default, the J2EE Engine automatically accepts its own logon tickets. Therefore, if the J2EE Engine is both the issuer and receiver, then you can omit this procedure.

Prerequisites The login module stacks for applications that will accept logon tickets contain the login module EvaluateTicketLoginModule as described in Adjusting the Login Module Stacks for Using Logon Tickets [External].

For system connections between the SAP Web AS ABAP and the J2EE Engine that use the authentication assertion ticket, the corresponding module is EvaluateAssertionTicketLoginModule.

Procedure 1. Import this certificate into the TicketKeystore view on the accepting J2EE Engine:

a. Logon to the Visual Administrator and go to Server Services Key Storage.

b. Using the Key Storage service on the accepting server, select the TicketKeystore view.

c. Choose Load. d. Select the file from the file system and choose OK.

The certificate is stored in the selected view as a CERTIFICATE entry. (See Figure-1)

Figure 1 – TicketKeystore View

2. Pay attention to the server’s Distinguished Name ([DN]) and the issuer’s Distinguished Name ([IssuerDN]) since you will need these two Distinguished Names for the access control list (ACL) entries in the next step.

3. Maintain the logon ticket access control list in the options for the login module EvaluateTicketLoginModule:

a. Go to Server Services Security Provider User Management b. Select User Management tab and in the User Stores select UME User

Store. c. In the Login Modules select EvaluateTicketLoginModule and click

View/Change Properties. d. Under Options, make the following entries for each ticket-issuing server

from which the J2EE Engine should accept logon tickets:

Access Control List Entries Name Value trustedsys<x>

<SID>, <Client>

Use 000 as the client if the issuer is a J2EE Engine.

trustediss<x>

<Issuer’s_Distinguished_Name> Distinguished Name of the issuer of the ticket issuing system’s public-key certificate.

trusteddn<x>

<System’s_Distinguished_Name> Distinguished Name of the ticket-issuing system.

If the ticket-issuing system uses a self-signed certificate, then these two Distinguished Names are identical. Also, the corresponding public-key certificate must exist in the SAPLogonTicket keystore view entry.

If all applications are to accept logon tickets, then make the ACL entries in the corresponding template. Otherwise make the entries for all of the applications that are to accept logon tickets individually. Pay attention when you copy the DN characters, as any incompatibility or mismatch will cause the SSO not to work. In some cases in the EP, the DN can be long and since the width of the text field is limited, some of the characters are hidden, so make sure to scroll right while copying the DN in order to copy all characters.

Example The following example shows an access control list for the J2EE Engine that should accept logon tickets that have either been issued by the SAP System ABC, client 100 and from the J2EE Engine with the system ID J2E.

Figure 2 - Sample Access Control List Entries

Result The J2EE Engine accepts logon tickets that have been issued by the corresponding server. Continue with Testing the Use of Logon Tickets [External].

3.1.2 Java Application Use To make sure your Java application accepts Single Sign-On connections. Prerequisites You have administration permission for the J2EE Engine or SAP Enterprise Portal. When the source server is the ticket issuing system, you have set up the destination server to accept ticket from the source server. See Configuring the J2EE Engine to Accept Logon Tickets and Configuring the SAP Web AS ABAP to Accept SAP Logon Tickets.

Procedure

3.1.2.1 Typical Java Application If you already have deployed your Java application and you want to configure it to accept Single Sign-On connections, you need to go to the Visual Administrator and add to the application the EvaluateTicketLoginModule.

1. Open Visual Administrator and go to Server Services Security Provider. 2. Make sure the Runtime/Policy Configurations tab is selected. 3. Find your application and click on it. 4. If EvaluateTicketLoginModule doesn't appear in Authentication tab, click on Add

New button and add this module (See Figure 3). More information about configuring Login Modules can be found here: Adjusting the Login Module Stacks for Using Logon Tickets [External].

Figure 3 - Application LoginModule Configuration

3.1.2.2 WebDynpro The login module stack for the WebDynpro application contains the login module EvaluateTicketLoginModule. This login module verifies users’ logon tickets when they access the application. By default, all Web Dynpro applications that are activated for authentication use the ticket Authentication template, which contains EvaluateTicketLoginModule.

3.1.2.3 Web Services If your EJB module is exposing some services as web services, it is possible to configure the web service to accept SAP Logon Tickets during development or later on at deployment through the Visual Administrator, like any other application. • Configuration during development:

1. In your EJB project in the SAP NetWeaver Developer Studio, open the Web Service Configurations.

2. Expand the web service name and the config name. 3. Open the Security item. 4. If Authentication Mechanism is "None," select HTTP Authentication. 5. Check the Use SAP Logon Ticket checkbox.

• Configuration during deployment:

Configuration of the web service after deployment is like configuration of a Java application. See Typical Java Applications section 3.1.2.1 for more details.

3.2 SAP Web AS ABAP Configuring the SAP Web AS ABAP to Accept SAP Logon Tickets Use If you want to use Single Sign-On between the J2EE Engine and an SAP Web AS ABAP system, then you must configure the corresponding SAP Web AS ABAP application server to accept logon tickets accordingly. Prerequisites The public-key certificate to use for verifying the Web AS digital signature is available. The following scenarios are supported:

• The J2EE Engine uses a self-signed public-key certificate for digitally signing. In this case, this certificate exists as a file in the file system.

• The J2EE Engine uses a public-key certificate that has been signed by a CA. In this case, the CA’s root certificate either exists as a file in the file system or it is contained in the application server’s certificate database.

In either case, the certificate must exist either in base 64 or in DER format.

The J2EE Engine’s public-key certificate that it uses for logon tickets is located in the TicketKeystore entry in the Key Storage service. For more information, see Managing Entries [External].

Procedure On the SAP Web AS ABAP application server:

• In transaction RZ10, set the profile parameter login/accept_sso2_ticket = 1. • Set login/create_sso2_ticket = 0 unless the server should also be able to issue

tickets. (Use DEFAULT profile)

1. For Releases 4.0 and 4.5, also set the profile parameter SAPSECULIB to the location (path and file name) of the SAP Security Library (or SAP Cryptographic Library).

2. Add the Web AS public-key certificate to the corresponding certificate list. o For Releases >= 6.10, use the trust manager (transaction STRUST or

STRUSTSSO2). Import the J2EE Engine’s public-key certificate into the PSE that is used for logon tickets. Per default this is the System PSE. In the following cases a PSE other than the System PSE is used: • If the system has been upgraded from a Release <= 4.6B, then the PSE

used for logon tickets is the SAPSSO2 PSE.

• If you have defined an explicit PSE to use for logon tickets, then this PSE (as specified in the table SSFARGS) is used.

o For Releases <= 4.6D, use the transaction PSEMAINT.

3. Add the Web AS information to the access control list. Enter the Web AS system ID and its Distinguished Name from the certificate found in the TicketKeystore entry. For J2EE Engine's use client number 000. o For Releases >= 6.10, use the transaction STRUSTSSO2.

o For Releases <= 4.6D, use table maintenance (transaction SM30) to edit the

table TWPSSO2ACL.

Figure 4 - Transaction STRUSTSSO2

See also: Using Logon Tickets [External]

4 Configuration for Sending SSO

In order to configure a system to work with SSO, a trust relationship has to be established between the systems involved. This section will cover the configuration of Web AS J2EE and Web AS ABAP systems as a sender side.

4.1 SAP Enterprise Portal The portal system is set up to issue SAP logon tickets. In other words, the login module stack used by the portal authentication scheme should contain the login module CreateTicketLoginModule. By default the portal is set up to issue logon tickets; therefore, you do not need to configure anything. For more information, see Portal Platform Security Guide → Single Sign-On → Single Sign-On with SAP Logon Tickets → Configuring Portal Server for SSO with SAP Logon Tickets.

4.2 SAP Web AS J2EE There are two possibilities, either the Web AS is the ticket-issuing server or it propagates an accepted ticket to other servers. If the Web AS is the ticket-issuing server you first need to export the Web AS ticket and import it to the destination servers. In order to export the ticket:

1. Go to the Visual Administrator Services Key Storage service. 2. Select the Runtime tab, in the Views select TicketKeystore and in the Entries

select the SAPLogonTicketKeypair-cert entry. 3. Choose Export. 4. Specify a filename. Use the file type X.509 Certificate with the extension .crt

and choose OK. Now import the certificate to your destination server, follow the import instructions from section 3 according to the server type. If the Web AS only propagates an accepted ticket to other servers no special configuration is required except, of course, to accept the ticket.

4.2.1 Setting up a Web Dynpro Application for a Logon Ticket

Use You want to configure a Web Dynpro application that receives data from a SAP system with an adaptive RFC model so that it logs onto the SAP system with the user’s logon ticket. If you use an adaptive RFC model in a Web Dynpro application, two JCo destinations are automatically created in the Web Dynpro Content Administrator. You must maintain these JCo destinations with this tool.

• With the first connection, the Web Dynpro application receives the metadata that is not user-specific and that is therefore the same for all users. It must be available to all users.

• With the second connection, the Web Dynpro application receives the application data, which is normally user-specific.

The JCo destinations for an adaptive RFC model have the following default names:

• WD_MODELDATA_DEST for application data • WD_RFC_METADATA_DEST for metadata.

When you create JCo destinations, you can also give them different names. When the data for further adaptive RFC models is loaded from other SAP systems, you may not use the default names; you must define unique names for the JCo destinations.

The JCo destinations are displayed in the Web Dynpro Content Administrator when you select the corresponding development component or local We bDynpro application in the Browse and Search Area.

Prerequisites You have administration permission for the J2EE Engine or SAP Enterprise Portal. You set up the SAP system so that the logon tickets that are sent by the Web Dynpro application are accepted. These logon tickets can be issued by either the J2EE Engine on which the Web Dynpro application was deployed or another system, such as an SAP Enterprise Portal. For more information see Configuring the SAP Web AS ABAP to Accept Logon Tickets from the J2EE Engine [External].

Procedure ...

1. Open the Web Dynpro Content Administrator from the URLs a. Directly with the URL

http://<YourHost>:50000/webdynpro/dispatcher/tc~wd~tools/explorer b. From the home page of the J2EE Engine with the following URL

http://<YourHost>:50000/webdynpro/welcome by choosing Content Administrator.

2. Or in the top-level navigation of SAP Enterprise Portal select Content Administration → WebDynpro → WebDynpro Content Administrator.

3. Select the required development component or local Web Dynpro application in the corresponding level in the Browse and Search Area. The first level local contains all the locally deployed Web Dynpro applications. The second level contains all the development components and is called by the vendor name, for example sap.com. On the JCO Connections tab page select the JCo destination you want to maintain and choose Edit.

4. A wizard with which you can define the JCo destination in individual steps opens. a. Define the general data.

At runtime the JCo connection is implemented with a JCo pool. You must define the largest possible pool size. This is the maximum number of connections that can be set up at runtime. You also define the client.

b. Define the message server. You can define the message server below. If you are using a SAProuter, you can also define the SAProuter string in this step. For more information about the SAProuter, see the SAP Library under SAP NetWeaver → Security → SAPNetWeaver Security Guide → Network Infrastructure → Firewalls → SAProuter.

c. Define the security settings. You have to take security matters into consideration and define the security settings when you specify a JCo destination. You select the required authentication method for user authentication. If you select User/Password, you must define a user and the corresponding password. If you select the value Ticket, ticket authentication is expected. The same is true for Client Certificate (X509). You need not define a user and password here either.

To define the JCo destination for application data, select authentication method Ticket. The user’s logon ticket is sent to the SAP system. To define the JCo destination for metadata, select authentication method User/Password. The data that is relevant for all users is now available. Since this authentication method technically only sets up a connection, resources can be saved, thus increasing performance.

d. Overview of the defined parameters. 5. End the wizard with Finish. 6. Then perform the same steps for the second JCo destination. The order in which

you process the JCo destinations is of no importance.

Result You maintained the necessary JCo destinations for an adaptive RFC model. If data is loaded from the backend for the user of the Web Dynpro application that contains this model, the user is logged on with Single Sign-On with logon ticket.

4.2.2 Configuring the Web Service Destination to Send SAP Logon Ticket

Use You created a web service module and deployed it into the Web AS in order to connect to the destination server using Single Sign-On.

Prerequisites You have administration permission for the J2EE Engine or SAP Enterprise Portal and you have created a deployable web service project.

When the source server is the ticket issuing system, you have set up the destination server to accept ticket from the source server. See Configuring the J2EE Engine to Accept Logon Tickets and Configuring the SAP Web AS ABAP to Accept SAP Logon Tickets.

Procedure You can configure deployable web service during development time in the SAP NetWeaver Developer Studio or during development or deployment time. • Configuration during development:

1. Open the Web Service Deployable project in the SAP NetWeaver Developer Studio.

2. Open the project in Web Services perspective and select Client Explorer tab. 3. Expand the Logical Ports node of your deployable Web Service proxy and

double click on your logical port name. 4. Select HTTP Authentication and check Use SAP Logon Ticket. 5. Save the project.

• Configuration during deployment:

1. Open the Visual Administrator and go to Server Services Destinations 2. Expand the WebService node and select the web service name. 3. In the Authentication combo-box select Logon Ticket. 4. Click on Save (in the bottom).

Figure 5 - Web-Service Destination Configuration

4.2.3 Configuring the HTTP Destination to Send SAP Logon Ticket

Use You want to connect to an HTTP destination using Single Sign-On.

Prerequisites You have administration permission for the J2EE Engine or SAP Enterprise Portal. When the source server is the ticket issuing system, you have set up the destination server to accept ticket from the source server. See Configuring the J2EE Engine to Accept Logon Tickets and Configuring the SAP Web AS ABAP to Accept SAP Logon Tickets.

Procedure You can configure HTTP destination with the Visual Administrator. To configure it in the Visual Administrator:

1. Open the Visual Administrator and go to Server Services Destinations 2. Expand the HTTP node and select the HTTP name. 3. In the Authentication combo-box select Logon Ticket. 4. Click on Save (in the bottom).

Code Example for using HTTP destination: DestinationService dstService = (DestinationService) ctx.lookup(DestinationService.JNDI_KEY); if (dstService == null) throw new NamingException("Destination Service not available");

Destination destination = dstService.getDestination("HTTP","dst-1"); //for HTTP destination: cast HTTPDestination httpDestination = (HTTPDestination) destination; //obtain a HTTPUrlConnection from the destinationHttpURLConnection httpConnection = httpDestination.getURLConnection();

4.2.4 Manual (Code) Connections

Use You want to write a code that will enable you to connect to other server using Single Sign-On.

Prerequisites You can obtain programmatically the Logon Ticket string. If the source server is the ticket issuing system, you have set up the destination server to accept ticket from the source server. See Configuring the J2EE Engine to Accept Logon Tickets and Configuring the SAP Web AS ABAP to Accept SAP Logon Tickets.

Procedure

4.2.4.1 HTTP To connect to HTTP destination with Single Sign-On you can follow the instructions in section 4.2.3, however, if you want more flexibility you can do it programmatically. In your HTTP connection object you will have to add to the cookie header another cookie with name: MYSAPSSO2 and the value is the Logon Ticket string. Here is a code example: private void connectToHTTPDestination(String urlDestination) { String cookies = getCookies();//Getting other cookies String ssoString = getSSOString();//Getting SSO ticket StringBuffer currentCookies = new StringBuffer(); if ( cookies != null && cookies.length() > 0) { currentCookies.append(cookies); } if ( ssoString != null && ssoString.length() > 0) { currentCookies.append("; "); currentCookies.append("MYSAPSSO2="); currentCookies.append(ssoString); } URL url = new URL(urlDestination); HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection(); httpConnection.addRequestProperty("Cookie",

currentCookies.toString()); . . .

}

4.2.4.2 JCO To connect to a JCO destination with Single Sign-On you will have to create the JCO client with username "$MYSAPSSO2$" and the password will be the SSO string. For example: private void connectToJCODestination(String urlDestination) { String ssoString = getSSOString();//Getting SSO ticket //Pay attention that $MYSAPSSO2$ is the username and password is ssoString Client client = JCO.createClient(clientNumber, "$MYSAPSSO2$", ssoString, language, host, systemNumber); client.connect(); . . . }

4.3 SAP Web AS ABAP

Prerequisites You must know whether the server should use a self-signed public-key certificate or a certificate signed by the SAP CA. Procedure 1. If you use a certificate signed by the SAP CA, you need to obtain the certificate and

import it into the server's Personal Security Environment (PSE) to use for Single Sign-On. For the SAP Web Application Server, the default SSO PSE is the system PSE.

Per default, the PSE used is the System PSE, however, if a different PSE is to be used, then select it. A different PSE can be used in the following cases:

• If the system has been upgraded from a Release <= 4.6B, then the PSE used for logon tickets is the SAPSSO2 PSE.

• If you have defined an explicit PSE to use for logon tickets, then this PSE (as specified in the table SSFARGS) is used.

If you use a self-signed certificate, then the public-key certificate already exists. For more information, see:

a. Obtaining a Certificate Signed by the SAP CA b. Using a Self-Signed Certificate

2. Set the following profile parameters on the SAP Web Application Server:

Profile Parameters Used for Logon Tickets

Parameter Value Comment login/accept_sso2_ticket 1 Allows the server to

accept an existing logon ticket.

login/create_sso2_ticket 1: If the server's certificate is to be included in the logon ticket. 2: If the server's certificate is not to be included.

For best results, set this parameter to the value 1 if the server possesses a certificate signed by the SAP CA. Set it to the value 2 if the certificate is self-signed.

login/ticket_expiration_time Desired value Default = 60 hours

For more information, see the documentation provided for the profile parameters in transaction RZ11.

You can use the SSO administration wizard to view the current server's SSO configuration. (Execute the tool without specifying an RFC destination.)

5 Appendix

5.1 SSO Cross Domain In a default configuration, the portal system issues a single SAP logon ticket for the domain of the portal system. Browsers only send the logon ticket to web servers located in the same DNS domain as the issuer of the logon ticket. For example, if the portal is installed at server.mycompany.com, the logon ticket will only be valid for hosts in that domain, such as server1.mycompany.com. Portal users can only access systems in that domain with Single Sign-On (SSO). If you want to integrate applications that are located in various DNS domains in the portal and want to provide SSO with logon tickets to these applications, you need a separate logon ticket for every domain. For example, a business warehouse system is set up in your company's headquarters in the domain mycompany.com, and a customer relationship management system is installed in the domain mycompany.ie. To enable SSO to applications running on these systems, the web browser requires a separate logon ticket for both the domain mycompany.com and mycompany.ie. For EP6.0 SP4 and above more information can be found here: http://help.sap.com/saphelp_nw04/helpdata/en/b8/9ba340fa432b54e10000000a1550b0/content.htm For EP6.0 SP2 please download the following zip and read the HowTo carefully http://service.sap.com/~sapidb/011000358700000909802004E/Cross_Domain.zip

5.2 SAP XI SAP XI 3.0 supports session-based Single Sign-On for dialog users of the SAP XI tools. A dialog user has to log on only once for all SAP XI tools, provided that the same browser session is used for each tool access and that the tools are started from the same J2EE Server. SAP XI 3.0 doesn't support Single Sign-On between SAP NetWeaver '04 components, since XI can be found a lot of times in the middle of a solution design it can be a big obstacle in the flow of propagating Single Sign-On user from first tier to backend. The most common solution for that issue is using 'technical' user from and to SAP XI while passing the executer user as parameter.