Configuring a web server

Edit online

Traditional:
In a highly available, load balanced environment with multiple server clones, clients (such as end users with browsers) still connect to the User Management Service by using a single URL that is provided by a web server, which routes requests to available User Management Service (backend) servers for processing.

Quick start: For a quick start configuration, a standalone server is used without an HTTP server, therefore no additional server configuration is required.

To configure the web server and start your User Management Service servers, perform the following actions:

Install and configure IBM® HTTP Server as described in Installing IBM HTTP Server.
Ensure that your web server can be reached securely as describe in Guide to properly setting up SSL within the IBM HTTP Server.
Edit your Liberty server.xml configuration file and add the following sub-element to the featureManager element:
```
 <feature>localConnector-1.0</feature>
```
To ensure that the WebSphere® server plugin is configured with a list of web application paths that are available on backend servers as well as with a list of hostnames and ports of these backend servers, generate a plugin-cfg.xml configuration for each running IBM WebSphere Application Server Liberty server by using the pluginUtility, which is described in Configuring a web server plug-in for Liberty.
Add a pluginConfiguration element to your Liberty configuration and provide non-default settings for your environment. For example:
```
<pluginConfiguration pluginInstallRoot="C:/Program Files/IBM/WebSphere/Plugins" />
```
For more information, see pluginConfiguration - Web Server Plugin (pluginConfiguration).
Important: Because this configuration must be the same for all servers, consider collecting it in a dedicated configuration file in ${shared.config.dir} and including it in each servers' configuration. For more information, see Liberty: Directory locations and properties and Using include elements in configuration files.
Install the JWT Keystore on all servers. To enable single sign on with JWK token exchange, the servers needs a certificate to sign the JWK token. Single sign on clients will validate the JWK token by checking the public key of the certificate against the signature of the token. The requirement is that all server nodes use the same certificate, hence the same keystore must be copied on all server nodes.
1. The keystore can for instance be generated by the following command:
```
 keytool -genkey -keyalg RSA -alias default -keypass password -keystore jwtkey.p12 -storetype PKCS12 -storepass password -validity 3650
```
2. Copy the keystore to resources/security/jwtkey.p12 on all servers.
3. Ensure that the settings oidc.jwt.* in configDropins/overrides/umsVariables.xml point to the correct keystore.
Start the servers by changing to the wlp/bin directory and issuing the commands to start each server. For example:
```
server start ums1
server start ums2
```
Use the pluginUtility again to merge all the separate plugin-cfg.xml server files into a single merged configuration file. The merged configuration file along with a truststore containing the SSL signer certificates of each Liberty server must be specified later when you generate the WebSphere server plugin.
Generate WebSphere plugin configurations by running the wlp/bin/pluginUtility for each User Management Service server, providing the server name and a target file name as command parameters. For example:
```
pluginUtility generate --server=ums1 --targetPath=..\plugin-cfg1.xml
pluginUtility generate --server=ums2 --targetPath=..\plugin-cfg2.xml
```
Merge WebSphere plugin configuration by running wlp/bin/pluginUtility providing a target directory (or file name) and a comma-separated list of source files to merge. For example:
```
pluginUtility merge --targetPath=.. --sourcePath=..\plugin-cfg1.xml,..\plugin-cfg2.xml
```

Add the WebSphere plugin to your web server configuration by adding to your web server’s httpd.conf file, as described in Adding a plug-in configuration to a web server. For example:

LoadModule was_ap22_module "C:/Program Files/IBM/WebSphere/Plugins/bin/64bits/mod_was_ap22_http.dll"
WebSpherePluginConfig "C:/Program Files/IBM/WebSphere/Plugins/config/webserver1/merged-plugin-cfg.xml"

Configure a secure connection from the WebSphere plugin to each of your Liberty servers:
1. Create a truststore that contains all signer certificates that are required to connect to your Liberty servers. You can use the GSKit installation that is part of your IBM HTTP Server installation:
```
bin\gskcapicmd -keydb -create -genpw -stash
    -db "C:\Program Files\IBM\WebSphere\Plugins\config\webserver1\plugin-key.kdb" 
```
2. Export each Liberty server’s signer certificate. Assuming the basic configuration, Liberty generated a SSL certificate and in a keystore upon initial server start. You can use keytool to extract its public key certificate, as described in keytool – Key and Certificate Management Tool . For example:
```
keytool -exportcert -rfc -keystore wlp/usr/servers/serverName/resources/security/key.jks
        -storepass ssl_keystore_password -alias default -file signer1.arm
```
  Where serverName is the name of the server and ssl_keystore_password is the value of ssl_keystore_password from the umsVariables.xml file.
3. Import the signer certificates into the WebSphere plugin’s truststore. Again, you can use the GSKit installation that is part of your IBM HTTP Server installation. For example:
```
bin\gskcapicmd -cert -add -db "C:\Program Files\IBM\WebSphere\Plugins\config\webserver1\plugin-key.kdb" 
    -stashed -label ums -file signer1.arm
```
Restart your web server.
Using a browser, test that the URL https://webserver/ums/login works. Where webserver is the host name of your web server.

Next, perform Configuring a single sign-on database.