Download to read offline
Uploaded byalvaro alcocer sotil
18 c oand_au
These training materials are confidential and intended solely for use by Accenture employees during Siebel training. The materials may only be used to help clients implementing Siebel, provided Accenture has a nondisclosure agreement in place. The materials cannot be used for competitive purposes or shared with third parties without permission.
More Related Content
More from alvaro alcocer sotil
![[002665]](https://cdn.slidesharecdn.com/ss_thumbnails/002665-150507182236-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
18 c oand_au
- 1. These training materialsare confidential to Siebel. They may not be used to train anyone other than Accenture employees who have attended Siebel training. If the materials are marked "Restricted Use Allowed" you may use the information to help clients who are evaluating vendors, one of which must be Siebel and you may use the information to help clients which are implementing Siebel. If they are not so marked, then the information may only be used to help clients who are implementing Siebel. In either case, you can not; (a) use the materials if you are involved developing or are likely to be involved in developing a product competitive to Siebel (b)use the materials for a client who is a competitor of Siebel; or (c) provide the materials to any third party, whether it is a client or otherwise. If you are going to be discussing Siebel with a client and using these training materials as the basis of information you provide to the client, you must also make sure Accenture has a nondisclosure agreement in place with the client (as part of a Consulting Services Agreement or otherwise). Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users - 1
- 2. Please adjust volumeto hear audio. Audio will play automatically for each slide upon advance. You may replay audio by clicking on the speaker icon in the upper right hand corner of each slide. Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users - 2
- 3. Creating an Organizationand Authenticating Users Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users - 3
- 4. Module Objectives This modulewill 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 Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 4
- 5. Organizational Hierarchy • Allowsfor the definition of organizations, divisions, and positions • Use a top-down approach to define the company structure Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 5
- 6. Defining Company Structure •Create the company structure by defining: Organizations Divisions Positions Responsibilities Employees • Company structure determines the records and views to which employees have access Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 6
- 7. Defining Organizations and Divisions • Allowsyour company to: Partition itself into logical groups, and then segregate data based on these groups Limit access to data based on the organization(s) and divisions(s) to which positions are assigned Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 7
- 8. Defining Divisions • Navigateto Group AdministrationDivisions Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 8
- 9. Defining Organizations • SetOrganization Flag to make a division an organization Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 9
- 10. Defining Organizations (cont’d) •Navigate to Group AdministrationOrganizations Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 10
- 11. Defining Employees • Navigateto User AdministrationEmployees to define employees Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 11
- 12. Defining Positions • Navigateto Group AdministrationPositions • Create positions based on your reporting structure Ask the question “Who needs to see what?” Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 12
- 13. Defining Responsibilities • Navigateto Application AdministrationResponsibilities Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 13
- 14. Position and Responsibility •There is no relationship between position and responsibility • Employees are assigned: One or more positions One or more responsibilities Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users Return to Knowledge Check 14
- 15. User Authentication • Authentication: Determines and validates the user’s identity Is controlled inside or outside of the Siebel application 3 Types of Authentication: • Database Authentication • Security Adapter Authentication • Web single Sign on Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 15
- 16. Open Authentication Architecture •Open Authentication adaptor provides three approaches for authentication Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 16
- 17. Siebel Authentication Manager •Runs within the Siebel object manager • Verifies credentials • Establishes connection to Siebel database Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 17
- 18. Two Types ofAuthentication • Internal authentication: Verifies against the relational database (RDBMS) and Siebel application • Also known as database authentication • External authentication: Uses an external file (or directory) and security adapter to authenticate users Siebel 2001 Configuration ©Accenture Creating an Organization and AuthenticatingCheck Return to Knowledge Users 18
- 19. Internal Authentication • Requiresa database (RDBMS) login and password for each user • Is the default for Siebel applications • Authenticates users accessing one or more Siebel applications Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 19
- 20. Example of Internal Authentication • Scenario:Rob is a new employee and requires access to Siebel Call Center • Administration steps: 1) Database Administrator (DBA) creates RDBMS login and password 2) DBA grants user proper access rights 3) System administrator creates Siebel employee record, which defines login, position, and responsibility Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 20
- 21. Example of Internal Authentication(cont’d) • User authentication steps: 1) Rob enters credentials (login and password) in Siebel Call Center login form 2) Rob’s login and password are verified in RDBMS 3) Rob’s position and responsibility are determined in the Siebel application 4) Rob starts using Siebel Call Center 5) If Rob’s credentials are not validated in the RDBMS and Siebel application, he receives an error message at login Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 21
- 22. External Authentication • Usesan external directory containing user credential and administrative information • Allows for centralized management of user authentication across Siebel and non-Siebel applications Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 22
- 23. External Authentication (cont’d) •Standard Siebel software provides prebuilt security adapters for LDAP and ADSI Lightweight Directory Access Protocol (LDAP) is an open network protocol • LDAP security adapter allows Siebel applications to access standard LDAP directories Active Directory Service (ADSI) • ADSI security adapter allows Siebel applications to access Microsoft Active Directory Security Adaptor Software Developers Kit • API documentation and sample code for building custom adaptors Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 23
- 24. Example of External Authentication • Scenario:Mary is a new customer and needs access to Siebel eService • Administration steps 1) Enable eService to communicate with external directory by updating parameters in eservice.cfg and eapps.cfg • Restart Siebel Server to activate changes in eservice.cfg • Restart Siebel Server and Web Server to activate changes in eapps.cfg 1) Update system preferences 2) Activate user registration workflows Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 24
- 25. Benefits of External Authentication • Froma user perspective Allows for login maintenance and self-registration Allows for Web Single Sign On • • Ability to log in only once and access all applications within a Web site or portal From an administration perspective Reduces overhead by not having to maintain database logins and passwords for each and every user External directory can be used for other applications Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 25
- 26. Maintaining Login Information • Externalauthentication allows Web users to maintain their login information Reduces burden on system administrator to maintain user login information Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 26
- 27. Web Single Signon (SSO) • Allows users to log in once via the Web to access multiple applications at a given site Siebel applications support Web Single Sign On by allowing users to provide one set of credentials for access to multiple applications • Authentication occurs at Web server level, not at application level Credential collection and verification is external to Siebel applications Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 27
- 28. Web Single Signon Configuration • Web Server (IIS, iPlanet, IBM HIS) Create a protected virtual directory Configure authentication client • Siebel Web Server Extension Edit eApps.cfg to designate the variable through which the authenticated user identifier will be passed • Siebel Security Adaptor Edit application CFG file to set security adaptor in Single Sign On mode Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 28
- 29. Web Single SignOn - Shared Infrastructure • Centralizes authentication for all Web Applications • Maintains global “Web site” session • “Pluggable” at the Web server level • Examples: Web server basic authentication SSL with client authentication Commercial authentication/authorization servers Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 29
- 30. Web Single Signon (SSO) - Data Flow Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 30
- 31. Guidelines for Using Authentication DesiredDeployment Database Security Web or Functionality Authenticati Adapter SSO on Requires no additional infrastructure Offers centralized components store for user credentials and roles Limits number of database accounts on RDBMS Supports dynamic user registration Creating an Organization Supports Web SSO Siebel 2001 Configuration and Authenticating Users ©Accenture 31
- 32. Summary Now that youhave 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 Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 32
- 33. Knowledge Check Take thisopportunity to check your knowledge of the concepts presented in this module. Try to answer the questions on the slide. The answer for each question will pop up as you advance the slide. Each answer may link back to the area within the presentation where that concept is presented. At the end of the section referenced you will find a ‘Return to Knowledge Check’ hyperlink, which will take you back to this slide. Question Answer Define your company’s organizational hierarchy in the Siebel application. • Navigate to Group Administration-> Divisions • Set Organizational Flag to make a division an organizat • Navigate to Group Administration-> Organizations • Navigate to User Administration-> Employees to define • Navigate to Group Administration->Positions • Create positions based on your reporting structure • Navigate to Application Administration-> Responsibilitie • Create Responsibilities • Assign Responsibilities and Positions to Employees Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 33
- 34. Knowledge Check (cont’d) Takethis opportunity to check your knowledge of the concepts presented in this module. Try to answer the questions on the slide. The answer for each question will pop up as you advance the slide. Each answer may link back to the area within the presentation where that concept is presented. At the end of the section referenced you will find a ‘Return to Knowledge Check’ hyperlink, which will take you back to this slide. Question Describe the difference between authentication and Access Control. Answer User authentication determines and validates the user’s identity. Access control restricts what is seen in the application according to view access, customer data, master data and application access. Describe internal and external authentication. Internal authentication: verifies the relational database and Siebel applicatio External authentication: uses an external file (or directory) and security adap Siebel 2001 Configuration ©Accenture Creating an Organization and Authenticating Users 34
Editor's Notes
- #4 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.
- #5 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
- #6 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.
- #7 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.
- #8 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.
- #9 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.
- #10 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).
- #11 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.
- #12 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.
- #13 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.
- #14 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.
- #15 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.
- #16 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.
- #17 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.
- #18 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.
- #19 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
- #20 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.
- #21 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.
- #22 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.
- #23 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.
- #24 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.
- #25 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.
- #26 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.
- #27 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.
- #28 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.
- #29 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.
- #30 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.
- #31 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.
- #32 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.
- #33 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