WO2001011845A2

WO2001011845A2 - Security architecture with environment sensitive credentials

Info

Publication number: WO2001011845A2
Application number: PCT/US2000/020929
Authority: WO
Inventors: David L. Wood; Thomas Pratt; Michael B. Dilger; Derk Norton; Yunas Nadiadi
Original assignee: Sun Microsystems, Inc.
Priority date: 1999-08-05
Filing date: 2000-07-31
Publication date: 2001-02-15
Also published as: US6691232B1; EP1205057A2; WO2001011845A3; AU6752700A

Abstract

By including environment information in a security policy, a security architecture advantageously allows temporal, locational, connection type and/or client capabilities-related information to affect the sufficiency of a given credential type (and associated authentication scheme) for access to a particular information resource (e.g., 191, 192 or 193). In some configurations, time of access, originating location (physical or network) and/or connection type form a risk profile that can be factored into credential type sufficiency. In some configurations, changing environmental parameters may cause a previously sufficient credential to become insufficient. Alternatively, an authenticated credential (e.g., 420) previously insufficient for access at a given trust level may be sufficient based on a changed or more fully parameterized session environment. In some configurations, the use of session tracking facilities (e.g., the information content of session tokens) can be tailored to environmental parameters (e.g., connection type or location). Similarly, capabilities of a particular client entity (e.g., browser support for 128-bit cipher or availability of a fingerprint scanner or card reader) may affect the availability or sufficiency of particular authentication schemes to achieve a desired trust level.

Description

SECURITY ARCHITECTURE WITH ENVIRONMENT SENSITIVE CREDENTIAL SUFFICIENCY EVALUATION

Technical Field

The invention relates to mformation secuπty, and more particularly, to systems and method for improving the security of mformation transactions over networks

Background Art

The internet has become an important medium for mformation services and electronic commerce As the internet has been commercialized, organizations initially established their presence m cyberspace by makmg information (typically static, non-sensitive promotional mformation) available on resources well removed from the operational infrastructure of the organization Secuπty issues were often addressed by isolating publicly accessible resources (e g , web servers) from more sensitive assets usmg firewall techniques As long as the publicly accessible mformation and resources were relatively non-sensitive and user interactions with such mformation and resources was not mission critical, relatively simple firewall techniques were adequate Though mformation and resources outside the firewall were at πsk, the πsk could generally be limited to non-proprietary mformation that was easily replaceable if compromised Propπetary mformation and systems critical to day-to-day operations were sheltered behind the firewall and mformation flows across the firewall were filtered to exclude all but the comparatively non-threatening services such as electronic mail

However, as the internet has become more pervasive, and as the sophistication of tools and techniques has mcreased, several aspects of the secuπty environment have changed dramatically First, busmesses have recognized the power of mformation transactions that more tightly couple to operational data systems, such as order processing, inventory, payment systems, etc Such transactions mclude electronic commerce with direct purchasers or consumers (e g , browsing, selectmg and purchasmg of books by members of the public from an on-lme bookseller) as well as supply cham and/or busmess partner interactions (e g , automated just- in-time inventory management, customer-specific pπcmg, availability and order status mformation, etc ) Commercially relevant transactions mcreasmgly require mformation flows to and from secure operational systems Second, even information-only services are mcreasmgly rmssion-cπtical to their providers Corporate image can be adversely affected by unavailability of, or degradation access to, otherwise non- sensitive mformation such as customer support mformation, product upgrades, or marketing and product mformation Because many busmesses rely heavily on such facilities, both unauthorized modification and denial of service represent an increasing threat

Individual mformation service or transaction system typically exhibit differing secuπty requirements While it is possible to field individualized secuπty solutions for each information service or transaction system, individualized solutions make it difficult to mamtam a uniform security policy across a set of applications or resources Furthermore, individualized solutions tend to foster incompatible secuπty islands within what would ideally be presented to consumers or busmess partners as a smgle, mtegrated enterpπse For example, a user that has already been authenticated for access to an order processmg system may unnecessaπly be re-authenticated when accessmg an order status system Worse still, a set of individualized solutions is typically only as good as the weakest solution A weak solution may allow an enterprise to be compromised through a low secuπty entry point

Another problem with individualized solutions is a veritable explosion m the number of access controls confronting a user As more and more busmess is conducted usmg computer systems, users are confronted with multiple identifiers and passwords for vaπous systems, resources or levels of access

Administrators are faced with the huge problem of issumg, tracking and revokmg the identifiers associated with their users As the "user" community grows to mclude vendors, customers, potential customers, consultants and others m addition to employees, a huge "id explosion" faces administrators Furthermore, as individual users are themselves confronted with large numbers of identifiers and passwords, adherence to organizational security policies such as password restrictions and requirements (e g , length, character and or case complexity, robustness to dictionary or easily-ascertainable mformation attack, frequency of update, etc ) may be reduced As users acquire more passwords — some individuals may have 50 or more — they cannot help but wπte down or create easy-to-remember, and easy-to-compromise, passwords

DISCLOSURE OF INVENTION Accordmgly, a security architecture has been developed m which a smgle sign-on is provided for multiple mformation resources Rather than specifying a smgle authentication scheme for all information resources, secuπty architectures m accordance with some embodiments of the present mvention associate trust-level requirements with information resources Authentication schemes (e g , those based on passwords, certificates, biometπc techniques, smart cards, etc ) are associated with trust levels and environmental parameters In one configuration, a log-on service obtams credentials for an entity commensurate with the trust-level requιrement(s) of an mformation resource (or mformation resources) to be accessed and with environment parameters that affect the sufficiency of a given credential type Once credentials have been obtained for an entity and have been authenticated to a given trust level, access is granted, without the need for further credentials and authentication, to mformation resources for which the trust level is sufficient given a current session environment In some configurations, credential msufficiency may be remedied by a session continuity preserving credential upgrade

By mcludmg environment information m a secuπty policy, facilities in accordance with some embodiments of the present mvention advantageously allow temporal, locational, connection type and/or client capabilities-related mformation to affect the sufficiency of a given credential type (and associated authentication scheme) for access to a particular mformation resource In some configurations, time of access, oπgmating location (physical or network) and or connection type form a risk profile that can be factored mto credential type sufficiency In some configurations, changmg environmental parameters may cause a previously sufficient credential to become insufficient Alternatively, an authenticated credential previously insufficient for access at a given trust level may be sufficient based on a changed or more fully parameterized session environment In some configurations, the use of session tracking facihtes (e g , the information content of session tokens) can be tailored to environmental parameters (e g , connection type or location) Similarly, capabilities of a particular client entity (e g , browser support for 128-bit cipher or availabhty of a fingerpπnt scanner or card reader) may affect the availability or sufficiency of particular authentication schemes to achieve a desired trust level Of course, not all advantages need be provided m any given implementation

In one embodiment m accordance with the present mvention, a method of determining sufficiency of a credential type for access to an mformation resource mcludes establishing a correspondence between a session and an access request targeting the mformation resource, establishing a trust level requirement for access to the mformation resource, and evaluatmg correspondence of one or more credential types with the trust level requirement for access to the mformation resource and with environment mformation associated with the session

In another embodiment m accordance with the present mvention, a method of operating a secuπty architecture mcludes matchmg an access request of a client entity with a correspondmg session The access request targets a first of plural information resources and the session has an associated one or more session parameters affecting sufficiency of credential types The method further mcludes determining a set of one or more credential types sufficient for access to the first mformation resource The determining is based, at least m part, on the one or more session parameters If an authenticated credential associated with the session is of one of the sufficient credential types, then access to the first mformation resource is allowed Otherwise, a new credential is obtammg, the client is authenticated entity thereby, and access to the first information resource is allowed The obtamed credential is of one of the sufficient credential types

In still another embodiment m accordance with the present mvention, an mformation system mcludes plural mformation resources hosted on one or more servers coupled via a commumcation network to a client entity and an access control facility common to the plural information resources The plural information resources have individualized authentication requirements and the common access control facility obtains a credential for the client entity and authenticates the client entity thereby In response to a request for access to a first of the information resources, the common access control facility evaluates, based m part on current parameters of a correspondmg persistent session, sufficiency of associated authenticated credentials for access to the first mformation resource

In still yet another embodiment m accordance with the present mvention, an access control facility for providmg a smgle sign-on for sessions that potentially mclude accesses to plural mformation resources having differing secuπty requirements mcludes an application proxy and means responsive to the application proxy for evaluating sufficiency of credential types based on then current parameters of the session and on a trust level requirement of the targeted information resource The application proxy configured for receivmg an access request targeting one of the information resources, associating the access request with a session, and selectively proxymg the access request if at least one sufficient credential is associated with the session

BRIEF DESCRIPTION OF DRAWINGS The present mvention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled m the art by referencmg the accompanymg drawings FIG. 1 is a block diagram lllustratmg mformation flows between components m a secuπty architecture with environment sensitive credential sufficiency evaluation m accordance with an exemplary embodiment of the present mvention

FIG. 2 is a flow chart lllustratmg operation of a secuπty architecture with environment sensitive credential sufficiency evaluation m accordance with an exemplary embodiment of the present mvention

FIG. 3 illustrates mteractions between functional components m a functional decomposition of a secuπty architecture with environment sensitive credential sufficiency evaluation m accordance with an exemplary embodiment of the present mvention

FIG. 4 illustrates relations between logm credentials, session credentials and a cookie encodmg of a session token in accordance with an exemplary embodiment of the present mvention

The use of the same reference symbols m different drawmgs mdicates similar or identical items

MODE(S) FOR CARRYING OUT THE INVENTION

Some terminology used m this specification has meaning particular to the context of embodiments descπbed herem Therefore, to aid persons of ordinary skill m the art m understanding the full scope of the mvention, some of that terminology is now defined

Glossary

Access Management Systems, methods and techniques for controlling use of mformation resources Typically, access management systems employ both authentication and authorization to control access to information resources

Authentication A process used to venfy the identity of an entity As typically implemented, an authentication method is employed to venfy the identity of a user or object based on a credential supplied by the user or object

Authorization A process for determining whether an identity is permitted to perform some action, such as accessmg a resource Typically, an identity will be authenticated, though in some configurations certain identities need not be

Credential Evidence of identity used to authenticate an entity Exemplary credentials types include passwords, certificates or other encrypted mdicia based on asymmetric, symmetric, public, pπvate, or secret key technologies, one-time passwords, biometnc mdicia such as by retinal scan, voice pπnt, finger print, etc , and possession based mdicia such as smart cards, Enigma cards, keys, etc In some realizations, credentials may be associated with users, sessions, functional objects, etc

Digital Signature A transformation of a message usmg an asymmetπc cryptosystem such that a person havmg the initial message and the signer's public key can accurately determine whether the transformation was created using the private key that corresponds to the signer's public key and whether the message has been altered since the transformation was made

Entity A user or object, mcludmg data objects and/or functional objects such as applications, components, modules, services, processes, threads, etc , as well as instantiations thereof In some configurations, only user entities (typically, the human principal mteracting with a software program or on whose behalf a software agent purports to act) are considered In other configurations, entities mclude functional objects without an associated human principal The identity of an entity may be authenticated using a credential

Session A period and collection of states spanning one or more mteractions between an entity and an mformation environment As used herein a session may span multiple interactions with multiple resources of the mformation environment and, in some configurations, may span multiple mformation access protocols (e g , HTTP, FTP, telnet, etc ) A session has a beginning and an end Durmg its existence, a session has state As used herein, the term session connotes a greater persistence than as sometimes used to describe the penod of a "session layer" protocol interaction, which m the case of some protocols, such as HTTP, is generally very short-lived

Single Sign-on Security Architecture

FIG. 1 provides an overview of major mteractions between components for an exemplary secuπty architecture in accordance with the present mvention As illustrated m FIG. 1, a client application, e g , a browser 170 operated by a user, mteracts with the security architecture via a gatekeeper and entry handler component 110 and a logm component 120 Gatekeeper and entry handler component 110 provides an entry pomt for external client applications requestmg access to enterprise applications and/or resources, mcludmg e g , mformation resources 191, 192 193, for which access management is provided by the secunty architecture Usmg facilities provided by a session management component 160, an authorization component 140, an authentication component 130, an identification component 150, and logm component 120, the gatekeeper/entry handler component 110 allows, redirects or refuses access requests m accordance with a secuπty policy

Individual information resources typically have differing security requirements In addition, individual types of access to a smgle mformation resource may have differing security requirements Nonetheless, a given level of security may be sufficient for more than one of the mformation services or access types For example, mformation resource 191 may mclude a product mformation service for providmg general mformation such as product descπptions or data sheets to the public, while mformation resource 192 mcludes an order processmg system for an eCommerce site Information resource 193 may mclude functions for supply chain interactions such as access to inventory mformation or current selling price mformation Both the product mformation service and order mtake functions of the eCommerce may operate with similar security requirements, e g , allowing access by minimally authenticated, non-hostile entities On the other hand, supply cham functions may require a higher level of security Order status functions of the order processing system may require a mid-level of security Logm component 120, operatmg in conjunction with gatekeeper/entry handler component 110 and other components of the security architecture, provides a single sign-on interface for access to enterpπse applications and/or resources In an exemplary embodiment, secuπty requirements are expressed in terms of trust levels and login component 120 obtains logm credentials for an entity requesting access to one of the enterprise applications and or resources The login credentials obtained are selected from a set of credential types that, if authenticated, are sufficient to achieve the trust level requirement of an application or information resource to be accessed Without limitation, typical login credential types and associated authentication mechanisms include those based on passwords, certificates, biometπc techniques, smart cards, etc Other credential types and associated authentication mechanisms are described elsewhere herem

In some embodiments in accordance with the present invention, gatekeeper/entry handler component

110 queries authorization component 140 to obtam authorization for access to a particular requested enterpπse application or mformation resource by the requestmg entity (e g , the browser user) If the entity requestmg access has not yet been authenticated to the trust level required for the particular access to the particular enterprise application or information resource requested, authorization component 140 may mdicate that the access request is to be redirected to logm component 120 so that logm credentials may be obtamed and authenticated to a particular trust level If, on the other hand, logm credentials have already been obtamed for the requesting entity and the requesting entity has been authenticated usmg the obtamed credentials such that the required trust level has been achieved, the access will typically be allowed without the need for further logm credentials and authentication In certain circumstances, authorization component 140 may mdicate that the access is to be refused For example, authorization component 140 may be programmed to perform more stringent testmg beyond a trust level requirement In an exemplary enterpnse tool configuration, a desired secunty policy may dictate that a salary tool is accessible only from with a company's internal network No level of authenticated trust may be sufficient to access such a tool from outside company network To facilitate implementation of such a security policy, authorization component 140 could refuse access based on environment parameters indicating a session oπgmatmg outside the company's internal network

Of note, m certain embodiments m accordance with the present mvention, the mappmg of logm credential types and authentication mechanisms to trust levels is influenced by environment information such as time of request, source of request, connection speed, and/or client application (e g , browser) environment mformation In this way, even with a static set of mappmg rules, the set of credential types and authentication mechanisms suitable to support a given trust level may vary based on environment mformation In general, mappmg rule dependencies are based on perceived variations in threat characteristics and/or requesting entity capabilities In some embodiments m accordance with the present mvention, gatekeeper/entry handler component 110 is the authority on environment mformation for a particular requesting entity

In some embodiments, mappmg rules may be dynamically varied For example, if a particular logm credential type and or authentication method is deemed msecure (e g , because compromised or because of a changmg threat profile), the trust level mappings can be updated and have enterprise- wide effect In addition, several other advantages are achieved by defining the authentication requirement mterface between enterpπse applications and or resources and the security architecture m terms of required trust levels, rather than m terms of particular credential types and authentication methods First, smgle sign-on configurations are facilitated using an enterprise-wide credential obtaining, authentication and session tracking infrastructure Second, authentication requirements may be enforced uniformly in accordance with an enterprise-wide security policy and with reduced vulnerability to a lax security implementation by any particular mformation resource Third, credential types and authentication methods can be added, deleted, or mapped to a new trust level, all without modification of enterprise applications and resources Of course, all advantages need not be achieved m any particular implementation

In certain embodiments in accordance with the present invention, a credential upgrade facility is provided In response to an access request from an entity for which login credentials have already been obtamed and authenticated, but for which the obtained and authenticated login credentials are insufficient for the trust level associated with the requested access, authorization component 140 may indicate that the access request is to be redirected to logm component 120 so that sufficient logm credentials may be obtamed and authenticated to the required trust level Of note, credential upgrade facilities m accordance with certain embodiments of the present mvention allow upgrade without loss of session continuity

Exemplary Configuration

Referring to FIG. 1, an entity (e g , a browser 170 operated by a user) interacts with enterpπse applications and/or resources (e g , 191, 192, 193) and the security architecture via a gatekeeper/entry handler component 110 and a login component 120 In general, a wide vaπety of entities, including human users operatmg browser and/or non-browser client applications as well as automated agents and systems, may mteract with enterpnse applications and/or resources and the secuπty architecture as described herein

Furthermore, a variety of mformation resource identification schemes, such as by Uniform Resource Locator (URL), resource address, identifier or namespace designation, may be employed However, for purposes of illustration and not limitation, an exemplary interaction involving a browser and mformation resources identified by URL is described in detail Nonetheless, based on the descπption herem, persons of ordinary skill m the art will appreciate a wide variety of configurations m accordance with the present mvention m which non-browser clients, automated agents or other systems mteract with enterprise applications and/or resources and the secunty architecture usmg any of a variety of mformation resource identification schemes

Focusmg then on an exemplary browser-type client entity, browser 170 requests access to one or more of enterprise applications and or resources (e g , information resource 191) by presentmg an URL to gatekeeper/entry handler component 110, which acts as a pomt of entry for client entities requestmg access to applications and/or resources controlled by the security architecture Gatekeeper/entry handler component 110 receives the request as a proxy for the requested resource In some configurations, a combmed gatekeeper/entry handler mstance is provided, while in others, separate and/or multiple instances are provided with functionally identical mterfaces to other components of the security architecture In some configurations, multiple instances of entry handler functionality (e g , interception of mbound requests and collection of environment information) are provided For example, one or more mstances for each of several connection types (e g , dialup, WAN, etc ) may be employed One or more instances of gatekeeper functionality (e g , allowing access for authorized requests and otherwise denymg or initiating appropriate responsive action) may also be provided Configurations and functional decompositions suitable to a particular environment and expected load requirements will be appreciated by persons of ordinary skill m the art

Entry handler functionality (e.g , m gatekeeper/entry handler component 110) ascertains much of the requestmg client's environment mformation For example, for dial-up connections, environment mformation such as lme speed and low-level lme encryption are ascertained. Additional mformation, such as source number (e.g., from caller id mformation or based on a callback configuration), signaling type (e.g , POTS or digital ISDN), etc , may also be obtamed For network connections, similar environment mformation (e.g., source network and/or node, Virtual Pπvate Network (VPN) low-level encryption, etc.) may be obtamed from mcommg requests themselves or based on a particular entry pomt (e g , a particular router or port) More generally, gatekeeper/entry handler component 110 obtams and/or mamtams mformation such as connect location (if ascertainable), temporal mformation such as request time/date, session start time/date, etc (preferably m both the client entity's frame of reference and the secunty architecture or requested mformation resource's frame of reference, if location is ascertainable), and client type and/or capabilities (e.g , browser type and Java Development Kit (JDK) level) In some configurations, mformation on lme speed, oπgmation pomt (e.g., mside or outside of a corporate network), browser type, encryption capability, number of hops, latency, system type, etc. may be gathered. Such mformation is used m some configurations for mappmg particular authentication mechanisms to trust levels and for authorization decisions. Environment mformation is generally packaged mto a data structure that is associated with a client session. Other components of the secunty architecture may add additional client environment information, such as authentication strength or current trust level

Gatekeeper functionality (e.g., m gatekeeper/entry handler component 110) checks whether a session is already associated with the mcommg request. Although other techniques are possible, m some configurations m accordance with the present mvention, gatekeeper/entry handler component 110 checks for the presence of a session token m the mcommg request. Use of session tokens is descnbed in greater detail below; however, m short, a session token may be any data supplied to the client entity for use m uniquely identifying an associated session In general, preferred session token implementations are cryptographically secured and mclude facilities, such as expiration or mappmg to a particular connection, to limit risk of replay attack and/or spoofing Some session token implementations may encode session, principal, and/or trust level mformation. Some session token implementations may employ cookies, URL encodmg, or other similar techniques for bmdmg to mcommg requests

In some configurations, session tokens are employed to facilitate session continuity and to allow the secunty architecture to associate pnor authentication of logm credentials with an mcommg access request. In one utilization, session tokens are issued to client entities as part of an interaction with the secunty architecture and are thereafter presented with access requests. In some configurations, new session tokens (each correspondmg to a smgle session) are issued to client entity on each credential level change. In other configurations, a session token may remain the same even as credential levels are changed. Session continuity means the mamtenance of coherent session state across one or more mteractions between an entity and an mformation environment

Components of session state (e g., m some configurations, principal id, session id, authenticated trust level, group ids and/or roles, creation time, expiration time, etc.) are mamtamed or advanced throughout the duration of a session Typically, aspects of session state are represented internally by the secunty architecture and a session token (e g , a session id encoded m a cryptographically secured session token) allows the secunty architecture to reference mto the internal representation. However, m some configurations, at least some aspects of session state may be represented or duplicated m the session token. For example, a principal id and current trust level are encoded m one realization of a cryptographically secured session credential and associated session token or cookie In general, a vaπety of facilities, such as cookies, can be used to mamtam state across a seπes of protocol mteractions, such as HTTP transactions, that do not otherwise support persistent session state

Referring agam to FIG. 1, if a session token is present in the mcommg request, gatekeeper/entry handler component 110 resolves the token to a session object Alternatively, if no session token is present or if a session token is invalid, gatekeeper/entry handler component 110 establishes a new session (2) In an exemplary configuration m accordance with FIG. 1, session management component 160 allocates a new session and supplies associated default session credentials (2) based on the requested information resource and environment mformation Note that a session is created irrespective of authentication status or identity, although some implementations may refuse to even allocate a session based on particular information resource requests and or environment information. Given a session object, which may be resolved from a received session token or newly allocated, gatekeeper/entry handler component 110 mteracts (3, 4) with authorization component 140 to determine whether the requested access is authorized. For some requested accesses and secunty policies (e.g., anonymous ftp access to certain archives), even a session without authenticated logm credentials (trust level=0) may be authorized. For others, a more substantial trust level may be required.

Gatekeeper/entry handler component 110 supplies authorization component 140 with an identifier for the requested resource (e.g., the requested URL) and an identifier for the associated session. Preferably, the associated session identifier is cryptographically secured (e.g., as a signed session credential) In some configurations, the signed session credential is obtained from the correspondmg session object. In the case of a pre-existing session, the signed session credential may be obtamed usmg a received session token In any case, authorization component 140 receives (3) the requested resource and session identifiers and responds (4) m accordance with the trust level requirement of the requested resource In configurations for which sensitivity to a changmg environment is desired, environment mformation may also be supplied to authorization component 140. In an exemplary configuration, authorization component 140 responds with an ALLOW, REDIRECT, or REFUSE response based on the sufficiency of a current trust level. In some configurations, authorization component 140 dynamically calculates a cunent trust level based on the signed session credentials and environment mformation. In others, authorization component 140 may base its ALLOW, REDIRECT, or REFUSE response on a "current" trust level previously associated with the signed session credentials Generally, an access request with sufficient current trust level is ALLOWED and forwarded (14) without further authentication. An authorization request without proper parameters (e.g., without a specified information resource or without a properly secured session credential) may be REFUSED. Authorization requests associated with a client entity that has been blacklisted or for a resource for which the associated client entity cannot be authenticated usmg any available method to achieve the required trust level may also be REFUSED For example, a given security policy and associated trust level mappmgs may dictate a REFUSE response m response to an access request to a sensitive resource (such as financial data) by any client entity (even a browser supplymg the digital certificate for the CFO, and therefore presumably operating on behalf of the CEO) if the access request is received over a dial-up lme and oπgmates from an unknown number or is received outside of workmg hours.

In general, there is an imp licit, base level of environment inherent m an authenticated trust level; however, m some configurations, a particular authorization transaction may dig deeper mto environment information before respondmg For example, m configurations providmg log-up capabilities, an authorization service will typically redirect to a logm service if the trust level associated with current session credentials is insufficient for a requested access However, for sensitive applications in such a configuration, an madequate trust level may result in a REFUSED message rather than a log-up REDIRECT dependmg on the particular secuπty policy implemented.

A REDIRECT response is used to forward the access request to logm component 120 so that sufficient logm credentials may be obtamed and authenticated to achieve the required trust level for the requested access Note that m some configurations, both initial logm credentialing and credential upgrade are provided usmg the REDIRECT facility In response to a REDIRECT response (4), gatekeeper/entry handler component 110 redirects (5) browser 170 to logm component 120. In one configuration, gatekeeper/entry handler component 110 issues a client-side redirect via HTTP location directive to forward the request to logm component 120. Parameters such as required trust level, requested URL and credential passmg method can be encoded m the redirect URL and supplied (6) by browser 170 to logm component 120. Alternatively, some parameters can be passed (5A) directly (e.g , through a HttpSession object) although a stateless configuration is preferred

A session token is passed to browser 170 m conjunction with the redirect (5) to logm component 120. Based on the descπption herem, persons of ordinary skill m the art will appreciate a number of suitable mechanisms for passmg the session token, mcludmg those based on cookies and URL encodmg. Preferably, mechanisms employed are based on facilities provided by commercially available browsers (e.g., m accordance with HTML 3.x, 4.x or other de-facto standards), although customized or plug-m facilities for receivmg and supplymg session token may be employed In one suitable configuration, the session token is cryptographically secured and encoded m a cookie placed at browser 170 usmg a set cookie directive embedded m the redirect. Other configurations may use a less persistent session identification method, such as passmg an identifier or session token in the redirect URL without storage at browser 170. Still other configurations may transmit a session token, a session credential, or identifier such as a session handle for storage m a medium such as a smart card In configurations providmg credential upgrade, persistent session identification methods are generally preferred, even for a not yet authenticated client entity, for consistency of approach Note that although the identity of the client entity may not be authenticated to a sufficient level of trust, the redirected request mcludes a session token that at least identifies the session Other configurations may omit the bmdmg of session tokens to sessions of not yet authenticated client entities, though with some mcrease m complexity of logm component 120

Browser 170 sends (6) logm component 120 a new access request usmg the URL specified m the redirect from gatekeeper/entry handler component 110 In configurations employmg cookies as a medium for passmg session tokens, the new access request will mclude the cookie and therefore the session token Note that m configurations m which the secuπty architecture controls access to resources m several domams, care should be exercised to select a tag or tags for the cookie such that it will be provided through normal operation of the browser m subsequent accesses to any of the several domams Persons of ordmary skill m the art will appreciate suitable taggmg techniques, mcludmg the use of multiple cookies Logm component 120 receives the access request and determines an appropπate authentication scheme based on mappmg rules that identify those authentication schemes which are sufficient to achieve a given trust level Preferably, the mappmg rules are a function of environment mformation In some configurations, mappmg rules are implemented as fuzzy sets wherem acceptable authentication schemes are a function of required trust level and environment mformation In this way, environment affects the set of authentication schemes sufficient to meet a trust level requirement

Generally, mappmg rule logic is evaluated before a user is challenged to authenticate Mappmg occurs as a function of session environment and particulars of the information resource for which access is requested By evaluatmg the minimum trust level required by the target of an access request, a service (e g , a logm service such as provided by logm component 120) derives a list of potential authentication methods The service then checks current session environment agamst the allowed environment states for each potential authentication method to trim the list further If there is no particular resource for which access is bemg requested (e g , if a user jumps straight to a sign-on page without requesting an access), the service will proceed accordmg to the lowest level of trust available consistent with session environment Other configurations may employ differing default behaviors

In some configurations, logm component 120 queries (7) authorization component 140 to identify the set of authentication schemes that meet or exceed the required trust level given a cunent environment In other configurations, the mappmg is performed by logm component 120 In either case, logm component 120 supplies (9) mformation to browser 170 to allow the user to select from the suitable authentication schemes and to provide an associated logm credential In some configurations, logm component 120 supplies browser 170 with a logm page (e g , HTML) that prompts the user for an application specific user ID and a choice of authentication schemes Interactions with browser 170 depend on the set of credential types that, if authenticated, would be sufficient to meet the trust level requirement for access to the requested resource For example, if more than one type of credential would be sufficient, logm component 120 may mteractively allow a user to select from amongst the credential types (e g , usmg any HTML-based dialog) Once a particular credential type has been selected, logm component 120 mteracts with browser 170 to obtam an mstance of the logm credential to establish the identity of the browser user Some credential types (e.g , username/password pairs, onetime passwords, enigma challenge, etc) may be obtamed through an mteractive process m which the user supplies the logm credential(s) entry mto an HTML form browser 170 POSTs form contents back to logm component 120 Others (e.g , digital certificates) may be supplied (10) for the client entity from browser 170, or m some configurations, may be obtamed from or via an agent or certificate aufhonty A personal digital certificate (such as those issued by Verisign™,

Thwate, Entrust or other certificate authority) may be obtamed from a browser 170 usmg an HTTP certificate request. Although credentials may be transacted m a variety of ways, credentials are typically obtamed from a user Typically, the obtammg is indirect by askmg the user's browser to complete the negotiation process. In such configurations, certificate-based authentication may be transparent to the user. In some configurations, further authentication can be performed by usmg mformation encoded within the certificate to query a certificate authority for current status or a lookup to an authentication database may be performed for more detailed requirements In an exemplary configuration, the more detailed mformation could relate to session environment or could force an additional name/password authentication as part of the certificate authentication cham In a particular implementation such facilities can be provided by mappmg rule encodmgs that require successful authentication usmg multiple authentication methods to achieve a given trust level

Once logm credentials have been obtamed by logm component 120, they are supplied (11) to gatekeeper/entry handler component 110 for authentication. In configurations m which both gatekeeper/entry handler component 110 and logm component 120 have access to a shared object such as the HttpSession object, logm credential passmg via the shared object is suitable. In other configurations, an HTTP POST may be employed. In an exemplary configuration, the particular credential passmg method is selected as part of the ongmal HTTP redirect (e.g., encoded m the redirect URL) although other configurations need not allow for a selection or may employ other facilities for selection of a credential passmg method.

Logm component 120 also passes control of the access request back to gatekeeper/entry handler component 110 In an exemplary configuration, logm component 120 issues a new HTTP request (11) specifymg the originally requested URL, which has been stored m the HttpSession object. As before, gatekeeper/entry handler component 110 receives the request. Gatekeeper/entry handler component 110 extracts the logm credentials from the request or from the HttpSession object and passes (12) the logm credentials to authentication component 130 for authentication. Authentication component 130 authenticates the logm credential, and if successful, quenes (13) identification component 150 to establish a conespondence with a set of entity descnptors that uniquely identifies the requesting entity. In an exemplary configuration, entity descnptor types mclude. entity id, system id (e.g., name/password), certificate, emgma id, smartcard token, name/address, and phone One or more of values may uniquely identify an entity and one or more entity descnptor types may support multiple values (e g., multiple digital certificates, name/password parrs, or phone numbers per identity). Once the requesting entity has been identified (14), session parameters are updated (15) and session management component 160 supplies (16) session credentials. Preferably, session credentials are digitally-signed or otherwise cryptographically secured and returned (17) to gatekeeper/entry handler component 110 Gatekeeper/entry handler component 110 agam supplies (18) authorization component 140 with an identifier for the requested resource (e g , the requested URL) and an identifier for the associated session (e g , the signed session credentials authorization component 140 responds with an ALLOW, REDIRECT, or REFUSE response based on the sufficiency the session ciedentials (and underlying authentication of logm credentials) for the trust level required for the requested access Logm credentials should now be sufficient for access to the requested resource and an ALLOW response is supplied (19) by authorization component 140 Gatekeeper/entry handler component 110 proxies the requested access (20, 21) to mformation resource 191 and streams (22) results back to logm component 120 Logm component 120, m turn, streams (23) results back to browser 170

In some embodiments m accordance with the present mvention, session continuity is facilitated by supplymg a session token to browser 170 For example m one configuration, logm component 120 supplies a session token usmg a set cookie directive encoded with the results streamed (23) back to browser 170 In response, browser 170 stores the cookie usmg a tag (typically a filename encodmg) Browser 170 supplies the cookie (and the session token) with subsequent access requests based on a correspondence between the tag and the requested resource Typically, the correspondence is based on the second-level domam (e g , sun com) m which the requested resource is hosted, although nth-level domams or other resource identification and session token associating schemes may be employed In configurations m which the secunty architecture controls access to multiple domams across which a spanning smgle sign-on is desired, multiple cookies may be employed

Although the encodmg of session tokens usmg cookies is presently prefened, m part because cookie facilities are widely supported and reasonably well accepted, other facilities may be employed to establish session continuity For example, alternative URL encodmgs and/or custom or plug-in support for session identifier receipt, storage and supply may be employed Also, some configurations may employ lower-level session identifiers, e g , as provided by a particular connection type such as trusted caller id information or as associated with a low-level lme encryption or virtual pπvate network mfrastructure As such facilities are likely to be connection-type specific, it is envisioned that they may be used m conjunction with other session identifier facilities descnbed above, e g , session tokens encoded m cookies In one configuration, the unique Ethernet MAC address associated with a network mterface card may be employed as a session handle The MAC address is then used to associate with a particular set of session credentials mamtamed by a central authonty In general the representation of a session handle can take may forms

Referring agam to FIG. 1, subsequent access requests (e g , access request 1A) mclude a previously assigned session token As descnbed above, gatekeeper/entry handler component 110 uses the session token, if provided to resolve a session object contaimng session credentials, and to determine whether previously authenticated credentials are sufficient for the requested access As descnbed above, authorization component 140 may be queπed usmg session credentials and an identifier for the requested resource to determine sufficiency of previously authenticated credentials In some configurations, sufficiency is determined usmg trust level mappmgs as described above Dependmg on the information resource to which access is requested, and m some configurations dependmg on current session environment information, access request 1A may or may not have associated previously authenticated ciedentials sufficient to support the requested access In the case of an access request 1A havmg a trust level requirement commensurate with previously obtamed and authenticated credentials (1 e , an access request for which no additional credentials need be obtamed via logm component 120), the access request is proxied (20) and results (21) are streamed directly (23 A) back to browser 170 In some configurations, gatekeeper/entry handler component 110 supplies an updated session token usmg a set cookie directive encoded with the results streamed (23A) back to browser 170 An updated session token, if supplied, resolves to the same session object as the session token replaced For example, m some configurations, both session tokens encode a same session handle, although other aspects associated with session token security such as expiration may be updated In other configurations, results (21) are streamed (23 A) back to browser 170 without an updated session token In such configurations, the previously supplied session token remams valid until expired o otherwise invalidated Some vanations may employ a session token refresh interval

Dependmg on the mformation resource to which access is requested, previously obtamed and authenticated logm credentials may be insufficient for the trust level requirement associated with requested access 1A As before, authorization component 140 supplies gatekeeper/entry handler component 110 with an ALLOW, REDIRECT or REFUSE response based on the trust level accorded based on the previously obtamed and authenticated logm credentials and on the trust level requirement associated with requested access 1A Advantageously, authorization of individual access requests is streamlined by the encodmg of trust level m a cryptographically secured session credential or token In the case of insufficient credentials, a REDIRECT response is supplied and gatekeeper/entry handler component 110 agam redirects (5) browser 170 to logm component 120 Additional logm credentials are obtamed as descnbed above with reference to initial credentials Upon successful authentication, access request is proxied (20) and results (21) are streamed (23A) back to browser 170

Preferably, gatekeeper/entry handler component 110 supplies an updated session token usmg a set cookie directive encoded with the results streamed (23 A) back to browser 170 An updated session token, if supplied, resolves to the same session object as the session token replaced As a result, session state (mcludmg e g , identity mappmgs, authorizations, roles, permissions, environmental vanables, etc ) is maintained through the credential level change However, m the case of a credential upgrade, the session object now encodes a logm credential successfully authenticated to achieve a higher trust level In one advantageous configuration, the achieved (higher) trust level is encoded m a cryptographically secured session token representation as a cookie streamed (23A) back to browser 170 with results (21)

FIG. 2 illustrates operation of an exemplary secuπty architecture providmg a smgle sign-on facility with trust level mappmg to authentication requirements As before, an access request is received (201) from a client entity If the request does not contam a session identifier (e g , a session key or token) or if the request can otherwise be reliably associated with a session maintained by the secuπty architecture, a new session is created (202) A trust level requirement is determined for access to the requested resource in the context of the requesting session environment In some configurations, as descnbed above, the determination is performed by an authorization service such as authorization component 140 Given a trust level requirement, cunent session credentials are evaluated (203) m the context of session environment information to determine whether the previously supplied logm credentials are sufficient to achieve the required trust level In one advantageous realization of session credentials and tokens, a cryptographically secured encodmg of trust level allows authorization to be confirmed without mvolvement of an authentication service (e g , with reauthentication of logm credentials) In the case of a newly created (202) session, the authorization evidenced by session credentials will typically be insufficient, although some security policies may allow anonymous access to certain resources

For a pre-existmg session, I e , for an access request that can be reliably associated with a persistent session by a cryptographically secured session token or otherwise, session credentials may or may not be sufficient for access to the currently requested resource For example, after a first access, the identity of an entity accessmg resources controlled by the secunty architecture will be authenticated to a trust level sufficient for that access Dependmg on the trust level requirements of a subsequent access and, m some configurations, dependmg on then cunent trust level mappmg rules and environment mformation, the level of trust associated with a cunent session (e g , as evidenced by cunent session credentials) may or may not be sufficient for the subsequent access In situations for which a cunent level of trust (e g , resulting from pπor authentication of logm credentials for an entity associated with the session) is sufficient for later access to the same or to another information resource, access is allowed without additional authentication For example, in some secuπty architectures m accordance with the present mvention, the secuπty architecture proxies (204) the request to the requested mformation resource and streams (205) a resultmg response back to the requesting client entity

As descnbed elsewhere herem, sufficiency of cunent session credentials is determined usmg mappmg rules that, m some realizations, mclude environment information In general, cunent session credentials may be insufficient (1) because the identity of the requesting client has not yet been authenticated (e g , m a first access situation), (2) because of a higher trust level requirement for the requested access, or (3) because of a change m mappmg rules or environment that causes a previously sufficient credential no longer be sufficient for a particular trust level Whatever the reason for the msufficiency, a request conespondmg to a session and client entity that is insufficiently authenticated, and that is therefore not authorized, is passed to a facility for obtammg credentials of a type that, if authenticated, will support the required trust level

Typically, session credentials and/or an associated session token encode an expiration time (see descπption, below, of FIG. 4) In such configurations, a previously sufficient session credential is insufficient after its expiration In some configurations, session credentials are penodically refreshed by reauthentication of the underlying logm credentials For example, m one implementation, a presented session token indicating expiration m less than five (5) minutes causes the secunty architecture to reauthenticate (not shown) underlying logm credentials stored m a conespondmg SessionObject (e g , under the pnvate key of authentication component 130) Reauthentication typically results m a new session credential and associated trust level Dependmg on then mstant mappmg rules, the associated trust level may or may not be sufficient Also, reauthentication may fail if the logm credentials have been invalidated, revoked or if the login credentials have expired Assuming that reauthentication of logm credentials is successful, updated session credentials are issued, for example, by authentication component 130 and supplied (e g , as a cookie encoded session token) to the client entity e g , browser 170)

Refenmg agam to FIG. 2, a request conespondmg to a session not authorized for a requested access is redirected (206) to a credential gathermg service (e g , logm component 120) The credential gathermg service receives (207) the redirected access and obtains (208) a trust level requirement for the requested access In some configurations, the trust level requirement may be passed with the redirected access or otherwise associated with the redirected access, m others the trust level requirement may be re-obtamed from an authorization service such as authorization component 140 A trust level requirement is mapped (209) to at least one authentication scheme sufficient to achieve the requirement based on cunent trust level mappmgs and, if employed m the mappmg rules, based on cunent environment mformation Assuming that at least one authentication scheme is available that, if successful, will support the required trust level, logm credentials of that type are obtamed (210) for the entity and authenticated (211) Some credential types (e g , username/password pairs, onetime passwords, enigma challenge, etc) may be obtamed through an interactive process in which a pπncipal (e g , a human user) supplies the credentιal(s) entry m an HTML form and POSTs form contents back to the credential gathermg service Others (e g , certificates) may be obtamed for the client entity from an agent or authonty For example, a personal digital certificate (such as those issued by Veπsign™, Thwate, Entrust or other certificate authonty) may be obtamed from a browser usmg an HTTP certificate request In some configurations, a choice of credential types may be provided and user may select from a set of credential types sufficient for the requested access Once appropnate logm credentials have been obtamed and authenticated, the session conespondmg to the requested access is updated (213) to reflect the new authenticated session credentials The now sufficiently authorized request is proxied (204) and results are streamed back (205) to the requesting client entity Updated or refreshed session credentials are typically supplied as a session token (e g , a cookie) encoded with the streamed results

FIG. 3 illustrates mteractions between functional components m an exemplary functional decomposition of a security architecture An on-lme order processmg transaction is exemplary and functional boundaπes are merely illustrative Based on the description herem, a wide variety of suitable enterpnse information environments and functional decompositions m accordance with the appended claims will be appreciated by persons of ordmary skill m the art

In the configuration of FIG. 3, application and central security portions (321 and 322, respectively) of the secunty architecture are illustrated Of note, functional components of application secunty portion 321 are typically hosed as services on a first server environment, while functional components of central secuπty portion 322 are hosted as services on a second server environment In this way, most mteractions amongst functional components occur within a smgle server environment and do not require network transactions In the configuration of FIG.3, credentials associated with a calling component (e g , framework credentials associated with application secuπty framework 303 or application credentials associated with order management service 312) are used to establish sufficient authorization for network transactions Other configurations may be employed, however, the relatively small number of network transactions (e g , authentication transaction 331 and optional value passmg transaction 332) tends to improve performance of the secuπty architecture Of note, authentication transaction 331 need only be performed on logm credential authentication (e g , at initial sign-on or credential upgrade) or reauthenticated (e g , to refresh session credentials) Value passmg transaction 332 provides an optional facility for passmg values amongst multiple components of a distributed application (e g , a distπbuted implementation of order management service 312) wherem application credentials are used to mediate storage and retneval of values m a central registry

User 301 mteracts with browser 302 to place an order with order management service 312 An application security framework 303 receives an access request mcludmg the order and, operating m conjunction with a vanety of other services, provides a smgle sign-on facility substantially as described above If the order does not mclude a session token or cannot be otherwise associated with conespondmg valid session credentials, then session credentials are obtamed As illustrated m FIG. 3, session credentials are obtamed usmg logm credentials (e g , a username/password pair, a digital certificate, etc ) Typically, an access request without session credentials will not have associated logm credentials As a result, and default logm credentials (e g , ιdentιty=anonymous) are used during initial phases of a smgle sign-on process Nonetheless, m some configurations, logm credentials may be provided with an initial access request More typically, an mitial access request is received by application security framework 303 without session credentials or without pnor presentation and authentication of logm credentials sufficient to access the requested resource In response to credential gathermg operations, a subsequent request is made with logm credentials that purport to be sufficient, if authenticated, to meet the trust level required for access to order management service 312 In such a case, session credentials are obtamed by passmg logm credentials to a central secunty framework 304

Authorization of application secuπty framework 303 for access to components of the central secunty portion 322 is checked by query to central authorization service 306 Assuming that framework credentials evidence sufficient authorization, logm credentials are authenticated by central authentication service 307 Central authentication service 307, in turn, mteracts with central principal registry 310 to establish the identity and group membership of user 301 and with central session registry 311 to create a persistent session for subsequent accesses by user 301 Particulars of the request are logged to central audit service 308 and, if authentication was successful, session credentials are returned to application secunty framework 303

Signed session credentials are presented to application authorization service 313 together with an identifier for the requested resource and optionally with an identifier for a particular function or facility of the requested resource In response, application authorization service 313 checks the authorization of the principal (e g , of user 301) associated with the session credentials to access the requested resource Application authorization service 313 mteracts with application resource registry 314 to identify trust level requirements for the requested resource (and m some configurations, for a particular function or facility of the requested resource) and determines the sufficiency of a cunent trust level evidenced by the session credential Note that trust level is assessed by inspection of the session credential and without interaction with an authentication service In some configurations (e g , as illustrated m FIG. 3), group membership is also evaluated as part of the authorization check If the signed session credentials mdicate that the requesting entity, e g., browser 302 on behalf of user 301, is sufficiently authorized to access order management service 312, a CreateOrder request is passed to order management service 312 and order processmg proceeds in accordance with normal handlmg thereof Additional accesses may be required, e g., to select delivery options or to confirm some aspect of the order. Assuming that the additional accesses do not require a higher trust level, they will be passed to order management service 312 based on the conespondence of session credentials with trust level requirements

If an exception is thrown due to insufficient authorization, e.g., if the signed session credentials do not mdicate that the requestmg entity is sufficiently authorized to access order management service 312, a logm credential gathermg process is initiated. Based on the required trust level and on rules that encode the sufficiency of authentication schemes, a logm credential is obtamed from user 301 and/or browser 302 The obtamed login credential is of a type that, if authenticated, is sufficient to meet the trust level requirement for access to order management service 312 Aspects of an exemplary credential gathermg process are descnbed m greater detail above However, as an example, FIG. 3 illustrates the obtammg of a username/password pair. Once login credentials are obtamed, they are passed to central security framework 304 (as descnbed above) for authentication by central authentication service 307 so that session credentials can be obtamed, the requested access can be authorized, and the order processmg initiated Signed session credentials, typically embodied as a cryptographically secured session token that may be stored as a cookie, are passed back to browser 302 with results of the requested access. In this way, subsequent access requests are identified as part of a session and authorization may be quickly confirmed without unnecessary re-authentication.

Some configurations m accordance with the present mvention employ session credentials as a mechanism for evidencmg prior authentication of obtamed logm credentials and for bmdmg individual transactions to a particular session. In some configurations, session credentials are also employed m a session token form advantageous for transactions external to the secuπty architecture. In an exemplary realization, session tokens are encoded for supply to browsers as cookies. FIG. 4 illustrates relationships between exemplary logm credential, session credential and session token objects.

As descnbed above, logm credentials (e.g., represented m a form such as exemplary logm credentials structure 410) are obtamed for a client entity Typically, logm credentials encoded m logm credentials structure 410 are obtamed from a prmcipal via browser client and serve as evidence that the principal (e.g., a human user) is entitled to a particular identity. Accordingly, logm credentials structure 410 encodes a userld and a domainld within which the userld should uniquely conespond to a prmcipal. Specific logm credentials, e.g., a password, a certificate, results of a biometπc process, a response to an Enigma challenge or results of a smart card mtenogation, etc. are encoded m logm credentials structure 410, as a tagged value. An authenticationScheme is specified and creation time may be encoded to limit replay attacks. In the implementation of FIG. 4, logm credentials structure 410 is encrypted usmg the public key of an authentication service (e.g., of authentication component 130). Because the key is public, any component, even untrusted components may encrypt logm credentials for provision to authentication component 130, while only authentication component can decrypt the encrypted logm credentials usmg its pπvate key. In some configurations, secure transfer protocols, e.g., SSL, are employed to secure logm credentials between a chent entity such as browser 170 and the security architecture while encryption with a public key of an authentication service is performed withm the security architecture, e g , at logm component 120 In other configurations, encryption with a public key of an authentication service may be performed at the client entity

If the encrypted login credentials provided to an authentication service are determined to be authentic, session credentials are issued In the implementation of FIG. 4, session credentials are embodied m a form such as exemplary session credentials structure 420 Encrypted and clear text portions (421 and 422) of session credentials structure 420 allow contents of the session credential to be read by anyone and changed by no one (except the authentication service possessmg a private key) Contents of encrypted portion 421 conespond to that clear text portion 422 but are encrypted usmg the pπvate key of the authentication service (e g , of authentication component 130) Of note, principal ids, authorizations and other contents encoded m the session credential may be read by components of the security architecture, and m some embodiments by components external to the secunty architecture Such components can venfy the authenticity of mformation stored m clear text portion 422 usmg encrypted portion 421 and a public key conespondmg to the private key of the authentication service Of note, the information contamed m a session credential is generally not sensitive What is sensitive is the state of the mformation Therefore, secunty architectures employmg facilities described herem ensure that information contamed m the session credential is provably constant once set by an authentication service By usmg the public key of the authentication service, which will m general be freely available, together with the encrypted mformation, any application can read the mformation (e g , m free text) and ascertain that the session credential was created by the authentication service and that the session credential has not been tampered with Assuming that the authentication service's pnvate key has not been compromised, tampering with the session credential will result m a decryption failure

In an alternative implementation (not shown), session credentials may be digitally signed and venfied by a public key conespondmg to a pπvate key In such an alternative implementation, the digital signature also allows contents of the session credential to be read by anyone and changed by no one For some configurations, the implementation of FIG. 4 is prefened because encrypted portion 421 can be used as an externally supplied session token Such a session token representation is a compact representation of the session credential particularly appropnate for encodmg as a cookie placed at a browser and returned with subsequent access requests

Referring agam to session credentials structure 420, a session id, a prmcipal id, a trust level, group ids, a creation time and an expiration time are encoded m both m encrypted portion 421 and clear text portion 422 The session id is a unique identifier for a persistent session mamtamed by the secuπty architecture In implementations m which credential upgrade is provided or m which a session credential expiration and refresh is provided, multiple successively issued session credential mstances may encode the same session id and conespond to the same persistent session Prmcipal id encodes an identifier for a prmcipal to which the secunty architecture has resolved logm credentials For example, a logm credential mcludmg a username jdoe and a password conespondmg to jdoe may be resolved by the secunty architecture to a unique prmcipal id associated with John Q Doe of the shippmg and receivmg department, havmg an employee badge number of 12345, etc In some embodunents, a trust level encodes the authorization level to which a prmcipal has been authenticated In such embodiments, the encoded trust level serves as a basis for evaluating whether a prmcipal associated with the session credentials has been authenticated to a sufficient level for access to a requested resource For example, a trust level of 5 may be sufficient for access to mformation resources havmg a trust level requirement of 5 or less Trust levels offer an attractive decouplmg of authorization levels and authentication methods as described elsewhere herem However, m some embodiments, an authorization encodmg may establish that a prmcipal has been authenticated usmg a particular authentication mechanism In either case, an authorization (e g , encoded as a trust level) m a cryptographically secured session credential allows the security architecture to authorize accesses based on pπor authentication of a logm credential and without mvolvement of the authentication service

Group ids can be used to grant or limit authorization scope based on group membership Typically, session credentials serve as evidence of pπor authentication and authorization for multiple accesses to information resources controlled by the secuπty architecture However, session credentials may be replaced on a logm credential upgrade as described elsewhere herem In addition, session credentials of limited temporal validity may be refreshed by penodic replacement In the configuration of session credentials structure 420, creation time and expiration time allow the secunty architecture to improve resistance to replay attacks Session credentials typically have a relatively short expiration time (e g , 15 minutes from creation or less) and underlymg logm credentials will be reauthenticated pπor to expiration of the session credential Assuming that the underlymg logm credentials, which are stored under the public key of authentication component 130, remam valid, authentication component 130 will issue a replacement cryptographically secured session credential (e g , as session credentials structure 420) Dependmg on then cunent trust level mappmgs and, m some configurations, dependmg on then cunent environment parameters, the authorization accorded by the security architecture and encoded as a trust level may differ from that encoded m the session credential replaced If a prmcipal id or logm credential has been revoked, reauthentication may fail and a user may be prompted to supply a sufficient logm credentials as descnbed elsewhere herem Session id and prmcipal id will typically remam the same for successive session credentials associated with a smgle persistent session

As previously descnbed, one advantage of the approach employed m session credentials structure 420 is that encrypted portion 421 may also be employed as a compact session token representation 430 of session credential for use as a cookie In one embodiment m accordance with FIG. 4, encrypted portion 421 is a string encoded representation of approximately 200 characters which may be placed at a browser (e g , via transfer 5, 23 or 23 A of FIG. 1) usmg a set cookie directive

Exemplary Implementations

In an exemplary embodiment, at least some of the above-descπbed components are implemented as servlets executable m the context of a commercially-available web server environment For example, the Java™ Embedded Server (JES) architecture with extensions for certificate handlmg, HyperText Transfer Protocol (HTTP), Simple Network Management Protocol (SNMP), Secure Sockets Layer (SSL), extensible Markup Language (XML) grammar processmg and secuπty Access Control List (ACL) support available from Sun Microsystems, Inc is one suitable environment Java and all Java-based marks and logos are trademarks or registered trademarks of Sun Microsystems, Inc m the United States and other countnes

In general, the descnption herem is focused on aspects of a security architecture, rather than on peculiarities of a particular implementation environment It is envisioned that security architectures m accordance with the teachmgs of the present mvention may be implemented m the context of many commercially-available networked mformation service environments, mcludmg web server environments, as well as m custom environments and environments that in the future will be developed However, to facilitate an understanding of broad concepts usmg a specific exemplary environment, and without limitation, the description herem may mclude terminology specific to the Java Embedded Server (JES) architecture

Nonetheless, based on this descnption, persons of ordmary skill m the art will appreciate implementations suitable for other environments The scope of the invention, as defined by the claims that follow, is not limited to any specific implementation environment

While the invention has been descnbed with reference to vanous embodiments, it will be understood that these embodiments are illustrative and that the scope of the mvention is not limited to them Many vanations, modifications, additions, and improvements are possible For example, the set of authentication schemes described herem is illustrative and embodiments m accordance with the present mvention may mclude others, mcludmg those that may be hereafter developed If employed, rules mappmg trust levels to authentication schemes may be encoded m a vanety of ways dependmg on the particular implementation In general, such mappmg rules may be encoded as static or dynamic table associating trust level to authentication schemes Alternatively, mappmg rules may be encoded as predicates or m other declarative forms Mappmg rules may be encoded m a weighted logic or fuzzy set form Additionally, particular mappmgs may depend environment mformation Furthermore, evaluation of mappmg rules may be performed m a vanety of functional components such as an authorization service, a credential gathermg service or a gatekeeper Session contmuity may be provided usmg cryptographically secure session tokens passed as cookies or by other mechanisms

In some configurations, a session token is a compact encrypted representation of at least selected contents of a session credential Other compact representations conespondmg to a session credential may be employed Alternatively, the same representation of session credentials may be employed both within the secunty architectare and outside the secunty architecture (e g , at a browser or other client) Suitable contents of a session credential (and session token, if employed) will be appreciated by persons of ordmary skill m the art based on the descnption herem of specific examples

More generally, plural mstances may be provided for components described herem as a smgle mstance Finally, boundaries between vanous components, services, servlets, registπes and frameworks are somewhat arbitrary, and particular operations are illustrated m the context of specific illustrative configurations Other allocations of functionality are envisioned and may fall within the scope of claims that follow Structures and functionality presented as discrete components m the exemplary embodιment(s) may be implemented as a combmed structure or component These and other variations, modifications, additions, and improvements may fall withm the scope of the mvention as defined m the claims that follow

Claims

WHAT IS CLAIMED:

1 A method of determining sufficiency of a credential type for access to an mformation resource, the method compπsmg establishing a conespondence between a session and an access request targetmg the mformation resource, establishing a trust level requirement for access to the mformation resource; and evaluatmg conespondence of one or more credential types with the trust level requirement for access to the mformation resource and with environment information associated with the session.

2 A method as m claim 1, wherem one or more authenticated credentials of the one or more credential types are associated with the session; and wherem the conespondence evaluatmg mcludes determinmg whether at least one of the one or more authenticated credentials is sufficient to achieve the trust level requirement given the environment mformation

3. A method as m claim 2, further compπsmg if at least one of the one or more authenticated credentials is sufficient to achieve the trust level requirement given the environment mformation, allowing the requested access; and otherwise, obtaining and authenticating a sufficient credential before allowing the requested access.

4 A method as m claim 1, wherem the conespondence evaluatmg mcludes determinmg a set of the credential types sufficient to achieve the trust level requirement given the environment information.

5. A method as m claim 4, further compnsing: obtammg at least one credential of a type selected from the set of sufficient credential types; authenticating a client entity thereby; and performing the requested access on behalf of the client entity.

6 A method as m claim 1, wherem the conespondence evaluating mcludes evaluatmg a mappmg rule encodmg suitable credential types as a function of trust levels and environment parameters.

7 A method as m claim 1, wherem the session conespondence establishing mcludes use of a cryptographically secured session token encoded with the access request to resolve the session and the environment mformation. 8 A method as in claim 1, further compπsmg comcident with receipt of the access request, updatmg the environment mformation associated with the conespondmg session

9 A method as in claim 1, wherem the environment mformation mcludes one or more of connect location, access request time, access request date, session start time, session start date, client type and client capabilities

10 A method as m claim 1 , wherem the session mcludes a dial-up connection, and wherein the environment mformation mcludes one or more of connection speed and low-level lme encryption

11 A method as m claim 1 , wherem the environment mformation mcludes one or more of source identifier and signaling type

12 A method as m claim 1, wherem the session mcludes a network connection, and wherem the environment mformation mcludes one or more of source network, source node, Virtual

Pnvate Network (VPN) low-level encryption and routing mformation

13 A method as m claim 1, wherem the set of the credential types mcludes one or more of a username password pa r, digital certificate, an encrypted credentials based on asymmetric, symmetπc, public, pnvate, or secret key technology, a one-time password, a biometπc credential based on retinal scan, voice pπnt, or finger print, and a possession based credential embodied m a smart card, Enigma card or physical key

14 A method as m claim 1, wherem the trust level requirement establishmg mcludes querying an authorization service with a resource identifier for the mformation resource targeted by the access request and with a session identifier for the conespondmg session

15 A method as m claim 1, embodied as a computer program product mcludmg functionally descriptive mformation for directmg a processor to perform the conespondence establishmg, the trust level requirement establishmg, and the evaluating, the computer program product encoded by or transmitted m at least one computer readable medium selected from the set of a disk, tape or other magnetic, optical, or electronic storage medium and a network, wireline, wireless or other communications medium 16 A method of operating a security architecture, the method compπsmg matchmg an access request of a client entity with a conespondmg session, the access request targetmg a first of plural mformation resources and the session havmg an associated one or more session parameters affectmg sufficiency of credential types, determining a set of one or more credential types sufficient for access to the first information resource, the determining based, at least m part, on the one or more session parameters, if an authenticated credential associated with the session is of one of the sufficient credential types, then allowing access to the first mformation resource, and otherwise, obtammg a new credential and authenticating the client entity thereby, the obtamed credential bemg of one of the sufficient credential types, and allowing access to the first mformation resource

17 A method as m claim 16, wherem the determining of sufficient credential types mcludes obtammg a trust level requirement associated with the first mformation resource, selectmg only those credential types sufficient, if authenticated, to achieve the trust level requirement given cunent values of the one or more session parameters

18 A method as m claim 16, wherem the determining of sufficient credential types mcludes evaluating decision logic encodmg the set of sufficient credential types as a function of the session parameters and particular one of the information resource for which access is requested

19 A method as m claim 17, wherem the decision logic is encoded at least partly as one of mappmg rules, fuzzy sets, and session parameter-based trust level discounts, and an enumeration of trust level and session parameter minima conespondmg to individual of the credential types

20 A method as m claim 16, wherem the determining of sufficient credential types mcludes evaluatmg decision logic encodmg the set of sufficient credential types as a function of the session parameters and a trust level requirement associated with the targeted information resource

21 A method as m claim 16, wherem the one or more session parameters are indicative of temporal, locational or connection- related states of the matched session

22 A method as m claim 16, wherein the client entity mcludes a browser, and wherem the matchmg of the access request with the session mcludes use of a cryptographically secured session token encoded m cookie supplied to the browser

23 An mformation system compπsmg plural mformation resources hosted on one or more servers coupled via a commumcation network to a client entity, the plural mformation resources havmg individualized authentication requirements, and an access control facility common to the plural mformation resources, the common access control facility obtammg a credential for the client entity and authenticating the client entity thereby, wherein, m response to a request for access to a first of the mformation resources, the common access control facility evaluates, based m part on cunent parameters of a conespondmg persistent session, sufficiency of associated authenticated credentials for access to the first mformation resource

24 An access control facility for providmg a smgle sign-on for sessions that potentially mclude accesses to plural mformation resources havmg differmg security requirements, the access management system compπsmg. an application proxy for receivmg an access request targeting one of the mformation resources, associatmg the access request with a session, and selectively proxymg the access request; means responsive to the application proxy for evaluatmg sufficiency of credential types based on then cunent parameters of the session and on a trust level requirement of the targeted information resource, the application proxy proxymg the access request if at least one sufficient credential is associated with the session

25 An access control facility as m claim 24, further compπsmg: credential gathermg means responsive to an insufficient zero or more credentials associated with the session, the credential gathermg means obtammg a credential of type sufficient, if authenticated, to achieve the trust level requirement of the targeted information resource given then cunent parameters of the session

26 An access control facility as m claim 24, embodied as a computer program product encoded by or transmitted m at least one computer readable medium selected from the set of a disk, tape or other magnetic, optical, or electronic storage medium and a network, wirelme, wireless or other communications medium