Administering Domains, Roles and Users

Delegated Sign On

Enabling delegated sign-on (DSO) validation against a user account removes the need for the user to log in when launching Capital applications, and makes all of the operating system's user security functionality available to Capital.

Caution

By default, Windows Delegated Single Sign-On is enabled for on-premise installations. It is disabled for Capital X. You should use it only if you accept the security risks. It is recommended to use a more secure authentication mechanism. In the future, Windows Delegated Single Sign-On will be deprecated and will not be enabled by default. More secure authentication methods are:

OIDC multi factor authentication. See Multi Factor Authentication in the Capital Design Tools - Common Functions User Guide.
Standard authentication where you create user accounts with usernames and passwords in Capital. See Creating and Editing a User Account

When a user launches a Capital application, the details of the user currently logged into the operating system are obtained and passed to Capital Manager, where they are validated against the list of users configured for access to Capital. If an DSO-enabled match is found, the user will be allowed to proceed and the application will launch; if no DSO-enabled match is found, the user will be prompted to log in to Capital directly.

Note

It is not possible to enable DSO validation for the superuser account; access to this account will always require the entry of a username and password.

For details on how to enable DSO for web-based applications see Enabling Delegated Sign-on for Capital Device Modeler and Capital E/E Reporter.

Aside from removing the need to perform a second login when launching a Capital application, DSO also exposes all of the functionality of your operating system's security policies for use in controlling access to your systems. This includes:

Strong passwording - all supported operating systems offer the option to restrict the composition of user passwords in a number of ways. For example: Enforce a minimum length

Require at least one alphabetic (uppercase and/or lowercase) and numeric character

Require at least one special character (for example, !,$,* and so on)

							Supported special characters ! \ " # $ % & ' ( ) + , - . / :
								; < = > ? @ [ ] ^ _ ` { | } ~ * ¿ ¡

Not permit passwords featuring the user's full name or username

Password ageing
user passwords can be set to expire after a fixed duration, with reuse of an expired password being further restricted. For example, it may not be possible to reuse a password until three subsequent, unique passwords have been used.
Logging of failed attempts - all supported operating systems allow failed login attempts to be recorded.

In order to enable a user account for DSO validation, the username must match the account used to log onto the operating system. If the Capital client installation is running on Windows, the network domain must also have been prepended to the username; for example, domain \ username. If a password has been entered against the Capital user account, it is possible to flag that account as DSO/Capital-login as required, although with DSO enabled, the password will be ignored.

Caution

UNIX and Linux user account names are case-sensitive, so it is possible to have two accounts with the same name differentiated by capitalization; for example, user abc and user ABC. However, Capital user account names are case-insensitive, so continuing the above example, if a Capital user account exists named abc that is flagged for delegated sign-on, both users would be given access to that account when Capital is started. Obviously, this is neither practical nor secure, and the use of matching user names should be avoided. Windows user account names are case-insensitive, so this situation would never arise.

Capital superusers can flag all user accounts as DSO/Capital-login at the same time. To do this, right-click on the User Accounts folder in the browser tree and select one of the following options:

Convert All Existing Accounts to Delegated Sign On - a dialog will be displayed allowing you to enter a domain name to be prepended to all user names. If you are running Capital in a Windows environment, select the Prepend Network Domains to User Names option and enter the relevant network domain name in the Network Domain field. If you are running Capital on UNIX or Linux there is no need to enter a domain name. Click OK to proceed and all user accounts (apart from the superuser account) will be flagged as delegated sign-on. If you entered a domain name, it will be added to the start of the Login Name field, followed by a \ character.
Convert All Existing Accounts to User Login - selecting this option will set all user accounts to user login without any further action required. Note that not all accounts may have had a password entered before switching from delegated sign-on, in which case a default password of initial will be entered (obviously, this password should be amended by the user to something secure at the first opportunity). Note also that any text preceding a backslash character () in the Login Name field will be taken to be a Windows domain name, and will be removed, along with the backslash.

Enabling Delegated Sign-on for Capital Device Modeler

and Capital E/E Reporter

When using web based web applications, such as Capital Device Modeler and Capital E/E Reporter (CER) it is not straightforward to extract a Windows user name and connect with Capital. This is because Browsers are often not allowed to extract system information due to security issues. In order to make DSO work for web applications, the following set up can be used.

There should be a dedicated worker Capital Integration Server /CER server and a dedicated controller. Both the worker Capital Integration Server/CER server machines should connect to this dedicated controller. This dedicated controller will use a plug-in to authenticate the user. This plugin maybe obtained from Siemens Global Support Services. The plug-in (when obtained) uses LDAP authentication. No other Capital application should connect to this dedicated controller.

Note

This plug-in can also be used for desktop applications. Contact Siemens Global Support Services.

Once the set-up is complete, enter your Windows user name and password in the Capital Device Modeler or CER web login page. These credentials are first given (by Capital Manager) to the plug-in for authentication and if it successful then Capital Manager checks if the user exists in Capital. Once this is confirmed a connection is established.

Updating capitalintegrationserverconfiguration.xml files on Capital Integration Server Controller machine and Capital Integration Server Worker machine

Changes are required to the capitalintegrationserverconfiguration.xml file. For the purposes of this example assume Capital Integration Server Controller name is controller-machine and Capital Integration Server Worker machine name is worker-machine.

Capital Integration Server Controller set up

In the capitalintegrationserverconfiguration.xml file on the Capital Integration Server Controller machine (controller-machine) make edits to the ciscontroller node. Change the name attribute in the ciscontroller node to point to this machine (localhost):

Copy

<ciscontroller   application_memory_alloc="1024" delay-between-retries="10" name="localhost" number-of-retries="2" port="49901" timeout="1440">
</ciscontroller>

Capital Integration Server Worker set up

In the capitalintegrationserverconfiguration.xml file on the Capital Integration Server Worker machine (worker-machine), make edits such that this machine is a Capital Integration Server Worker machine. Since this itself is a Worker, this capitalintegrationserverconfiguration.xml has a worker node. Change the name attribute in the ciscontroller node to point to the Capital Integration Server Controller machine (controller-machine):

Copy

<ciscontroller application_memory_alloc="1024" delay-between-retries="10" name="controller-machine" number-of-retries="2" port="49901" timeout="1440">
</ciscontroller>
<worker name="worker-machine" port="49901" max-concurrent-tasks="3" pinginterval="1"/>
</worker>

You mus also ensure the Manager of the Capital Integration Server Worker machine points to the dedicated manager set up (change the serverconnection element in the config/clientprops.xml file for this to point to the dedicated manager)

Dedicated Manager set-up

On the machine where there is dedicated manager (for Worker Capital Integration Server and CER computers), copy the plug-in jar file and the ldap.properties file into <your_installation/plugins>.

Note

It is recommended you consult your IT Helpdesk to set the ldap information of your organization in the format attached. Also note the plug-in code assumes that there is an environment variable defined, called userdomain that gives the network domain name. The source code of the plug-is available, if you wish to change the authentication mechanism in a different way.

Once the plug-in is installed, start the Capital Manager, Capital Integration Server and CER servers. DSO should work for Capital Device Modeler and CER. Open the appropriate login and enter your Windows user name and password.

Parent Topic:

Administering Domains, Roles and Users