Install and Configure the Web Client

The Web Client itself is delivered in two versions – one for Apache Tomcat and one for SAP NetWeaver. The next two sub-sections detail the installation steps for the Secure Login Web Client on both systems.

Sections Section 5.3.1 „Web Client installation on Tomcat‟, on page 112 Section 5.3.2 „Web Client Installation on NetWeaver‟, on page 114

5.3.1

Web Client installation on Tomcat

1. If necessary, stop Tomcat.

2. Unpack the contents of the file shared.zip located in the directory <unzipped location on hard disk>SECUDE51SecureLoginServer/Tomcat WS/ (in the delivery package - see section 5.2 on page 111). This step differs according to the version of Tomcat you use:

- Tomcat 6: Unzip the content directly to the directory <Tomcat home directory>\shared.

- Tomcat 5:

- Unzip the *.properties files to the directory: <Tomcat home directory>\shared\classes

- Unzip the *.jar files to the directory: <Tomcat home directory>\shared\lib

Apache Tomcat 6.x does not use a ‘shared’ directory as standard and it must therefore not only be created but also manually entered into the Tomcat configuration (failure to do so will result in errors such as ‘SecudeJavaSDK not found’ and ‘JRE Policy not implemented’ – despite the fact that the components are in the correct directory):

Create the shared directory directly under the Tomcat home directory, for example: <Tomcat home>\shared

Open the Tomcat properties file catalina.properties in the directory <Tomcat home>\conf in a text editor.

Locate the following section:

# List of comma-separated paths defining the contents of the "shared"

# classloader. Prefixes should be used to define what is the repository type.

# Path may be relative to the CATALINA_BASE path or absolute. If left as blank,

# the "common" loader will be used as Catalina's "shared" loader. # Examples:

# "foo": Add this folder as a class repository

# "foo/*.jar": Add all the JARs of the specified folder as class

# repositories

# "foo/bar.jar": Add bar.jar as a class repository

# Please note that for single jars, e.g. bar.jar, you need the URL form

# starting with file:. shared.loader=

Change the last line to read:

shared.loader=${catalina.home}/shared,${catalina.home}/shared/*.jar Save the changes and close the text editor.

3. Copy the file securelogin.war from the delivery package to <Tomcat home directory>\Webapps.

113 4. Start Tomcat to deploy the securelogin.war file.

5. Start the Administration Console and create your basic configuration (see section 6.1 on page 119). Once completed, logout of the console.

6. Deploy the file axis2.war by copying it from the delivery package to the directory <Tomcat home directory>\Webapps. The deployment should be automatic but if not, restart Tomcat.

When configuring an SAP-ID-based Authentication Server, the Administration Console will usually take care of the signon&secure/JCO installation. This includes copying the file sapjco.jar to the directory:

<Tomcat home>\Webapps\securelogin\WEB-INF\lib.

This also applies to the AXIS Web Client scenario. The file sapjco.jar will be copied to the ‘shared’ directory:

For Tomcat 5.x: <Tomcat home directory>\shared\lib For Tomcat 6.x: <Tomcat home directory>\shared

However, for the AXIS Web Client scenario, if you have not set the option TomcatSharedPath in the Administration Console page Web Client Configuration, then you will have to copy the sapjco.jar file manually to the respective Tomcat 5.x/6.x directory. For further details about the Web Client Configuration node refer to section 6.1.16 on page 166.

7. Deploy the file secureloginservice.aar by copying it from the delivery package to the directory <Tomcat home directory>\Webapps\axis2\WEB-

INF\services. The deployment should be automatic but if not, restart Tomcat. 8. Open the file <Tomcat home directory>\Webapps\axis2\WEB-

INF\Web.xml in a text editor. Locate and remove the line

<load-on-startup>XXX</load-on-startup>. Save the file and close the editor.

9. Deploy the file SlsWebClient.war by copying it from the delivery package to the directory <Tomcat home directory>\Webapps

The Tomcat Security Manager

Usually, after a fresh Tomcat installation, the Tomcat Security Manager is deactivated. However, if it is active then errors such as ‘SecudeJavaSDK not found’ and ‘JRE Policy not implemented’ may occur despite the fact that everything in the configuration appears to be as it should. The Tomcat Security Manager must be deactivated:

For Tomcat 5.5 under Linux:

The following security manager option is located in the Tomcat start script in the directory init.d :

#Use the Java security manager? (yes/no) #TOMCATS_SECURITY=yes

Either comment it out or set it to no. For Windows:

The security manager is usually started using the runtime option –security. Do not use this option.

Change default Apache Axis2 administration account

Apache Axis2 also has an administration front-end. It is available via the URL: http://localhost:8080/axis2/axis2-admin/

This allows the upload (and hence the change) of Web Service Archives and the activation/deactivation of deployed services.

The front-end is shipped with a default account: user=admin, password=axis2. This of course, presents a security issue and therefore it is recommended that the Secure Login administrator change the password of the AXIS2 admin front-end. This can be accomplished as follows:

114

Open the axis2.xml file in the Server directory Webapps\axis2\WEB-INF\conf\ Locate the follow lines:

- <parameter name="userName">admin</parameter>

- <parameter name="password">axis2</parameter> Change the entries marked above - in red - accordingly.

10. Start the Administration Console and login. Click the Web Client Configuration node to start configuring the Web Client (see section 6.1.16 on page 166).

Next Step Configure the Secure Login Server using the Administration Console – seesection 6.1 'Administration Console‟ on page 119

Start and use the Web Client - seesection 5.4 „Use the Web Client‟ on page 115

5.3.2

Web Client Installation on NetWeaver

The Web Client installation for NetWeaver is exactly the same as the standard Secure Login installation detailed in section 3.7 on page 91. However, instead of deploying the standard Secure Login application (securelogin.ear) you deploy the Web Service application secureloginservice.ear (located in the NetWeaver WS directory in the delivery package).

Next Step Configure the Secure Login Server using the Administration Console – see section 6.1 'Administration Console‟ on page 119

115

5.4

Use the Web Client

This section describes how to open and use the Secure Login Web Client.

Only use the Web Client once you have finished configuring not only the Secure Login Server, but also the Web Client settings via the Administration Console (see sections 6.1 on page 119, and 6.1.16 on page 166 respectively).

1. Enter the following URL in your Internet browser: http://<hostname:port>/SlsWebClient

A security warning to confirm the digital signature of the Web Client Applet may appear. If so, confirm the signature to proceed to load the Web Client. You can choose to either to confirm the signature once or for always – choosing ‘always’ will mean that the security warning will reappear the next time you want to logon to the Web Client.

2. The Web Client login page will appear:

Figure 5-1 Web Client – login page

3. Enter your Username and Password, and select a Server to logon to from the Server combo-box. The next step will differ according to whichever Server you are about to authenticate and logon to:

 If you have configured the Web Client to start the SAP interface directly without calling the SAP logon dialog first (Web Client Configuration node> SAP GUI Management) then the next screen you should see is the SAP interface. The procedure ends with this step.

 If you have configured the Web Client to start the SAP logon dialog then the SAP Logon dialog will appear. Go to the next step.

4. On Windows Clients only: The new user certificate is propagated into the Windows Certificate Store in the background. Internet Explorer could use it for certificate based authentication if an SSL protected Web page is opened.

5. The SAP Logon dialog/GUI will appear (if the SAP Logon GUI for Java is correctly installed, it will take preference over the SAP Logon GUI for Windows):

116

Figure 5-2 Web Client – SAP Logon GUI (left: Windows, right: Java)

Web Client Logging

When logging-in via the SAP Logon dialog/GUI user information is stored in the local user directory. For Windows this directory is:

C:\Documents and Settings\<user>\secudesnc. The directory will contain some, or all, of the following files:

ComSecudeUtil.dll – SECUDE library copied over from the Server cred_v2 – Credentials file

SapProfile.sap – SAP profile

secude.dll – SECUDE library copied over from the Server SecudeSNCApplet.log – logfile of Web Client activity SNC.pse – SNC personal security environment

ticket.snc – license file copied over from the Server

user.properties – user properties file containing the username, date+time, and snc version.

version.txt – Native components version file copied over from the Server

It is possible to configure the Web Client to automatically delete the files in the secudesnc directory. Use the Administration Console option Client Logging under the node Web Client Configuration>Common Configuration. For further information see section 6.1.16.1 on page 168.

5.4.1

Configure SSL Trust for the Web Client Java Applet

This section details how to secure the communication between the Internet browser and Web Client using SSL thus helping to eliminate the security warnings when calling the Web Client (and any alarm this may cause – including extra hotline activity).

A normal call between Browser and the Web Client is established via Java over HTTP and therefore how we establish the SSL trust is Browser-dependent:

Linux Konqueror and Mozilla Firefox 3 do not use their own certificate store but rather the Java certificate store.

Microsoft Internet Explorer 6/7 and Apple Safari use their own certificate store. Trust may be established in two ways:

No permanent certificate: this means that the user computer is left untouched and the Web Client is called using an HTTPS URL. If SSL trust has not yet been established a Java pop-up will appear prompting the user if they wish to trust the SSL Server.

117 certificate (via remote distribution) and the Web Client is called using an HTTPS URL. This

can be configured so that no pop-ups will appear.

These are the three points of security configuration relevant to the Web Client, or rather the three possible levels at which action may be taken – depending on how far you want to go (all of which are for a permanent certificate only!):

SSL Trust between Browser and Application Server (for example, Tomcat).

This simply involves importing the Administration Console root certificate into the Browser‟s certificate truststore.

SSL Trust between Java Applet and Application Server

This only applies to Linux Konqueror and Mozilla Firefox 3! This will import the Administration Console root certificate into the Java environment. This can be performed on a two levels – per machine for all users, or per user:

- Per machine (all operating systems): Locate the Java truststore file cacerts under the path jre\lib\security. Use the Java Keytool to import the Administration Console root certificate into the Java truststore.

- Per machine (alternative method): Use the Administration Console to export the root certificate in JKS format. Rename the resulting keystore file in jssecacerts (no extension!) and place the file under jre\lib\security.

- Per user: Use the Administration Console to export the root certificate in JKS format. Rename the resulting keystore file in trusted.jssecacerts (no extension!) and place the file under:

- Windows: %HOMEPATH%\Application Data\Sun\Java\Deployment\security

- Linux/Mac: $HOME/.java/deployment/security Execution rights for signed applet (i.e. user warning prompts)

This will import the Administration Console root certificate and suppress the user warning prompts. The applet in the SSL Server SlsWebClient directory will always be „trusted‟. This can be performed on a two levels – per machine for all users, or per user:

- Per machine: Open the Java Security Policy file java.policy in the directory jre\lib\security. Add the following code:

grant codeBase "https://<SLS-HOSTNAME WITHOUT PORT>/SlsWebClient/*" {

permission java.security.AllPermission; };

Save and close the file.

- Per user: Open an editor and enter the following code:

grant codeBase "https://<SLS-HOSTNAME WITHOUT PORT>/SlsWebClient/*" {

permission java.security.AllPermission; };

Save the file as .java.policy in the user home directory (all operating systems).