Browse Prior Art Database

Method and Apparatus to Seemless Sign On based on Client Vault

IP.com Disclosure Number: IPCOM000132531D
Original Publication Date: 2005-Dec-20
Included in the Prior Art Database: 2005-Dec-20
Document File: 3 page(s) / 37K

Publishing Venue

IBM

Abstract

Today, a user has many userids and passwords to access many web sites, applications, etc. Moment you launch a browser, and access online banking, bill payment, confidential material, airline booking, and much more, one needs to remember multiple userid/passwords. This article outlines a proposal that includes a Client Vault repository containing user's credentials. When a challenge is received by the browser, a plugin written to the browser (or a handler in Axis engine, or an agent in Lotus notes, or similar plugin mechanisms) can access the repository and perform the search based on web site, realm etc. Once a search is performed and a match is found, the userid/password can be sent to the requesting server. Thus the user does not need to remember the many number of passwords and tokens, but the system helps by automating much of this and improves the user experience.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Method and Apparatus to Seemless Sign On based on Client Vault

Today, a user has many userids and passwords to access many web sites, applications, etc. Moment you launch a browser, and access online banking, bill payment, confidential material, airline booking, and much more, one needs to remember multiple userid/passwords. It is very common for users to have userid/passwords written in a notebook, text file, etc so that they can look it up and enter the right value every time. There are different approaches today to solve this. One approach is for client to register with an identity provider and log on to a portal to access rest of the applications. This does not cover all the scenarios nor all the applications tied to one or more client side identity providers (e.g, Passport, WS-Federation, Liberty etc). Those approaches would solve the problem when all of these applications get onto open standards, support them, tie into available infrastructure, have partnership with identity providers, etc. Before that becomes a reality, there exists the problem today where end user will need to look up the userid/password out of band and enter them everytime they access a new application/web site. Therefore, additional solutions are needed.

Proposed Solution

What is proposed is a simple but powerful mechanism to solve this customer pain. For every protocol of access, there is typically a mechanism to supply userid/password. In these discussions, we will use HTTP as an example but the invention is not restricted to that protocol only. When a user visits a web site, he gets a prompt (HTTP 401) or a form to login. When the challenge is issued by a web server, browser gets a 401 challenge asking for userid/password (as per spec, 'BasicAuth'). It includes a string named 'realm'. User looks at site (w3.ibm.com), and prompt indicating the realm ('w3' or 'Intranet'), and enters his userid/password. This proposed solution includes a repository or vault to store the userid/password associated with web site domains, and realm info. One such repository can be an XML file as outlined below. This file can be secured using the file system security. This is what end users typically do today (in spite of all warnings about the insecurity of this approach).

<client vault>

<cred entry>

<domain> *.ibm.com </domain> <realm> w3 </realm> <auth>

      <userid> bob </userid> <password> topsecret1 </password> </auth>

</cred entry>

<cred entry>

<domain> *.mybank.com </domain> <realm> customerBanking </realm> <auth>

      <userid> 1234567 </userid> <password> bank#$secret </password> </auth>

</cred entry>

</client vault>

Alternatively, they can be provided a tool to manage their userid and password.. so that the actual value itself is stored in encrypted form in a file, stored in the security chip that comes with their machines, in their smart cards, etc.

1...