This section explains how to manage credential sets using the SSOAdminConsole application. | |||||||||||||||||||||||||||||||||||
Before Creating Credential SetsBefore 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, ENOVIAV5VPM) are particularly important and require attention before creating the credential set. These are:
SSO UsernameThe 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 ENOVIAV5VPM, and another credential set for the same user for accessing Remote File. P&O UsernameThe P&O username is particularly important for the
ENOVIAV5VPM In a properly defined working deployment, you typically want the P&O username to be the creator of ENOVIAV5VPM 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 ENOVIAV5VPM 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 LCA 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 LCA 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 ENOVIAV5VPM 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. WarningIf you decide to run in SSO mode and SSO is not fully activated, the creator of ENOVIAV5VPM 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 ENOVIAV5VPM database. What is meant by full activation of SSO mode is explained in Activating Single Sign-On. |
|||||||||||||||||||||||||||||||||||
Creating Credential SetsAn 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 LCA 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:
|
|||||||||||||||||||||||||||||||||||
Importing CredentialsYou can also import credentials from a previously created file with the
suffix A sample of this file, the Import2Users.creddif file is located in:
To import a credential file:
|
|||||||||||||||||||||||||||||||||||
Exporting Credentials
|
|||||||||||||||||||||||||||||||||||
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. |
|||||||||||||||||||||||||||||||||||
Implementing Your Own SSO RepositoryWhen 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.
|
|||||||||||||||||||||||||||||||||||
|