Bookshelf Home | Contents | Index | Search | PDF

Security Guide for Siebel eBusiness Applications > Security Adapter Authentication > Siebel Security Adapters >

Requirements for Directory

---

You must provide your own directory product, whether it is one of the servers supported by Siebel security adapters or another directory of your choice.

If you provide one of the Siebel-supported servers, you may use a Siebel-compliant security adapter or another adapter of your choice.

If you provide a directory other than those supported by the Siebel security adapters, then you are responsible for supporting the directory with the security adapter you implement. For specific information about third-party products supported by Siebel eBusiness Applications, see System Requirements and Supported Platforms for your Siebel application.

Your directory must store, at a minimum, the following data for each user. Each piece of data is contained in an attribute of the directory.

Siebel user ID. This attribute value must match the value in the user ID field for the user's Person record in the Siebel Database. It is used to identify the user's database record for access control purposes.
Database account. This attribute value must be of the form username=U password=P, where U and P are credentials for a database account. There may be any amount of white space between the two key-value pairs and no space within each pair. The keywords username and password must be lowercase.
Username. This attribute value is the key passed to the directory which identifies the user. In a simple implementation, it may be the Siebel user ID, and so it may not need to be a separate attribute.
Password. The storage of a user's login password differs between LDAP servers and Active Directory Server (ADS).
LDAP. If the user authenticates through the directory, such as in a security adapter authentication implementation, then the login password must be stored in an attribute.

If the user is authenticated by an external authentication service, as might be the case in a Web SSO implementation, a password attribute is not required.

ADS. ADS does not store the password as an attribute. The password can be entered at the directory level as a function of the client, or the Siebel ADSI security adapter can use ADS methods to create or modify a password.

If the user authenticates through the directory, such as in a security adapter authentication implementation, then the login password must be stored. If the user is authenticated by an external authentication service, as might be the case in a Web SSO implementation, a password is not required.

You can use other user attributes to store whatever data you want, such as first and last name. Authentication options that you choose may require that you commit additional attributes.

An additional piece of information, roles, is supported by the Application Object Manager, but is not required. Roles are an alternate means of associating Siebel responsibilities with users. Responsibilities are typically associated with users in the Siebel Database, but they can instead be stored in the directory. Leave role values empty to administer responsibilities from within Siebel applications.

For more information about this type of role, see Roles.

User Privileges

Depending on your authentication and registration strategies and the options that you implement within your strategy, you must define users in the directory that read and may possibly write user information in the directory. It is critical that users who read or write data in the directory have appropriate search and write privileges to the directory. Depending on your authentication and registration strategies, these users may include:

The application user. If you implement the application user, then the application user is the only user that must be able to search and write records to the directory.

For information about the application user, see Application User.

The anonymous user. If you do not implement an application user and you allow user self-registration, then the anonymous user must have search and write privileges to the directory.

For information about the anonymous user, see Anonymous User.

For information about user self-registration, see Implementing Self-Registration.

Internal administrators and delegated administrators. If you do not implement an application user, then each user who creates or modifies other users must have search and write privileges to the directory. Internal administrators and delegated administrators may be included in this group.

For information about internal and external registration of users, see Internal Administration of Users and Delegated (External) Administration of Users.

Bookshelf Home | Contents | Index | Search | PDF