Infrastructure Managed Services Portal Pass-through authentication Implementation Guide

Transcription

1 Integration Technologies Infrastructure Managed Services Portal Pass-through authentication Implementation Guide Version 2.1

2 THIS DOCUMENT CONTAINS CONFIDENTIAL INFORMATION OF THE UNISYS CORPORATION ( Unisys ). Recipient agrees, in consideration for receipt of this document, to use it solely for the limited purpose for which it was made available and not to transmit it and/or the information therein contained, in whole or in part, or to suffer such action by others, for any purpose, except with the written permission, first obtained, of Unisys. Recipient further agrees to surrender this document and all copies, or certify destruction of same to Unisys when the reason for its receipt has terminated. NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Unisys Copyright 2004, 2007 Unisys Corporation All rights reserved. UNISYS PROPRIETARY Revision History Version Date Author(s) Comments 1.0 8/16/2005 JM Initial Document 2.0 6/1/2007 JM Updated URL definitions /6/2007 JM Added SSL requirement

3 Table of Contents 1 Purpose of Document Customer / Partner Responsibilities Overview of Recommended Solution Architecture Basic View Pass-through Authentication Flow Overview Transaction Flow Web Access Request Authenticate User Request and redirect Redirected Request with appropriate parameters Authentication Success = Requested information Authentication Failed = Redirect to failure url URL parameter data items Pre-defined Unisys Service Portal data items Transaction Examples Authentication transaction in test mode... 8 Passed validation and login would occur Authentication transaction with Destination URL Authentication transaction without Destination URL Project Process Guide Approval and Identification Project Plan Support Requirements User Acceptance Testing Release into Production Page 3 of 11

4 1 Purpose of Document The goal of this document is to describe the Unisys electronic interface for exchanging user authentication information This document is a guide for Unisys customers and business partners who need to create an electronic interface for the systemic passing of user authentication information to the Portal application. The technical information is generally based on current accepted industry standards wherever possible in order to standardize and minimize development effort for the business partners and Unisys. This document does not attempt to define or constrain the tools or infrastructure a customer or business partner can use in order to implement the solution. General guidelines and recommendations are provided based on our experience. 2 Customer / Partner Responsibilities The Customer / Partner owns the development, configuration, and support of the processes and applications that validates the end user, formulates the login url-based parameters, and redirects the end users browser to Unisys. It is important to understand on-going support implications. 3 Overview of Recommended Solution A Shared Key authentication system will be used that provides the ability for a Customer developed application to authenticate with the Service Portal. The Customer developed application would typically be in the form of a web application that would authenticate the end user and redirect the user s browser to the portal with appropriate parameters. The Unisys Portal will receive the parameters, authenticate that it is a valid request via the Shared Key and then systemically log the user into the portal and route the user to the desired URL. Users will be validated that they are members of the Customer within the Unisys Service Management system. The valid user list will be provided to Unisys on an agreed upon periodic basis as part of the standard data load. Page 4 of 11

5 All communications between the end user and the Oracle Portal will be over a SSL connection to ensure security. 4 Architecture Basic View The following diagram shows the normal method of providing a Service Portal Passthrough Authentication solution from our external Customers / Partners and Unisys. Page 5 of 11

6 5 Pass-through Authentication Flow 5.1 Overview This section describes the transaction flow for the Pass-through authentication process. 5.2 Transaction Flow The normal course of operations and data exchange would usually take the following form: (1) Web Access Request (2) Authenticated user request and redirect to Unisys Service Portal Customer s internal Web Site End User s Browser (3) Redirected request with Appropriate parameters (4) Authentication success = Requested information Unisys Service Portal (5) Authentication failed = Redirect to failure url Note: All communications will be across a SSL connection Page 6 of 11

7 5.2.1 Web Access Request The End User would navigate to the designated web site internal to the Customer / Partner infrastructure Authenticate User Request and redirect The customer s internal website would: Authenticate the end user Determine the end user s Service Portal User-ID Generate a redirect response to the End User s browser containing the required url variables Redirected Request with appropriate parameters The Unisys Service Portal would authenticate the incoming authentication request and: Validate the Company can perform pass-through authentication Validate the Shared key for this Company Validate the User-ID is a valid member for this Company Authentication Success = Requested information If the authentication process is successful, the Unisys Service Portal will reply with the requested information Authentication Failed = Redirect to failure url If the authentication process fails, the Unisys Service Portal will redirect the End User s browser to the defined failure URL. 5.3 URL parameter data items The URL parameters consist of the following data items. Their descriptions and usage are detailed here. Each data item is listed with its name, its data type, a description and whether it is a required item or not. Page 7 of 11 Name Type Req? Description Company Identifier STRING Y Identifies the Company making the request. Pre-defined value provided by Unisys Shared Key STRING Y It is used in conjunction with the Company Identifier to authenticate the request. UserID STRING Y This is the address of the end user. This value must match value passed in the User Feed to the Service Management System.

8 Requested URL STRING N This is the destination URL for the End User. If not provided, the Portal will respond with the user s pre-defined home page. Mode STRING N If set to test this will provide a diagnostic screen that can be used during the development effort. Note: The Shared Key, UserID, and Requested URL parameters shall be passed as a single BASE64 encoded parameter string. Note: All communications will be across a SSL connection 5.4 Pre-defined Unisys Service Portal data items The Service Portal maintains the following data items to facilitate this pass-through authentication process. Their descriptions and usage are detailed here. Each data item is listed with its name, its data type, a description and whether it is a required item or not. Name Type Req? Description Company Identifier STRING Y Identifies the Company allowed to make the request. Shared Key STRING Y Used in conjunction with the Company Identifier to authenticate the request. Authentication failed URL STRING Y This is the destination URL for the End User if the authentication process fails. 6 Transaction Examples This section shows sample scenarios with their associated transactions 6.1 Authentication transaction in test mode An example to access the Authentication transaction in test mode with the following parameters: Page 8 of 11 Company = Multisys Shared Key = multisys UserID = autologin.user@multisys.com Requested Url = pge/multisys_home_pge Resulting transaction to the service portal would be: 2tleT1tdWx0aXN5cyZ1c2VyaWQ9YXV0b2xvZ2luLnVzZXJAbXVsdGlzeXMuY29tJnJlcXVy

9 bd1odhrwczovl3bvcnrhbc51bmlzexmuy29tl3bvcnrhbc9wywdll3bvcnrhbc9fu0vsv kldrv9qr1ivz2xvymfsl211bhrpc3lzx2xvz2lux3bnzs9ndwx0axn5c19it01fx1bhrq == Note: The Shared Key, UserID, and Requested URL parameters are passed as a single BASE64 encoded parameter string. Note: All communications will be across a SSL connection The service portal will return a result similar to the following: Company parameter Company status Mode Encoded pauth parameter Decoded pauth parameter Userid parameter Userid status Group in OID status User in Company Skey parameter Security Key Valid Requested URL Multisys Company validated with id: 499 Test c2tlet1tdwx0axn5cyz1c2vyawq9yxv0b2xvz2lulnvzzxjabxvsdglzexmuy29tjnjlcxvy bd1odhrwczovl3bvcnrhbc51bmlzexmuy29tl3bvcnrhbc9wywdll3bvcnrhbc9fu0vsv kldrv9qr1ivz2xvymfsl211bhrpc3lzx2xvz2lux3bnzs9ndwx0axn5c19it01fx1bhrq== multisys autologin.user@multisys.com User validated with id: *** Group Multisys-usergroup found in OID *** True multisys True /multisys_login_pge/multisys_home_pge Passed validation and login would occur 6.2 Authentication transaction with Destination URL An example to access the Authentication transaction with the following parameters: Page 9 of 11 Company = Multisys Shared Key = multisys

10 UserID = autologin.user@multisys.com Requested Url (deep link to Outlook FAQs)= pge/multisys_home_pge/answers Resulting transaction to the service portal would be: 1tdWx0aXN5cyZ1c2VyaWQ9YXV0b2xvZ2luLnVzZXJAbXVsdGlzeXMuY29tJnJlcXV ybd1odhrwczovl3bvcnrhbc51bmlzexmuy29tl3bvcnrhbc9wywdll3bvcnrhbc9 FU0VSVklDRV9QR1IvZ2xvYmFsL211bHRpc3lzX2xvZ2luX3BnZS9NdWx0aXN5c19 IT01FX1BHRS9hbnN3ZXJz The service portal would validate the transaction, log the user in, and navigate to ys_home_pge/answers 6.3 Authentication transaction without Destination URL An example to access the Authentication transaction with the following parameters: Company = Multisys Shared Key = multisys UserID = autologin.user@multisys.com Resulting transaction to the service portal would be: 1tdWx0aXN5cyZ1c2VyaWQ9YXV0b2xvZ2luLnVzZXJAbXVsdGlzeXMuY29t The service portal would validate the transaction, log the user in, and navigate to the user s defined home page. 7 Project Process Guide 7.1 Approval and Identification Approval of the overall project is required and must be scheduled for a timeslot suitable to both parties. While waiting for design and development work to start it is considered imperative that a number of key people for the project be identified and informed of their involvement. These would normally include: Unisys Project Manager Customer Project Manager Customer Analysts / developers Page 10 of 11

11 Test and user personnel to be involved Support and Network people to be involved. This is obviously a far from exhaustive list but it should give a general idea. Early definition of the project managers responsible for driving the project is considered vital to the success of the project. 7.2 Project Plan The production of an accurate and agreed project plan detailing the various steps and their timelines involved in the implementation of the interface is a primary requirement. 7.3 Support Requirements Unisys and the partner early in the project process should agree to the specifics of the support methodology. There maybe some design implications that may require specific processes in place. An understanding of the features & functions of the Unisys and partner s support operations promotes an understanding early in the process. 7.4 User Acceptance Testing This is a vital process that needs to involve the dedicated testers and a representative sampling of the end users themselves. User acceptance testing (or UAT as it is more commonly known) should include the following tests as a minimum requirement: Normal transactions Invalid transactions Customer Project Manager Approval and signoff is required at the conclusion of UAT in order to allow the release to proceed on schedule. 7.5 Release into Production After a successful UAT, the Customer will have their own release procedures, which they need to document and then perform in order to implement a new interface. Page 11 of 11