Patent Application
20090217367
Generally, the present invention relates to computing environments involving single-sign-on (SSO) experiences. Particularly, although not entirely, it relates to SSO credential usage in a volatile session, such as per a defined length of time, while a computer is on, etc., and or for use amongst applications of an application suite or a plurality of (un)related applications. Other features contemplate credential lifetime, destruction of credentials, timing of application usage, and prompting users Retrofitting existing SSO services and providing computer program products and computing interaction, to name a few, are still other aspects.
Newer computer operating systems such as Linux, Windows XP, or Windows Vista provide multiple credential stores for network client applications' usage. These credential stores usually are utilized to provide mechanisms for software applications to securely store credentials for the user, and retrieve them later for authentication to provide a single-sign-on (SSO) experience.
As is known in the art, certain software applications have authentication engines “enabled” to detect the existence of an SSO software installation within the operating system of a computing device and its availability during an SSO session to store and/or retrieve credentials actively. An example of one such application would be Novell's Groupwise eMail software or Novell's Network Client software. Another embodiment allows for “helper” software, provided by the SSO components installed on the operating system, to intercept authentication requests and dialogs by employing operating system available features to perform screen scraping (as it is commonly known) to capture credentials and store and retrieve user credentials for use. An example of such helper software is Novell's Secure Login. In turn, a hybrid approach utilizes the “enabled” software embodiment to perform SSO through the use of “helper” software in the middle. An example of this type of SSO software would be Novell's CASA brand software (Common Authentication Services Adapter), Novell's Secure login, or Novell's SecretStore. In still another embodiment, a system administrator or the user pre-populates a SSO credential store.
In any embodiment, however, there is no present mechanism that allow applications to share a set of common credentials for authentication purposes. In turn, convenience and efficiency is lost since modification of credentials per a given application translates into needing to updating the credentials per other applications. In an application suite environment, it is known that multiple software components can be used or started independently of one another. However, the suite is incapable of acquiring knowledge that a user might have already started other components of the software and has already authenticated to one or more other components. In turn, user effort in coordinating credentials is high.
Also, it presently exists that SSO sessions might be temporarily undertaken at a borrowed computing device, e.g., a computing kiosk, for work, such as for twenty minutes in a lobby, two days during a hotel stay. In such scenarios, however, no present mechanism safeguards the credentials, after use, other than manual destruction by users or applications. In other words, existing SSO frameworks maintain a persistent SSO life cycle beyond the life of a user SSO session. Further, if the machine is borrowed by multiple users each having their own need to engage in an SSO session, nothing is available to allocate SSO credentials amongst the pluralities of users, each with their own safeguarding concerns.
Ultimately, nothing in existing SSO frameworks provides means to support shared credentials in a volatile session for security or other considerations or in shared hardware or software environments.
In view of these various problems, there is need in the art of credentialing for SSO experiences to share credentials. There is also a need to safeguard SSO credentials in a volatile session, including the destruction of credentials, perhaps. Contemplating shared credentials and volatile sessions are not mutually exclusive, needs in the art extend to overcoming both problems individually and collectively. In that many computing configurations already have existing SSO technology, it is further desirable to leverage existing configurations by way of retrofit technology, thereby avoiding the costs of providing wholly new products. Taking advantage of existing frameworks, such as the CASA (Common Authentication Service Adapter) software offering by Novell, Inc., the common assignee of this invention, is another feature that optimizes existing resources. Any improvements along such lines should further contemplate keeping user interaction to a minimum, for otherwise, the SSO advantages are minimized or lost) and to maintain good engineering practices, such as automation, relative inexpensiveness, stability, ease of implementation, security, etc.
The foregoing and other problems become solved by applying the principles and teachings associated with the hereinafter-described SSO in volatile session or shared environment. At a high level, methods and apparatus utilize a single-sign-on (SSO) framework on one or more physical or virtual computing devices. During use, it is determined whether SSO credentials are used in a volatile session, such as definite length of time, while a computer is on, etc., and/or for use amongst applications of an application suite or a plurality of (un)related applications. In the former, the SSO credentials are either made temporarily available in a memory of the physical or virtual computing devices, if relatively high security is desired, or a credential store and its contents are made available to a disk of the computing devices, if relatively low security is acceptable. In the latter, the SSO credentials are shared during authentication of a single user as individual applications of the application suite or the plurality of applications are used or started independently.
In a computing system embodiment, the invention may be practiced with secret stores; a client workstation; and a server arranged as part of pluralities of physical or virtual computing devices, including executable instructions for undertaking the foregoing methodology. Computer program products are also disclosed and are available as a download or on a computer readable medium. The computer program products are also available for installation on a network appliance, such as a server, on a client workstation, or as retrofit technology with a SSO service such as Novell's CASA architecture.
In still other embodiments, credential lifetime is contemplated as is the destruction of credentials, timing of application usage relative to credential life and/or prompting users to refresh credentials or re-authenticate.
These and other embodiments of the present invention will be set forth in the description which follows, and in part will become apparent to those of ordinary skill in the art by reference to the following description of the invention and referenced drawings or by practice of the invention. The claims, however, indicate the particularities of the invention.
The accompanying drawings incorporated in and forming a part of the specification, illustrate several aspects of the present invention, and together with the description serve to explain the principles of the invention. In the drawings:
In the following detailed description of the illustrated embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention and like numerals represent like details in the various figures. Also, it is to be understood that other embodiments may be utilized and that process, mechanical, electrical, arrangement, software and/or other changes may be made without departing from the scope of the present invention. In accordance with the present invention, methods and apparatus are hereinafter described for SSO in volatile sessions and shared environments, sharing being of the type related to hardware, software or both.
With reference to
In either, storage devices are contemplated and may be remote and/or local. While the line is not well defined, local storage generally has a relatively quick access time and is used to store frequently accessed data, while remote storage has a much longer access time and is used to store data that is accessed less frequently. The capacity of remote storage is also typically an order of magnitude larger than the capacity of local storage. Regardless, storage is representatively provided for aspects of the invention contemplative of computer executable instructions, e.g., software, as part of computer program products on readable media, e.g., disk 14 for insertion in a drive of computer 17. Computer executable instructions may also be available for installation as a download or reside in hardware, firmware or combinations in any or all of the depicted devices 15 or 15′.
When described in the context of computer program products, it is denoted that items thereof, such as modules, routines, programs, objects, components, data structures, etc., perform particular tasks or implement particular abstract data types within various structures of the computing system which cause a certain function or group of functions. In form, the computer product can be a download of executable instructions resident with a downstream computing device or readable media received from an upstream computing device or readable media, a download of executable instructions resident on an upstream computing device or readable media awaiting transfer to a downstream computing device or readable media, or any available media, such as RRAM, ROM, EEPROM, CD-ROM, DVD, or other optical disk storage devices, magnetic disk storage devices, floppy disks, or any other physical medium which can be used to store the items thereof and which can be assessed in the environment.
In network, the computing devices communicate with one another via wired, wireless or combined connections 12 that are either direct 12a or indirect 12b. If direct, they typify connections within physical or network proximity (e.g., intranet). If indirect, they typify connections such as those found with the internet, satellites, radio transmissions, or the like, and are given nebulously as element 13. In this regard, other contemplated items include sellers, routers, peer devices, modems, T# lines, satellites, microwave relays or the like. The connections may also be local area networks (LAN), metro area networks (MAN), and/or wide area networks (WAN) that are presented by way of example and not limitation. The topology is also any of a variety, such as ring, star, bridged, cascaded, meshed, or other known or hereinafter invented arrangement.
With the foregoing representative computing environment as backdrop,
In another embodiment of sharing credentials, a situation exists where there is an application suite that has multiple software components that can be used or started independently of one another (e.g., the Microsoft Office suite includes independently started/used applications like Microsoft Excel, Word, Power Point, etc.). However, these components are presently incapable of acquiring knowledge that the user might have already started one component in lieu of another, or the ability to pass the authentication credentials securely to the other component upon feature invocation. Thus, the present design overcomes these obstacles.
With reference to
At step 152, it is then determined what is an acceptable level of security for the user per their forthcoming SSO session. Relatively, this can consist of high, low, or medium, as prompted of the user also during login. Naturally, other security levels are known and can be substituted here. Upon answering, one scheme contemplates relatively low security, while another contemplates security higher than the low security, or a relatively high security level.
To the extent the user, policy or application deems relatively low security is acceptable, an entirety or substantial entirety of a credential store 170 for individual users A, B, or C can be downloaded or transferred from elsewhere upon authentication of the user to the network 180 and the workstation 160 to make SSO available during the session on the shared machine. In this scheme, the credentials are persistent and are stored on another server or workstation of the network 180, but are made available to the relatively permanent storage, e.g., disk 175, hard disk drive, etc., of the shared machine 160. The executable code 120′ of the SSO software would be required to be available on the shared machine and should clean up, e.g., destroy, the confidential data of the credential store upon the termination of an individual user's SSO session. Similarly, other users would have their credential store and contents made available to the shared machine that are cleaned-up upon the termination of their SSO sessions. Due to relatively lower security in this scheme, however, it is appreciated that catastrophic failures might leave otherwise sensitive residue data on the shared machine that can possibly be exploited by others having access to the shared machine.
In another scheme,
With reference to
In one version, a relatively high security level, volatile shared environment contemplates the simple downloading of secrets from a back-end credential store, in a secure manner, and loading them locally in a secure memory 177 for the duration of a user's (A, B or C) SSO session.
In another, a credential that is shared by applications 210, and session-based, is added when a first application 210-1 in a grouping of applications 210 is started and the user is prompted for credentials, e.g., those from User A's Credential store 170′-A. This set of credentials is then removed from memory 177 when User A turns off the workstation 15, 15′, signs off from the session, or the last application 210-n in the group of applications 210 is terminated. To clarify, the first invoked application in the group of applications, e.g., 210-1, collects the user's credential and authenticates the user. Upon successful authentication, it stores the credentials in a volatile store, e.g., memory 177 as a shared credential for possible use by other applications in the suite or group, e.g., 210-2 . . . 210-n. In turn, these types of shared credentials can either be aged for expiration for timely removal from memory or removed upon termination of the last-running application in the group. In the event the SSO session continues, in the age expiration case, the user will be prompted to refresh the credential, or in the last-running application case, upon invocation of a new application in the grouping the user will be prompted to authenticate and the shared credential will be stored for subsequent use.
As a working example, Novell's GroupWise, GroupWise Address Book, and GroupWise Messenger program products all require user credentials in order to authenticate a user to their respective services. Typically, all three require the same credential values to authenticate, but could, in some instances, be different. Hence, a SSO framework could be configured to allow the applications in the Novell suite to share the same credentials. Doing so means that the credential must exist for a period of time. For SSO to work effectively, that period of time must be at least as long for each application to authenticate. Once the first application collects a credential from the user, that credential must be available for the second application sharing this credential and so on.
In other words, the two versions or embodiments include the following. The first situation is one where a plurality of applications share a single preferred credential in a volatile memory based credential store. The second situation is one where a suite of applications share the same set of credentials in a volatile memory based credential. A SSO session's life span or an application's life span, during the SSO session, is then used to determine the life cycle of the credential in the credential store for use by the other applications in the suite or an aging scheme will be used to expire/destroy the credential in the store. In either, after the credentials are collected and stored in the SSO framework, they remain available until the last application in the suite terminates or age expiration is applied.
To the extent the lifetime of the user's SSO session on the computing device outlasts the credential's lifetime, the user will be prompted to refresh their credentials, steps 190, 192,
Various specific SSO frameworks for use with the invention include, but are not limited to, SecretStore, Firefox Password Manager, Gnome Keyring, KDE Wallet, CASA and miCASA. In more detail of one embodiment, Novell's CASA is a common authentication and security package that provides a set of libraries for application and service developers to enable single sign-on for an enterprise network. Version 1.7, for example, provides a local, session-based credential store (called miCASA) that is populated with desktop and network login credentials. A CASA manager serves as a user interface module, whereby users interface with their credentials in the various stores.
Within Novell's CASA Manager, it is contemplated that some or all of the foregoing will be configured using an SSO management utility. As anticipated, the CASA Manager, in an administrative mode, will allow a user with administrative privileges to set up the policy of SSO software (CASA) to only run in memory of a computing device without needing to save secrets on the hard disk of the computing device. In addition, it is possible to set expiration times for secrets. Depending on configuration for back-end availability, or the lack of it, the SSO software 120 can be configured to retrieve secrets from a back-end secret store or to operate without a back-end secret store when in a software suite mode of operation where a group of software components are enabled or configured to use a same secret. It is expected that this configuration will use encryption and save using a key-encryption based on a password provided by the system administrator to save these options for the default behavior of the SSO Software. Stated differently, once the administrator is authenticated to the workstation and the SSO software framework is operationally, the SSO management utility allows the administrator to enter credentials for storage, delete them, and edit them. The utility then allows the configuration of which credential is to be shared amongst applications, and/or the administrator to configure a group, or a suite, of applications using a shared credential. All of these options allow the administrator to configure the SSO software to a level of granularity that is defined by the security policies of the computing environment.
In an alternate embodiment, another scheme of usage is that of a user utilizing a computing device in the form of a disk-less workstation whereby the security policies do not allow for the user to have sensitive data such as credentials to be stored on disk. In this scenario, the SSO software will likely only run in a mode whereby the secrets are stored in a volatile memory-based credential store that, depending on the user having a back-end secret store or not, can operate automatically in one of the modes above without any need for a previous configuration.
During the use of the credential, the SSO framework determines the use of credential by its access, either being created or retrieved. The access of a credential is mapped to the Process ID of a process accessing the credential. From this ID, the framework determines the full path of the executable file name. If the application under consideration is configured as a member of an application suite, the PID is recorded as active for this credential. The SSO framework then monitors the running processes in the system. Either through the application stop event, or by a background thread, the SSO framework determines if a given credential should be destroyed by removal from memory. If all of the “active” PIDs terminate, the SSO framework removes the given credential.
Finally, one of ordinary skill in the art will recognize that additional embodiments are also possible without departing from the teachings of the present invention. This detailed description and particularly the specific details of the exemplary embodiments disclosed herein, is given primarily for clarity of understanding, and no unnecessary limitations are to be implied, for modifications will become obvious to those skilled in the art upon reading this disclosure and may be made without departing from the spirit or scope of the invention. Relatively apparent modifications, of course, include combining the various features of one or more figures with the features of one or more of other figures.
