Module Overview
Welcome to Creating an Organization and Authenticating Users.
This module explains how to create an organization in Siebel applications by defining organizations, divisions, positions, responsibilities, and employees. The company structure ultimately determines record and view access. The module then goes on to present the concepts of internal and external authentication at a very high level. We have already discussed the concepts of Siebel Access Control and have created an organizational hierarchy in the Siebel application. Now we will learn about the different ways a user can be authenticated before accessing the Siebel application.
This module covers organization hierarchy, defining organizations and divisions, defining positions, defining responsibilities, and defining employees. It then covers the difference between authentication and access, Siebel Authentication Manager, types of authentication, internal authentication, external authentication, benefits of external authentication, Web single sign on (Web SSO), and guidelines for using authentication.
This module will accomplish the following:
Define your company’s organizational hierarchy in the Siebel application
Describe the difference between authentication and Access Control
Describe internal and external authentication and how each works in Siebel eBusiness applications
Now let’s begin our discussion with Organizational Hierarchy. The definition of a company’s hierarchical structure in the Siebel application affects the records and views to which employees have access. Variations of this graphical example will be used throughout the module.
Technically, an organization is always a division, while a division is not necessarily an organization. In other words an organization is a specific type of division. Organizations are created for the purpose of controlling access to data.
Organization setup impacts Access Control, and other tasks such as Assignment Manager. Assignment Manager is covered in another module.
Organization structure needs to be defined to in order to leverage benefits of Access Control. We covered Access Control in the previous module and over the next few slides we will discuss how to define a company structure.
Organizations are designed to represent the broadest divisions of your company. An organization controls the data access of the employees that are assigned to it. Defining an organization allows you to partition your company into logical groups and then segregate data based on these groups. Organizations can be internal, or they can be external.
Here are some examples for defining organizations:
If a company has a small number of distinct internal business units, you might want to use organizations to support organization-specific versions of a limited number of business entities such as products and price lists.
If you have a full-scale global deployment that encompasses multiple internal and external user businesses made up of multiple distinct business units, where some data should be only available to some units while other information needs to be shared at the corporate level, the company will benefit from implementing organizations.
You may have different Assignment Manager and workflow rules for different
organizations within your company.
One important point to note is that divisions need to be created in order to support the My
Team’s (or manager’s) views.
Divisions belong to organizations and have no direct effect on visibility. Divisions help you to group positions, to record addresses, and to maintain default currencies. User reporting structures are defined by their parent positions, but their country of operation and currency are defined by their division.
You can assign divisions to organizations. You can also “promote” a division to an organization. Multiple divisions can be arranged in a multilevel hierarchy by assigning some divisions as the parents of others.
A division with its Organization Flag checked is an organization. The mechanics for creating a new division are similar to that of creating a new organization. This will be discussed in greater detail later on in the module.
In order to view divisions, you can go to the Site Map and select Group Administration and from there select the Divisions view. From this screen you can add a division by pressing the new button. When defining a new division, you will need to set the division name and currency fields. Please refer to the Applications Administration guide for a detailed description on the fields that you can fill in when creating a division.
Why would you want to create a division and then set the Organization Flag? You would do this when you would not want another organization to access the data. Making a division an organization allows you to assign records to that organization which typically will be visible only to that organization.
The screen shot shows an example of a division defined as an organization (Southern Europe Consulting) and a division belonging to the default organization (Northern Europe Consulting).
Note that the mechanics for creating an organization and a division are very similar. When you create an organization, it appears as a division, too. Why would you want to create a new organization, using this Organizations view? Creating an organization in this view automatically creates a division, and sets the flag. It does exactly the same as setting the Organization flag on the division.
So in order to create an organization you will need to navigate to the group administration view from the site map and select ‘Organizations’ from the show drop down list. From here you can create a new record by pressing on the new button. Again the required fields are name and currency.
After employees have database accounts, you can set up these database users as Siebel application users. As an administrator, you can add an employee; associate positions, responsibilities, organizations, and territories with an employee; and remove any item from its association with an employee.
To set up an employee you will need to choose View > Site Map > User Administration > Employees from the application-level menu. The Employees view will then appear and you will need to add a new record and select at least one responsibility. You can also add organizations and positions and define employee skills.
A position represents a specific job slot within your company. As you define your company structure, define specific positions with each level in the hierarchy of divisions. Positions determine which records users have access to. You must be logged onto a server database to add positions.
Each position typically has only one associated employee. In some circumstances such as job-sharing situations, a position may have multiple associated employees. One employee can be associated with multiple positions. There can be only one primary employee for a position, but an employee can be primary for more than one position.
In order to create a position you will need to navigate to the group administration view from the site map and select ‘Positions’ from the show drop down list. From here you can create a new record by pressing on the new button.
There are two required fields when creating positions: Division and Position. To further define the reporting relationship, specify the parent position for the position.
Responsibilities determine which views users have access to. For example, the System Administrator responsibility allows access to all views.
Defining responsibilities lets you limit user access to views, and therefore to your Siebel application’s information and functions. You must assign responsibilities to all users. Without a responsibility, a user cannot use the Siebel application, because that user cannot access any views.
Define responsibilities that correspond to the major job functions in your organization. For example, you might create responsibilities for the marketing administrator, the sales manager, and sales representatives. The sales representative responsibility might have access to all views except those reserved for sales management, marketing administration, and applications administration. The sales manager responsibility might have access to the same views as the sales representative, plus the Sales Manager views, and so on.
So in order to create a responsibility you will need to navigate to the application administration view from the site map and select ‘Responsibilities’ from the show drop down list. From here you can create a new record by pressing on the new button. Enter a name and a description for the responsibility. And then select an organization for the responsibility. To define a responsibility, you must specify which views are available to that responsibility. To add views, do the following, first select the Views list and then add a new record.
From here you will need to select records from the Add Views dialog box and click OK.
Now we would like to make one final note: there is no relationship between position and responsibility. An employee is assigned one or more positions and one or more responsibilities but the two do not relate together.
Remember that Divisions and Positions are created in Group Administration and Responsibilities are created in Application Administration.
Now we will move on to another topic, the topic of Authentication. User authentication is the method that you use to identify a user. In other words, the way that we prove that you are who you say you are.
In this section, we will talk about the open authentication architecture that Siebel provides, a key component of that architecture, authentication manager, and three different approaches to authenticating a user - database authentication, Siebel security adaptors, and Web single sign on. Siebel's open authentication architecture provides a variety of ways for different approaches for our customers to approach user authentication.
When you think about user authentication, there are two distinct steps.
The first step, designated by the top horizontal box, is called credential collection, where we collect the credentials from the user. Credentials take the form of username and password in most cases, but they can be more sophisticated, using such things as digital certificates.
The second step of user authentication is called credential verification, where those credentials are verified against some authoritative source. Siebel provides a variety of ways to accomplish credential collection and credential verification so that you can deploy the Siebel applications into your security framework.
The first arrow, marked A, we call an approach database authentication. In this approach, the Siebel login form collects the username and password credentials and verifies them against the application database on the back.
The middle approach, marked B, we call security adaptor authentication. In this approach, the Siebel login form collects credentials, but the authentication manager calls out to an external authentication service via a component we call a security adaptor. This external authentication service may be a shared resource in your environment, such as a directory.
The last approach, marked C on the slide, we call Web single sign on. In this approach, both credential collection and credential verification are externalized and performed before the Siebel application ever sees a request. This approach allows customers to deploy Siebel Web applications into a larger framework, such as a Web site or a portal, that requires single sign on.
A key component of user authentication in the Siebel architecture is something we call the authentication manager. The authentication manager has a logic flow that determines how users will be authenticated using these, the three approaches we have been discussing.
The authentication manager's function is to take a set of user credentials, presented here as a blue circle, translate them or map them into a database account that will physically be used to connect to the database on the back end.
The authentication manager flow starts by being given a set of user credentials. First, the authentication manager determines if the application will use a security adaptor or not. If not, we move down the first vertical path, which indicates we will be doing database authentication. In this case, the presented user credentials are the equivalent of the database account, so it is a one-to-one mapping, and we are able to create a connection to the database right away. If you are using a security adaptor, the authentication manager does one additional check to see if that security adaptor is configured to run in Web single sign on mode.
If it is not, we move down the second vertical path, which is the security adaptor authentication approach. In this case, the authentication manager calls the security adaptor to verify the presented credentials. Next, it calls the adaptor to retrieve a database account and some additional roles for that user, and then it connects to the application database.
If the security adaptor was configured to use Web single sign on, we move to the final vertical path in this flowchart, and in this case, the authentication manager assumes that the user has already been authenticated, or the user credentials have already been verified, and simply has to verify what we call a trust token. This trust token ensures that the request is coming from a trusted source. Then the authentication manager makes a call to the security adaptor for the database account and roles information, and creates a connection to the back end database, thus starting the Siebel application session.
In this module, we discuss internal (database) authentication and external (security adapter) authentication.
External authentication includes Web Single Sign-On (SSO). This is covered later in the module.
The types of authentication discussed in this module are invoked by configuring the Authentication Manager properly.
To implement internal authentication, the following elements are required:
An account on the RDBMS for the user
A user record in the Siebel database where the User ID matches the user name for the database account
Database authentication, as you recall, utilizes the relational database for credential verification.
In this case, first, the user credentials are presented by the user. Second, they can optionally be encrypted to create a database account password that is unknown to the actual end user. And third, that database account is presented to the database to log the user in.
With internal authentication, the credentials (username and password) are collected in the Siebel login form and are verified against an account on the database server. A database (DB) account (login and password) must be created for each user on the database. Because of the requirement for database accounts, database authentication does not support dynamic user registration. This is an unattractive option for application deployments that include a large number external users, since you do not want to have to create database accounts for each of them.
Let’s discuss password encryption further: If the Application Encrypt Password parameter in the object manager is set to TRUE, then the Execute Login function will call a Siebel encryption routine before sending the username and password to the database for verification. The encryption routine is a mangling operation that generates an encrypted version of the password by shifting the bits and then performing a numerical calculation. Encryption prevents users from accessing the Siebel database directly.
Before we continue, we want to make sure you understand Internal Authentication fully, so we will give an example of Internal Authentication.
Suppose you have a new employee, let’s call him Rob and he requires access to Siebel Call Center. The administration steps that would need to be done are that the Database Administrator, otherwise known as the DBA, would create a database login and password for Rob.
The DBA would also need to grant Rob user property access rights.
The system administrator would then need to create a Siebel employee record for Rob, which would define his login, position and responsibility.
Now once the administration steps have been completed, there are a number of user authentication steps that would need to be followed.
When Rob, our user, wants to log into the Siebel Call Center using his details, he would need to enter his user name and password in the Siebel Call Center log in form. Now as you can recall the system administrator created these for him previously.
Now once Rob has entered his user name and password, these are verified in the database to make sure that they exist. If the database can find Rob’s details, his position and responsibility are determined in the Siebel application and he can start using his Siebel Call Center session.
If however the database could not verify his details, an error message would be returned to Rob at login, preventing him from beginning a Siebel Call Center session.
The External Authentication approach supports scalable centralized user management platforms, such as LDAP directories. It allows customers to centralize the user management for their users across multiple applications, and provides an extensible interface that customers can use to create security adaptors to their own proprietary authentication services.
Let's look at the data flow for this type of authentication. In this case, the user presents a set of user credentials to the authentication manager in step one. The authentication manager verifies those credentials against an external authentication service via the security adaptor in step two. Then the authentication manager retrieves a set of roles and a database account from the authentication service in step three. That retrieved database account is then used to connect to the application database.
The information returned from the external directory is (1) the Siebel User ID of the user logging in, (2) database credentials (username and password), and optionally (3) the views the users will see via roles specified in the directory.
Directories are simply a method of organizing information, such as phone book or email address. Directories can be used for many things. In this context, they are a collection of users, user passwords, and the resources they can access.
Siebel provides a number of out-of-the-box security adaptors based on the leading industry standards for authentication services.
The first is our LDAP adaptor, supports the Lightweight Directory Access Protocol. The LDAP security adaptor is certified to work with LDAP directories from iPlanet, IBM, and Novell.
Siebel also provides a security adaptor out-of-the-box based on Active Directory Services Interface, or ADSI. This security adaptor is certified to work with Microsoft Active Directory. ADSI was developed by Microsoft to allow access to all directories via one method.
In addition, if your authentication service is not supported by one of these two out-of-the-box adaptors, Siebel provides a security adaptor software developers kit that has API documentation and sample code that will assist you in building your own custom security adaptor. Customers may find the custom adapter toolkit on Siebel Support Web.
The security adapter used is specified in the Siebel Object Manager. To enable the application to use LDAP, there are parameters in the object manager and application configuration files that need to be set:
In the object manager, set the parameter Security Adapter Name = TRUE.
In the [Siebel] section of the application .cfg file, set the parameter SecurityAdapter=LDAP. LDAP (Lightweight Directory Access Protocol) is a version of DAP (Directory Access Protocol). DAP is part of the X.500 standard for network directory services and is too large for PC environments. Hence, LDAP was developed.
Before we continue, we want to make sure you understand External Authentication fully, so we will give an example of External Authentication.
Suppose you have a new customer, let’s call her Mary, and she needs access to Siebel eService. The administration steps that would need to be done are that eService firstly needs to be enabled in order to communicate with the external directory. To perform this step, certain parameters would need to be updated in the eService.cfg file and the eApps.cfg file.
Now in order for these changes to come into effect, the Siebel Server and Web Server will need to be restarted. The system preferences would need to be updated and the user registration workflows would need to be activated.
Now we will explain the benefits of external authentication from the user’s perspective in more detail on the following slides.
From the user perspective, their Web experience will be virtually the same, regardless of whether they use external or internal authentication.
Is is important to note that using LDAP alone is not enough to enable SSO. Details on SSO are coming up in the following slides.
From an administration perspective, database logins and passwords do not have to be maintained for each user which can save time overall.
External authentication supports dynamic user registration, where users can be created in real time either through self-registration processes or administrative views. A login page or a login form embedded in a Siebel application page is the means by which user credentials are collected. A user is required to login, thereby identifying himself or herself as a registered user, to be allowed access to protected views in Siebel applications.
Protected views are designated for explicit login. Views that are not designated for explicit login are available for anonymous browsing, if the Siebel application allows anonymous browsing.
Siebel applications also provide other features on a login form besides user credentials collection, such as remembering a user name and password and providing forgotten password support.
Alternatively, you can configure a Siebel application to bypass the login form by providing the required user ID and password in the URL that accesses the application.
Let's move on to our third approach for authentication, called Web single sign on.
The Web single sign on approach to authentication encourage users to return to Web sites by making the login process easy for them. Forcing users to log in multiple times to multiple related applications results in an unpleasant user experience.
With Web Single Sign On (SSO), user registration becomes the responsibility of the third-party authentication architecture and is no longer handled by the Siebel architecture (Siebel applications perform no verification in the SSO environment). This approach completely externalizes both the credential collection and verification steps to an external infrastructure.
This infrastructure is configured to operate at the Web server level and perform user authentication before the Siebel application ever sees a request. This approach enables Single Sign On when this external infrastructure is utilized with all applications on a Web site or portal.
Authentication infrastructure refers to third-party (non-Siebel) software that takes care of all user authentication related issues, from user registration, to user account and information management, to user authentication. Examples of third-party software include Netegrity’s SiteMinder and Entrust’s GetAccess.
In configuring Web single sign on, there are three primary components that need to be set up properly.
Web server. Siebel supports Web servers from Microsoft, iPlanet, and IBM. In this case, to support Web single sign on, you'll need to additionally create what's called a protected virtual directory on the Web server.
You will also need to configure the authentication client from the third-party authentication infrastructure on that Web server. On the Siebel Web server extension, you will need to edit the eApps config file to designate the way that we will retrieve the identity of the authenticated user. We provide a number of ways to retrieve that identity, either through http header variables, or through environment variables.
The third component that needs to be configured properly is the Siebel security adaptor. You need to modify the configuration of the security adaptor to ensure that it is set to operate in single sign on mode.
To really understand Web single sign on, let's first talk solely about the shared authentication infrastructure.
On the slide that you see here, all of the components are actually non-Siebel components, or third-party components. This may include the browser, the Web server, and authentication client, and authentication service in a directory.
The third-party authentication infrastructure is made up of the authentication client, the authentication service, and the directory. The way that these products work is that they are tightly integrated with the Web server, and can be placed to protect particular virtual directories on that Web server.
When a client - when a browser makes a request to the Web server, the authentication client traps that request and presents a credential collection dialogue to the end user. The presented credentials, or user credentials, are then verified against the authentication service. A successful verification means that that user is authenticated.
We see here on this slide how the Siebel application fits into this framework.
In this case, the Siebel application sits below that authentication infrastructure. The data flow here is that the user credentials are presented to the authentication client. The authentication client verifies those credentials to the authentication service. A successful verification then results in user identity being passed from the authentication client to the Siebel application through the Siebel Web server extension.
The Siebel authentication manager takes the authenticated user identity, seen in step two, and simply retrieves the database account and role information from the directory, based on that identity.
You should notice, in this case, the Siebel authentication manager and security adaptor did not actually verify the credentials, since that had already been done in step one. The retrieved database account, then again, similarly to the other approaches, is used to connect to the application database.
The decision on an approach is made at the application level and/or data source level, and not at the enterprise level. It is possible to mix and match approaches based on the specific application and/or data requirements.
The database authentication approach is the only one that does not require additional third-party components since it uses the same database server under the Siebel application to authenticate users via database accounts.
Both security adapters and Web SSO imply that the customer is using some type of external authentication service.
The database authentication approach is also the only approach that requires a database account for each user of the system. This makes it unattractive for application deployments that include a number of external users since you do not want to have to create DB accounts for them. Because of the requirement for database accounts, database authentication does not support dynamic user registration, where users can be created in real time either through self-registration processes or administrative views.
In the Web SSO case, user registration becomes the responsibility of the third-party authentication architecture and is no longer logically handled by the Siebel architecture.
Now that you have completed this module, you should be able to :
Define your company’s organizational hierarchy in the Siebel application
Describe the difference between authentication and Access Control
Describe internal and external authentication and how each works in Siebel eBusiness applications
