|This section explains how to manage credential sets using the SSOAdminConsole application.|
Before Creating Credential Sets
Before discussing the SSOAdminConsole application, note that applications frequently need to access external systems and authenticate their users on these systems. The data allowing the connection are called credentials. A credential set contains a certain number of fields, varying from one application to another, in which the administrator enters data.
Before creating credential sets, you need to understand certain concepts and prepare your environment by creating certain data which you will later be required to input when creating the credential set for each application.
The number of fields in a credential set varies on the external application you want to authenticate to, and certain fields are more sensitive than others. The applications to which your end users want to connect are visible when creating credential sets:
Note that certain credential set data for certain applications (for example, ENOVIA V5 VPM) are particularly important and require attention before creating the credential set. These are:
The SSO username is the LDAP username (if you implemented LDAP authentication). You must create an LDAP user for each end user requiring access to your applications in SSO mode. The section Configuring and Customizing the LDAP Repository explains how to do so.
Each SSO username can then be referenced in one or more several credentials sets: one credential set is require per user and per application to which that user requires access. For example, you must create one credential set for a user for accessing ENOVIA V5 VPM, and another credential set for the same user for accessing Remote File.
The P&O username is particularly important for the
ENOVIA V5 VPM
In a properly defined working deployment, you typically want the P&O username to be the creator of ENOVIA V5 VPM objects, and you also want the P&O username to match the SSO username declared in your user registry (LDAP directory, ...) to avoid confusion.
Managing P&O users and the P&O database is described in your Enterprise Architecture Administration Guide.
User who starts the ENOVIA V5 VPM Server (and password)
To be able to start ENOVIA applications, an orbix daemon needs to be started. If it is not already started, you need to restart it. Once running, the process name is orbixd, and the owner of the process is typically root on UNIX and must be an administrator userid on Windows.
When you then start an application, for example ENOVIA VPM Lifecycle Navigator, the server manager process is first started. The process name is GW0SRVMG, and the process owner is the owner of the orbix process.
The server manager process then creates other processes, depending on the application launched. For example, for ENOVIA VPM Lifecycle Navigator, the name of the process is VDO0OrbServer. The owner of this process is an OS user defined in the credential set field User who starts the Server.
So you must first create at least one operating system (OS) userid with the following characteristics:
This OS userid:
You only need one OS userid on each OS running the ENOVIA V5 VPM server. This means that you can reference in the credential sets for a large number of users the same OS userid: this will avoid you having to create a separate OS userid for each user on each platform.
Note: the OS userid does NOT have to be declared in the P&O database.
If you decide to run in SSO mode and SSO is not fully activated, the creator of ENOVIA V5 VPM objects will be the OS user who started the server manager process and NOT the P&O user: this is not desired since you will lose visibility regarding the identity of the creator of objects in the ENOVIA V5 VPM database.
What is meant by full activation of SSO mode is explained in Activating Single Sign-On.
Creating Credential Sets
An administrator is responsible for creating users and their associated credential sets using the SSOAdminConsole application. This is typically the default wpsadmin user created when you set up your LDAP directory.
The following scenario explains how to start the SSOAdminConsole application.
Note: If you are deploying ENOVIA VPM Lifecycle Navigator, you can perform the same credential set management tasks in the Webtop application user interface, using the Administration and Preferences icon at the upper-right corner. The Administration page appears. Expand the Administration node: Administration -> General -> SSO and click SSO.
Updating and Deleting CredentialsAs SSO Administrator from the starting page, click the Update Credential Sets Instances button.
The following dialog box appears:
To update credentials:
To delete credentials:
You can also import credentials from a previously created file with the
A sample of this file, the Import2Users.creddif file is located in:
To import a credential file:
Deactivating Single Sign-On Credential Sets for the Default RepositoryIf you are using the default SSO Repository, delete the following file located in the installation path of the web application deployed in the application server:
WARNING: We do not recommend that you use the default SSO Repository. To create your own SSO Repository, see Implementing your Own SSO Repository. However, if you do use your own SSO Repository, you must manage its deactivation yourself.
When creating credentials, the default implementation of the SSO server uses a storage mechanism whereby credentials are stored in an XML file repository (a single XML file) in the installation path of the web application deployed in the application server.
However, the default implementation is not designed to support concurrent access from the SSO server and it does not support encryption.
Therefore, we strongly recommend that you implement your own SSO Repository as follows:
For the information necessary to implement the interface, please refer to the CAA RADE documentation.