Learn Basic Single Sign-On Authentication
Taleo’s Basic SSO application grants Learn access to users without requiring that they enter
authentication login credentials (username and password). The access point is determined by the client and the SSO URL is made available to the users. Once the client performs authentication, the user is navigated to the Learn system using a simple HTML form post that contains their user ID. If Taleo’s standard MD5 hash security feature will be implemented, encryption token parameters must also be included in the form post.
The user authentication process varies from client to client depending on internal resource capabilities, and client processes and procedures.
Single Sign-on contributes to an enhanced end user experience and offers multiple advantages to the client that includes but is not limited to:
• Reduced cost associated with managing employee identities • Centralized authentication services
• Elimination of additional logins
• Minimized maintenance across servers • Reduced overhead costs
• Reduced call volume (inquiries related to login credentials) • Lowered enterprise help desk costs
The Learn Basic SSO application is defined below.
Taleo will provide each client with a basic SSO guide, a sample HTML form post and sample MD5 hash encryption code.
The basic SSO application dynamically authenticates user accounts for active users in the root or in one specific sub LearnCenter; this is a default SSO configuration that is defined by the client up front. User authentication in a specific sub requires query string parameters in order for the SSO application to perform deep linking.
• Elements Managed by the Client:
o Required Learn configurations. This includes the addition of all active users that will be accessing Learn via the basic SSO.
o The initial launch point: Making the SSO available to the user such as placing a link on an intranet or internet page and providing the user with the SSO access point details. o The authentication environment: Authenticating and approving the user within the client
network and assigning a unique ID that the Learn SSO application will recognize. o Optional: Provide the MD5 hash encryption token.
• Basic SSO HTML Parameters: The SSO application includes predefined parameters to process the user and grant them access; this includes a unique user ID and the MD5 hash token values. The application minimum requirement is the User ID that is sent in the Username field in the form post. The encrypted MD5 hash token values are optional depending on the security requirements.
• Client Process/SSO Launch Point: The client will configure the SSO URL and place the link on an internet or intranet page. The client URL should be configured to gather the necessary user
credentials and perform authentication, generate the encrypted token and the HTML form post then forward the HTML form post to the Learn custom handling page. The process will also include the addition of query string values to perform deep linking as necessary (the Learn ID or page as defined).
• Basic SSO Process: A Taleo custom handling page reads the HTML form post for each user. If the MD5 hash security feature is part of the application the first step in the process is the validation of the form post. Once this security step is complete, the application then attempts to locate the user based on their unique ID. When the user is identified in the Learn database, they will be directed to the default landing page in the root (or a pre-defined sub LearnCenter) and granted access.
o User rules that you configure in Learn as part of the user profile determine the content that is accessible and will not be affected by the basic SSO.
• Deep Linking: The basic SSO application has the ability to navigate users to a Sub LearnCenter or a specific page using query string parameters sent by the client with the HTML form post. This is referred to as deep linking. The optional variable values that can be sent with the HTML form post include:
o The Page and / or Learn ID: Page=<variable> or LCID=<variable>
o The SSO application will validate the user, grant access to users that are in an approved status, and direct the user to the LearnCenter and / or page based on the query string values. o If the user is passed to Learn without the Page and / or LCID values the application will
navigate them to the default landing page in the system root.
• Basic SSO Authorization: The SSO application grants user access according to the following authorization processes and criteria:
o Security: If required, the encryption token that is sent with the HTML form post is validated. If the application is unable to perform this level of validation, the user will not be granted access.
o User Access: The unique ID sent in the username field with the SSO request must match user values located in the Learn database (note: the SSO username is not necessarily the same as the username within Learn. For example, Email address may be the only common user attribute in the client’s network. In this scenario, the Email address is added to the username parameter of the HTML form post).
o User Status: All users are granted access regardless of their status in Learn. Standard Learn functionality will prevent users from accessing any features in Learn once they’ve been granted access, and a standard access denied message will be presented.
• Messaging: The basic SSO application uses standard messages that are available for the client to configure and customize in Learn.
Excludes: The following items are not included with the basic Single Sign-on application
• Managing users in Multiple LearnCenters (other than redirecting users with query string parameters using a sub Learn ID. Users must have appropriate memeberships in each sub or standard Learn functionality will prevent them from accessing training or any other Learn features).
• Additional parameters in the from post (other than the Username and Md5 hash token values) • Additional client specific security layers (MD5 hash is standard for the basic SSO application) • Creating user accounts
• Updating user accounts
• Additional deep linking functionality (LCID and page are the only additional parameters that can be sent in the query string)
• Managing groups or assigning users to groups
• Managing Supervisors or assigning Supervisors to users • Managing or Assigning Job Profiles
• Managing or assigning Development Plans • Managing or assigning Assessments • Managing or assigning Enrollments • Managing or assigning User Roles • Managing or assigning Skills
• Managing or assigning Certification Tracks • Processing ecommerce data
• User License Management
• Multiple error message definition and handling(the client will configure messages using standard Learn functionality)
• Encrypting data transport • Client data clean-up • Test data creation
• Advanced testing (beyond what is defined below)
--- Integration Services will include the following phases and deliverables:
Approval Phase Includes:
• Review of the basic SSO application • Approval of the Learn Basic SSO Guide
Service Delivery Phase Includes:
• Unit Testing (Provider)
o Up to five (5) test runs of the application against a copy of the Customer database. o Documentation of changes made to the application before each test run.
o Spot checking records against the testing parameters defined in the Basic SSO Guide. • Quality Assurance
User Testing Phase Includes:
• Testing of Integration in a distinct User Testing (UT) environment that is a copy of Customer’s Production environment.
• Testing environment (distinct URL) to be available to the Customer for up to 30 days from the day the integration is first run in the UT environment.
• Developer testing will consist of a random sampling of Customer data for verification. Customer User Test script creation and execution are the sole responsibility of the Customer.
• Refinement of the SSO to ensure requirements captured in the SSO guide are being met. New requirements introduced during this phase will be considered enhancements and will be charged on a time and materials basis at a rate of $210 per hour.
• A maximum of five iterations of running the integration script in test environment. This translates to the initial test and a maximum of two (5) refreshes of the test environment with the LearnCenter database from the Production environment to support Customer-side User Testing • Customer sign-off on Testing Phase.
• After 30 days the project will be closed and any additional use of the UAT site will be at an additional cost, unless there are ongoing Learn.com Development Deliverables. At such time, all fees shall be due and payable under this Statement of Work.
Migration Phase Includes:
• Migration and scheduling of Integration in Production LearnCenter environment. • Customer sign-off on project completion.
