Directly connecting a recursive session to the IBM Spectrum Symphony session manager (SSM)

By default, when using the recursive workload with IBM® Spectrum Symphony, a recursive session interacts with the IBM Spectrum Symphony session director before connecting to the session manager. However, if the session director for your environment is heavily loaded, to help with performance and offload the session director, an application developer can configure IBM Spectrum Symphony to bypass the session director and, instead, directly connect to the session manager. Additionally, when a recursive service instance connects directly to the session manager, the session manager checks the validity of the username and password used; you can optionally disable username and password authentication by using an inclusion list of application names.

Procedure

Get the value of the SSM_FRONTEND_URL environment variable, and then pass it to the SoamFactory::connect() API, as the first parameter in the service code for your programming language:

Example for C++

char *url = getenv("SSM_FRONTEND_URL");
ConnectionPtr conPtr = SoamFactory::connect(url, application_name, &securityCB);

Example for Java

String url = System.getEnv("SSM_FRONTEND_URL");
Connection connection = SoamFactory.connect(url, application_name, securityCB);

Example for C#

string url = Environment.GetEnvironmentVariable("SSM_FRONTEND_URL");
Connection connection = SoamFactory.Connect(url, application_name, securityCb);

Recompile and redeploy the recursive application, so that the recursive service instance will be able to connect directly to the SSM.

Optional: By default, when a recursive service instance connects directly to the SSM, the SSM will check the validity of the username and password used. You can optionally disable this username and password authentication checking:
1. Open the sd.xml file for editing:
  - Windows: %EGO_CONFDIR%\..\..\eservice\esc\conf\services\sd.xml
  - Linux: $EGO_CONFDIR/../../eservice/esc/conf/services/sd.xml
2. Add the SD_BYPASS_AUTHENTICATION_BY_APPLICATION environment variable to the file, listing the applications that you do not require the system to authenticate:
```
<ego:EnvironmentVariable name="SD_BYPASS_AUTHENTICATION_BY_APPLICATION">application_name1,application_name2,application_name3</ego:EnvironmentVariable>
```
  To specify multiple applications, use a comma-delimited list and ensure that there are no extra spaces or quotation marks. You can also use the asterisks (*) and question mark (?) characters, to indicate wildcard names. For example, to allow application names that start with sampleapp and symping to have clients bypass authentication, specify:
```
<ego:EnvironmentVariable name="SD_BYPASS_AUTHENTICATION_BY_APPLICATION">sampleapp*,symping*</ego:EnvironmentVariable>
```
  Note: Kerberos authentication and authorization cannot be bypassed using the SD_BYPASS_AUTHENTICATION_BY_APPLICATION environment variable. Bypass the session director and directly connecting to the session manager is not supported for Kerberos client authentication.
3. Save your sd.xml file settings.
4. Update the sd.xml file so that your changes take effect:
```
> egosh service stop SD
> egosh service modify SD -f sd.xml 
> egosh service start SD
```
5. To verify if username and password authentication checking is bypassed, run the symping command with an unsupported password (such as Badpassword):
```
> symping -m 1 -r 1 -u Admin -x Badpassword
```
  Note: Role-based access control is not disabled. For example, an unsupported user will be flagged if the user is set to BadAdmin and not Admin with the following error message:
```
Security error: User <BadAdmin> does not have privileges to perform this action.
```
  If successful, an SD_BYPASS_AUTHENTICATION_BY_APPLICATION mode enabled message is logged in the $SOAM_HOME/logs/sd.*.log (Windows) or $SOAM_HOME\logs\sd.*.log (Linux) file, to indicate that bypassing authentication has been enabled.