| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2015 E24814-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2015 E24814-01 |
|
Previous |
Next |
View PDF |
This topic describes security adapter options that can be implemented in a security adapter authentication environment or in a Web SSO environment. Unless noted otherwise, these options are supported by the Siebel LDAP and ADSI security adapters and by adapters that comply with the Siebel Security Adapter Software Developer's Kit (SDK) version 3.0. For more information, see 476962.1 (Article ID) on My Oracle Support.
Depending on your security adapter or Web SSO implementation, you might have to configure the following:
This topic describes how to configure the directory application user. The application user is not an actual user who logs into an application; it is a special user defined to handle access to the directory. The application user is defined as the only user with search, read and write privileges to the LDAP directory or Active Directory. This minimizes the level of access of all other users to the directory and the administration required to provide such access.
The application user must be defined in the following authentication strategies that implement a Siebel security adapter:
Security adapter authentication: LDAP, ADSI, some custom security adapter implementations
You do not have to define an application user if you implement a database security adapter.
Web SSO authentication
Whether or not an application user must be defined depends on how you have implemented the Web SSO solution.
The application user is the only user who can read or write user information in the directory. Therefore, it is critical that the application user has appropriate privileges to the directory. The application user must be defined in the directory with the following qualities:
The application user provides the initial binding of the LDAP or Active Directory server with the Application Object Manager when a user requests the login page. Otherwise, binding defaults to the anonymous user.
Assign the application user sufficient permissions to read any user's information in the directory and do any necessary administration:
In a Siebel security adapter implementation, the application user must have search and write privileges for all user records in the directory. In a Web SSO implementation, the application user must have, at least, search privileges.
For ADSI authentication, it is recommended that you use the Active Directory Delegation of Control Wizard to define privileges for users in Active Directory.
If you are using a Microsoft Active Directory server, then you must use the Delegation of Control Wizard to assign the following permissions to the application user on the Users base DN:
Create, delete, and manage user accounts
Reset passwords on user accounts
Read all user information
If you are configuring an ADSI security adapter, then the application user must either be a domain user or have access to the directory server. If the application user cannot access the directory server, then the authentication process fails.
Permissions for the application user must be defined at the organization level (for example, OU for LDAP).
The following procedure describes how to define the application user.
To define the application user
Define a user in the directory, using the same attributes as for other users.
Assign values in appropriate attributes that contain the following information:
Username. Assign a name of your choice. If you implement an adapter-defined user name, then use that attribute (for further information, see "Configuring Adapter-Defined User Name"). Otherwise, use the attribute in which you store the Siebel user ID, although the application user does not have a Siebel user ID.
Password. Assign a password of your choice. Enter the password in unencrypted form. If you are using an Active Directory, then you specify the password using Active Directory user management tools, not as an attribute.
You maintain an unencrypted password for the application user in the directory, while an encrypted version of the password is used in other phases of the authentication process. An encryption algorithm is applied to the application user password before it is sent to the database. The application user login must also be set up with the encrypted version of the password.
Assign appropriate permissions to the application user in the directory as described in "About Application User Permissions".
For your Siebel security adapter, define the following parameter values for the security adapter's enterprise profile (such as LDAPSecAdpt or ADSISecAdpt) on the Siebel Gateway Name Server.
ApplicationUser. Enter the application user's full distinguished name (DN) in the directory.
For example, ApplicationUser can be set as in the following example:
ApplicationUser = "uid=APPUSER, ou=people, o=example.com"
ApplicationPassword. Enter the application user password (unencrypted).
For information about setting Siebel Gateway Name Server configuration parameters, see "Siebel Gateway Name Server Parameters". For Developer Web Client, define these parameters in the corresponding section in the application configuration file, such as uagent.cfg for Siebel Call Center. For Gateway Name Server authentication, define these parameters in the gateway.cfg file.
Typically, user administration in an LDAP or ADSI server is performed through the application user. In addition, user policies that are set for the entire directory apply to the application user as well as to all other users.
If you implement a password expiration policy in the directory, then exempt the application user from the policy so the application user's password will not expire. To do this, set the application user's password policy explicitly after the application user sets the password policy for the whole directory. For more information about account policies and password expiration, see "Login Security Features".
The checksum validation option verifies that the security adapter loaded by the authentication manager is the correct version. It is recommended that you use checksum validation to make sure that the appropriate security adapter provides user credentials to the authentication manager for all users who request access.
Checksum validation for security adapters can be implemented in the following authentication strategies:
Security adapter authentication: LDAP, ADSI, custom (not database authentication)
Web SSO authentication
You can implement checksum validation with the Siebel checksum utility that is included when you install your Siebel application.
Checksum validation supports the following principles:
A CRC (cyclical redundancy check) checksum value for the security adapter library file (such as the DLL file on Windows) is stored as a configuration parameter value for the security adapter.
When a security adapter provides a user identity and database account to the Application Object Manager, a checksum value is calculated for that security adapter.
The user is granted access if the two checksum values are equal.
The following procedure outlines the steps in implementing checksum validation.
To configure checksum validation
Enter and run the following command at a command prompt, using the required security adapter library file name (such as the DLL file on Windows) as the argument:
checksum -f filename
The utility returns the checksum value.
For example, if you are using an LDAP security adapter, then the following command:
checksum -f sscforacleldap.dll
returns something similar to:
CRC checksum for file 'sscforacleldap.dll' is f49b2be3
|
Note: You must specify a different DLL file if you are using an ADSI security adapter or a custom security adapter. |
For the security adapter you are using, set the CRC configuration parameter to the checksum value that is calculated in Step 1.
For information about setting Siebel Gateway Name Server configuration parameters, see "Siebel Gateway Name Server Parameters". For Developer Web Client, define these parameters in the corresponding section in the application configuration file, such as uagent.cfg for Siebel Call Center. For Gateway Name Server authentication, define these parameters in the gateway.cfg file.
In previous Siebel CRM releases, the CRC checksum value was set using the Security Adapter CRC system preference, rather than a configuration parameter.
|
Note: The checksum value in this procedure is an example only. You must run the checksum utility as described to generate the value that is valid for your implementation. In addition, you must recalculate the CRC checksum value and update the CRC parameter value each time you upgrade your Siebel Business Applications, including each time you apply a Siebel Patchset. |
This topic describes how to use TLS to transmit data between a security adapter provided with Siebel Business Applications and an LDAP directory or Active Directory. Secure communications for the Siebel security adapter can be implemented in the following authentication strategies:
Security adapter authentication: LDAP, ADSI, custom (not database authentication)
Web SSO authentication
The setup you must do to implement TLS differs depending on whether you implement the LDAP or ADSI security adapter. If you use the LDAP security adapter to authenticate against Active Directory, then you must configure TLS between the LDAP security adapter and the Active Directory server if you want to manage user passwords or create new users in the Active Directory. Implementing TLS in these circumstances is a requirement of Microsoft Windows and Active Directory.
The following procedure describes how to configure TLS for the LDAP security adapter.
To configure TLS for the LDAP security adapter
Set the SslDatabase parameter value for the security adapter (LDAPSecAdpt) to the absolute directory path of the Oracle wallet.
The Oracle wallet, generated using Oracle Wallet Manager, contains a certificate for the certificate authority that is used by the directory server. For information about generating the database file for an LDAP authentication environment, see "Creating a Wallet for Certificate Files When Using LDAP Authentication with TLS".
Set the WalletPassword parameter for the LDAP security adapter (LDAPSecAdpt) to the password assigned to the Oracle wallet.
The following procedure describes how to configure TLS for the ADSI security adapter.
To configure TLS for the ADSI security adapter
Set up an enterprise certificate authority in your domain.
Set up the public key policy so that the Active Directory server automatically demands a certificate from that certificate authority.
Set the profile parameter UseSsl to True for the ADSI Security Adapter profile (alias ADSISecAdpt).
For information about setting Siebel Gateway Name Server parameters, see "Siebel Gateway Name Server Parameters".
You can configure your authentication system so that a designated directory entry contains a database account that is shared by many users; this is the shared database account. The shared database account option can be implemented in the following authentication strategies:
Security adapter authentication: LDAP, ADSI, custom (not database authentication)
Web SSO authentication
By default, the shared database account option is not implemented, and each user's database account exists in an attribute of that user's record in the directory. Because all externally authenticated users share one or a few database accounts, the same credentials are duplicated many times. If those credentials must be changed, then you must edit them for every user. By implementing a shared credential, you can reduce directory administration.
The shared database account option can be specified for the LDAP and ADSI security adapters as follows:
The shared database account credentials can be specified in an attributes of the shared database account record in the directory. Database credentials are retrieved from the shared database account if they are available to be extracted. If database credentials are not available from the shared database account, then they are instead retrieved from the user. For information, see "Storing Shared Database Account Credentials as Directory Attributes".
The shared database account credentials can be specified as profile parameters (SharedDBUsername and SharedDBPassword) for the LDAP or ADSI Security Adapter profiles. If you want to implement a shared database account, then it is recommended that you specify database credentials as profile parameters. For information, see "Storing Shared Database Account Credentials as Profile Parameters".
When storing database credentials in a directory attribute, both the user name and password are stored as plain text, even if you implement database credentials password hashing (in this case the hashed password is maintained in the database, while an unhashed version of the password is stored in the directory). Specifying database credentials as profile parameters avoids having to store database credentials as plain text in the directory.
Even if you implement a shared database account with external directory authentication, the shared database account cannot be used for any user who requires administrator access to Siebel Business Applications functionality, for example, any user who has to perform Siebel Server management and configuration tasks. For these users, you must either:
Create a separate database account.
The database account user ID and password you create for the user must match the user ID and password specified for the user in the external directory.
Do the following:
Implement LDAP or ADSI authentication for the Gateway Name Server.
Create a user account record in the directory for the user requiring administrator access.
In the attribute of the record that is used to store role information, specify the user role that is required to access the Gateway Name Server: Siebel Administrator is the default role.
The following topics describe in more detail how the LDAP and Active Directory servers use the shared database account option.
This topic describes how to implement a shared database account and store the database credentials as attributes of the directory entry you create for the shared database account. This option is available to you when you use either the LDAP or ADSI security adapters.
To store shared database credentials in an attribute of the directory entry
Create a database account to be shared by all users who log into a given Siebel application; the account must have administrator privileges.
Create a designated entry in the directory, and enter the user name and password parameters for the shared database account in one of that entry's attributes, such as the dbaccount attribute. You might have to create this attribute.
|
Note: The user name and password you specify for the shared database account must be a valid Siebel user name and password and must have administrator privileges. |
For information about formatting a directory attribute that contains the database account, see "Requirements for the LDAP Directory or Active Directory".
For each security adapter that implements this shared database account, specify values for the parameters shown in the following table.
| Parameter | Value |
|---|---|
| CredentialsAttributeType | Enter the attribute in which the database account is stored in the directory, for example, dbaccount. |
| SharedCredentialsDN | Enter the distinguished name (including quotes) for the designated entry, such as:
|
For information about setting Siebel Gateway Name Server configuration parameters, see "Siebel Gateway Name Server Parameters". For Developer Web Client, define these parameters in the corresponding section in the application configuration file, such as uagent.cfg for Siebel Call Center. For Gateway Name Server authentication, define these parameters in the gateway.cfg file.
This topic describes how to configure a shared database account for an LDAP directory or Active Directory and how to store the database credentials for the account as parameters of either the LDAP or the ADSI Security Adapter profile.
It is recommended that you store shared database account credentials as profile parameters unless you have to store more than one set of database credentials, as only one set of database credentials can be stored as profile parameters.
To store shared database credentials as profile parameters
Navigate to the Administration - Server Configuration screen, Enterprises, and then the Profile Configuration view.
Select either the LDAPSecAdpt profile or the ADSISecAdpt profile.
Specify values for the following parameters for the LDAPSecAdpt or ADSISecAdpt profile.
| Parameter | Value |
|---|---|
| SharedDBUsername | Enter the user name to connect to the Siebel database. |
| SharedDBPassword | Enter the password to connect to the Siebel database |
|
Note: You must specify a valid Siebel user name and password for the SharedDBUsername and SharedDBPassword parameters. |
You can configure your authentication system so that the user name presented by the user and passed to the directory to retrieve a user's database account is not the Siebel user ID. For example, you might want users to enter an adapter-defined user name, such as their Social Security number, phone number, email address, or account number. The security adapter returns the Siebel user ID of the authenticated user and a database account from the directory to the authentication manager.
The adapter-defined user name option can be implemented in the following authentication strategies:
Security adapter authentication: LDAP, ADSI, custom (not database authentication)
Web SSO authentication
The adapter-defined user name must be stored in one attribute in your directory, while the Siebel user ID is stored in another attribute. For example, users can enter their telephone number, stored in the telephonenumber attribute, while their Siebel user ID is stored in the uid attribute.
The UsernameAttributeType configuration parameter defines the directory attribute that stores the user name that is passed to the directory to identify the user, whether it is the Siebel user ID or an adapter-defined user name. The OM - Username BC Field (alias UsernameBCField) parameter for the Application Object Manager defines the field of the User business component that underlies the attribute specified by UsernameAttributeType.
Even if other requirements to administer user attributes in the directory through the Siebel client are met, you must also set the UsernameAttributeType parameter for the security adapter, and set the OM - Username BC Field parameter. If you do not define these parameters appropriately, then changes through the Siebel client to the underlying field are not propagated to the directory.
For example, for users to log in with their work phone number, you must specify UsernameAttributeType to be the directory attribute in which the phone number is stored, for example, telephonenumber, and you must define OM - Username BC Field to be Phone #, the field in the User business component for the work phone number.
The following procedure outlines how to configure an adapter-defined user name.
To configure an adapter-defined user name
For each security adapter (such as LDAPSecAdpt) that implements an adapter-defined user name, define the following parameter values:
| Parameter | Value |
|---|---|
| UseAdapterUsername | TRUE |
| SiebelUserNameAttributeType | The attribute in which you store the Siebel user ID, such as uid (LDAP) or sAMAccountName (ADSI). |
| UsernameAttributeType | The attribute in which you store the adapter-defined user name, such as telephonenumber. |
For information about setting Siebel Gateway Name Server configuration parameters, see "Siebel Gateway Name Server Parameters". For Developer Web Client, define these parameters in the corresponding section in the application configuration file, such as uagent.cfg for Siebel Call Center. For Gateway Name Server authentication, define these parameters in the gateway.cfg file.
Determine the field on the User business component that is used to populate the attribute in the directory that contains the adapter-defined user name.
The Application Object Manager parameter to be populated is OM - Username BC Field.
For information about working with Siebel business components, see Configuring Siebel Business Applications. For information about working with configuration parameters, see Siebel System Administration Guide.
Using Siebel Server Manager, specify the User business component field name as the value for the OM - Username BC Field parameter. You can provide this value at the Enterprise, Siebel Server, or component level. If this parameter is not present in the parameters list, then add it.
|
Note: The OM - Username BC Field parameter is case sensitive. The value you specify for this parameter must match the value specified for the parameter in Siebel Tools. |
If you do not specify a field in the OM - Username BC Field parameter, then the Siebel security adapter assumes that the Login Name field of the User business component (the Siebel user ID) underlies the attribute defined by the UsernameAttributeType parameter.
The anonymous user is a Siebel user with very limited access. The anonymous user (defined in the Siebel database) allows a user to access a login page or a page containing a login form. For LDAP and ADSI authentication, the anonymous user must have a corresponding record in the user directory.
The anonymous user is required even if your applications do not allow access by unregistered users. When an Application Object Manager thread first starts up, it uses the anonymous user account to connect to the database and retrieve information (such as a license key) before presenting the login page.
If you implement security adapter or database authentication, then you can allow or disallow unregistered users to browse a subset of an application's views. Unregistered users access Siebel application views and the database through the anonymous user record.
If you allow anonymous browsing, then users can browse views that are not flagged for explicit login. If you disallow anonymous browsing, then unregistered users have no access to any of the application's views but do still have access to an application's login page. For additional information on enabling anonymous browsing, see "Process of Implementing Anonymous Browsing".
The following procedure describes how to configure the anonymous user. The anonymous user for employee applications must be associated with an appropriate position and responsibility.
To configure the anonymous user
If you are using database security adapter authentication, then create a database account for the anonymous user.
If you are using LDAP or ADSI security adapter authentication, then define a user in the directory using the same attributes as used for other users. Assign values in appropriate attributes that contain the following information:
Siebel user ID. Enter the user ID of the anonymous user record for the Siebel application you are implementing in the attribute in which you store the Siebel user ID, for example, GUESTCST.
Password. Assign a password of your choice. Enter the password in unencrypted form. If you have implemented Active Directory, then you specify the password using Active Directory user management tools, not as an attribute.
Specify values for the following parameters, either when configuring the SWSE logical profile (recommended), or by editing the eapps.cfg file manually:
AnonUserName. Enter the user name required for anonymous browsing and initial access to the login pages of the application you are implementing, in this example, GUESTCST.
AnonPassword. Enter the password associated with the anonymous user. If necessary, you can manually encrypt this password using the encryptstring.exe utility. For additional information, see "Encrypting Passwords Using the encryptstring Utility".
You can define an anonymous user for a single application or as the default for all the Siebel Business Applications you deploy. Even if the anonymous user is specified as the default, any single application can override the default.
If you use one anonymous user for most or all of your applications, then define the anonymous user in the [defaults] section of the eapps.cfg file. To override the default value for an individual application, list the AnonUserName and AnonPassword parameters in the application's section of the eapps.cfg file, for example, the [/eservice] section.
Responsibilities assigned to each user in Siebel Business Applications provide users with access to particular views in the application. Responsibilities are created in the Siebel application and are stored in the Siebel database. One or more responsibilities are typically associated with each user in the Administration - Application screen.
Creating roles in the LDAP directory or Active Directory is another means of associating Siebel responsibilities with users. Roles are useful for managing large collections of responsibilities. A user has access to all the views associated with all the responsibilities that are directly or indirectly associated with the user.
You can choose to store users' Siebel responsibilities as roles in a directory attribute instead of in the Siebel database in the following authentication strategies:
Security adapter authentication: LDAP, ADSI, custom (not database authentication)
Web SSO authentication
|
Note: You can store Siebel user responsibilities as roles in a directory attribute but you cannot store Siebel user positions as roles in a directory attribute. |
It is recommended that you assign responsibilities in the database or in the directory, but not in both places. If you define a directory attribute for roles, but you do not use it to associate responsibilities with users, then leave the attribute empty. If you use roles to administer user responsibilities, then create responsibilities in the Siebel application, but do not assign responsibilities to users through the Siebel application interface.
To configure roles defined in the directory
In the directory, define a directory attribute for roles.
To make sure that you can assign more than one responsibility to any user, define the roles directory attribute as a multivalue attribute. The security adapters supported by Siebel Business Applications cannot read more than one responsibility from a single-value attribute.
For each user, in the directory attribute for roles, enter the names of the Siebel responsibilities that you want the user to have. Enter one responsibility name, such as Web Registered User, in each element of the multivalue field. Role names are case-sensitive.
Configure the security adapters provided with Siebel Business Applications to retrieve roles for a user from the directory by setting the RolesAttributeType parameter for the LDAP or ADSI security adapter. For example, for the LDAP security adapter, define the following parameter:
RolesAttributeType= attribute_in_which_roles_are_stored
For information about setting Siebel Gateway Name Server configuration parameters, see "Siebel Gateway Name Server Parameters". For Developer Web Client, define these parameters in the corresponding section in the application configuration file, such as uagent.cfg for Siebel Call Center. For Gateway Name Server authentication, define these parameters in the gateway.cfg file.
