Integration Technologies

Infrastructure Managed Services

Portal Pass-through authentication

Implementation Guide

Version 1

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

UNISYS PROPRIETARY

Revision History

Version / Date / Author(s) / Comments
1.0 / 8/16/2005 / JM / Initial Document

Table Of Contents

1Purpose of Document

2Customer / Partner Responsibilities

3Overview of Recommended Solution

4Architecture Basic View

5Pass-through Authentication Flow

5.1Overview

5.2Transaction Flow

5.2.1Web Access Request

5.2.2Authenticate User Request and redirect

5.2.3Redirected Request with appropriate parameters

5.2.4Authentication Success = Requested information

5.2.5Authentication Failed = Redirect to failure url

5.3URL parameter data items

5.4Pre-defined Unisys Service Portal data items

6Transaction Examples

6.1Authentication transaction in test mode

Passed validation and login would occur

6.2Authentication transaction with Destination URL

6.3Authentication transaction without Destination URL

7Project Process Guide

7.1Approval and Identification

7.2Project Plan

7.3Support Requirements

7.4User Acceptance Testing

7.5Release into Production

1Purpose 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.

2Customer / 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.

3Overview 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 need to exist in the Unisys Service Management system. These users will be provided to Unisys on an agreed upon periodic basis.

4Architecture Basic View

The following diagram shows the normal method of providing a Service Portal Pass-through Authentication solution from our external Customers / Partners and Unisys.

Page 1 of 11

5Pass-through Authentication Flow

5.1Overview

This section describes the transaction flow for the Pass-through authentication process.

5.2Transaction Flow

The normal course of operations and data exchange would usually take the following form:

5.2.1Web Access Request

The End User would navigate to the designated web site internal to the Customer / Partner infrastructure.

5.2.2Authenticate 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

5.2.3Redirected 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

5.2.4Authentication Success = Requested information

If the authentication process is successful, the Unisys Service Portal will reply with the requested information

5.2.5Authentication 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.3URL 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.

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 email address of the end user. This value must match value passed in the User Feed to the Service Management System.
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.

5.4Pre-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.

6Transaction Examples

This section shows sample scenarios with their associated transactions

6.1Authentication transaction in test mode

An example to access the Authenticationtransaction in test mode with the following parameters:

Company = “Multisys”
Shared Key = “multisys”
UserID = “”
Requested Url =

Resulting transaction to the service portal would be:

Note: The “Shared Key”, UserID, and Requested URL parameters are passed as a single BASE64 encoded parameter string.

The service portal will return a result similar to the following:

Company parameter / Multisys
Company status / Company validated with id: 499
Mode / Test
Encoded pauth parameter / c2tleT1tdWx0aXN5cyZ1c2VyaWQ9YXV0b2xvZ2luLnVzZXJAbXVsdGlzeXMuY29tJnJlcXV
ybD1odHRwczovL2Vwb3J0YWwudW5pc3lzLmNvbS9wb3J0YWwvcGFnZT9fcGFnZWlkPT
gxLDE1OTQ2MSZfZGFkPXBvcnRhbCZfc2NoZW1hPVBPUlRBTFBST0Q=
Decoded pauth parameter / multisys
Userid parameter /
Userid status / User validated with id: 30679
Group in OID status / *** Group Multisys-usergroup found in OID ***
User in Company / True
Skey parameter / multisys
Security Key Valid / True
Requested URL /
&_schema=PORTALPROD

Passed validation and login would occur

6.2Authentication transaction with Destination URL

An example to access the Authenticationtransaction with the following parameters:

Company = “Multisys”
Shared Key = “multisys”
UserID = “”
Requested Url (deep link to Outlook FAQs)=

Resulting transaction to the service portal would be:

The service portal would validate the transaction, log the user in, and navigate to

6.3Authentication transaction without Destination URL

An example to access the Authenticationtransaction with the following parameters:

Company = “Multisys”
Shared Key = “multisys”
UserID = “”

Resulting transaction to the service portal would be:

The service portal would validate the transaction, log the user in, and navigate to the user’s defined home page.

7Project Process Guide

7.1Approval 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

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.2Project 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.3Support 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.4User 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 ManagerApproval and signoff is required at the conclusion of UAT in order to allow the release to proceed on schedule.

7.5Release 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 1 of 11