Integrating heterogeneous authentication and authorization mechanisms into an application access control system

FIELD OF THE INVENTION

The present invention relates to security systems in computer systems, and in particular, integration of heterogeneous security systems into an application access control system.

BACKGROUND OF THE INVENTION

Computer networks have become ubiquitous in business, industry, and education. These networks typically have one or more resources, such as applications, that provide various computing functions. Development of the globally accessible, packet-switched network known as the Internet has enabled network resources to become available worldwide. Hypertext protocols that implement the World Wide Web have evolved, (“The Web”), enabling networks to serve as a platform for global electronic commerce and the easy exchange of information between businesses and their customers, suppliers and partners.

Businesses are rushing to make their applications available over networks, including the Web, and just as quickly stumbling into several roadblocks. For example, some information is valuable and sensitive, and needs to be made available only to selected users. Thus, there is a need to provide selective access to network resources and information over the Web.

This need exists in the context of internal Web networks that are available to employees of an organization, called Intranets, as well as Web networks and resources that are available to external customers, suppliers and partners of the organization, called extranets. Extranet users may require access to a large number of applications, for example, product catalogs, customer databases, or inventory systems. There may be millions of potential users, the number of which grows dramatically as an organization grows.

One approach to some of the foregoing problems and needs is the application approach. Under the application approach, a security mechanism is provided for each application program. Often, the security mechanism provided for an application is the application's own native security system. When a user connects to an application through a network, the security mechanism for the application is invoked. For example, when connecting to an accounting application, the accounting application invokes its security mechanism. The security mechanism obtains a user id and password from the user, and then authenticates the user. Authentication refers to the process of using information to identify a user (“authentication input”) and verifying that the user is what the information purports the user to be. Examples of authentication input include user id and password received from a user, or a digital certificate.

An advantage of the application approach is that it may use security mechanisms that already exist. Use of existing security systems avoids reprogramming applications to use another security system and reconfiguring the other security system, by, for example, re-entering the user id and passwords of existing users.

A disadvantage of the application approach is that it results in a heterogeneous set of security mechanisms, each of which may present the user with a different authentication procedure. Even if two security systems use the same authentication procedure, such as user id/password authentication, a user may use one user id and password pair on one system, and another user id and password pair on another system. Obviously, tracking different user ids and passwords can be very burdensome to a user.

Another disadvantage of the foregoing approach is duplication of management processes. To provide user access to a set of applications, an administrator must repeatedly add the user to each security system in use. The redundancy of these processes, combined with rapid growth in the number of users, can make the cost of deploying, managing and supporting a system unacceptably high.

Another disadvantage stems from the use of a common user interface for accessing applications over a network. The user interface is configured to interact with each security mechanism that may be accessed through the common user interface. Thus, adding a new security mechanism for a new or existing application may require reprogramming, recompilation, and reinstallation of the common user interface.

For example, new security mechanisms such as retinal scanners are becoming available. However, integrating such mechanisms is difficult. The required effort may increase costs and delays to implement new applications and security mechanisms to undesirably high levels.

Based on the foregoing, it is clearly desirable to provide a mechanism to govern access to one or more information resources in which selective access is given to particular users, a mechanism that is equally adaptable to an internal network environment and to an external network environment and which takes advantage of existing security mechanisms, and a mechanism that is easy to re-configure as new user applications and authentication techniques become available.

SUMMARY OF THE INVENTION

The foregoing needs and objects, and other needs and objects that will become apparent from the following description, are achieved by the present invention, which comprises, in one aspect, an access control system. The access control system includes a server which provides authentication and authorization services. The server uses the authentication and authorization services from a set of remote servers, which may be servers that provide the authentication services from legacy access control systems, or specialized access control systems such as authentication services based on retinal scans.

The services of the remote servers may be accessed through proxy servers. The proxy server serves as an interface between the server and the other remote servers, and provides an API through which the services of the remote servers may be accessed. The proxy servers may be instantiations of a subclass of a base class. The base class defines methods for the API. Due to the power and simplicity of the inheritance feature of object oriented technology, developers may develop subclasses which inherit the methods of the base class. A software developer need only implement methods needed to interface with a particular remote server.

A remote server may provide authentication services, authorization services, and the ability to edit information stored on the remote servers regarding users. The authorizations received by a server from the remote server may be translated into a form of authorizations used by the server. The translated authorizations may be migrated to the server, and stored in persistent storage for later use by the server.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 is a block diagram depicting an access control system coupled to a system protected by the access control system;

FIG. 2 is a block diagram depicting an access control system in greater detail than FIG. 1;

FIG. 3A is a block diagram of method that may be used to implement an integration of security systems in an application access system;

FIG. 3B is a block diagram of additional methods;

FIG. 4A is a flow diagram of a method of integrating security systems into an application access system;

FIG. 4B is a flow diagram of optional processes in the method of FIG. 4A;

FIG. 4C is a flow diagram of further steps in the method of FIG. 4A;

FIG. 5 is a block diagram depicting a computer system upon which an embodiment of the present invention may be implemented.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A method and apparatus for integrating heterogeneous authentication and authorization mechanisms into an application access control system is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Operational Context

FIG. 1 is a block diagram depicting elements of an information access system <b>100</b> according to a preferred embodiment. Generally, an Information Access System <b>100</b> comprises a plurality of components including an Access Server <b>106</b>, Registry Server <b>108</b>, and Proxy Security Servers <b>130</b>, and Remote Security Servers <b>140</b>. The foregoing components cooperate to control access to resources stored on one or more Protected Servers <b>104</b>. Each component comprises one or more modules. There may be any number of Protected Servers <b>104</b>. Users are individuals who have a relationship with an organization and play various roles, and are registered in the system <b>100</b>. Users may be members of an organization, or may be customers, suppliers, or business partners of the organization. Administrators control the system. A server is a executable module that resides on at least one computer and which provides services to clients requesting those services.

In one embodiment, Protected Servers <b>104</b>, Access Server <b>106</b>, and Registry Server <b>108</b> are configured as disclosed in co-pending application Ser. No. 09/113,609 filed Jul. 10, 1998, the entire disclosure of which is hereby incorporated by reference as if fully set forth herein.

A browser <b>103</b> is coupled by a communication link to a network <b>102</b>. The block shown for browser <b>103</b> represents a terminal, workstation computer, or an equivalent that executes a standard Web browser program or an equivalent, such as Netscape Communicator or Internet Explorer. Network <b>102</b> is a compatible information communication network, such as the Internet. In alternate embodiments, the browser <b>103</b> is a client process or client workstation of any convenient type, and the network <b>102</b> is a data communication network that can transfer information between the client and a server that is also coupled to the network.

Authentication and Authorization Module <b>114</b> manages authentication and authorization services in Information Access System <b>100</b>. To provide authentication and authorization services, Authentication and Authorization Module <b>114</b> uses data stored in a central repository and managed by Authentication and Authorization Module <b>114</b> or uses authentication and authorization services provided by Remote Security Servers <b>140</b>. The authentication and authorization services provided by Remote Security Server <b>140</b> may be accessed through a Proxy Security Server <b>130</b>. A Proxy Security Server <b>130</b> serves as an interface between Authentication and Authorization Module <b>114</b> and a Remote Security Server <b>140</b>.

Proxy Security Servers <b>130</b> provide an application programmer interface (“API”). An API is a symbolic interface that defines inputs and outputs to a set of computer program routines through which services provided by a server may be accessed by clients of the server. The API provided by Proxy Security Servers <b>130</b> allows Authentication and Authorization Module <b>114</b> to access services provided by Remote Security Servers <b>140</b>. To assist Remote Security Servers <b>140</b> in servicing the requests of Information Access System <b>100</b>, Authentication and Authorization Module <b>114</b> also provides a set of services for Remote Security Servers <b>140</b>. These services are also accessed through the API.

Each of Remote Security Servers <b>140</b> manages authentication profiles about users and may manage information about access rights of one or more applications residing on Protected Servers <b>104</b>. Access rights refer generally to actions that may be performed on behalf of a given user, including, for example, access to read or write data from a Resource. A Remote Security Server <b>140</b> may be, for example, a legacy security service used by an accounting application that resides on a Protected Server <b>104</b>, which may be running under the Windows NT™ operating system. The legacy security service is the security service provided by Windows NT. Authentication and Authorization Module <b>114</b> may access the security service of Windows NT through a Proxy Security Server <b>130</b>. This ability enables Information Access System <b>100</b> to manage access to the accounting application through information and services that already exist on other security systems, preserving time, effort, and money already invested in those systems.

Access Roles

The Information Access System <b>100</b> enables administrators to implement access rules by defining roles (Access Roles) that users perform when working for an organization or conducting business with an enterprise. An Access Role may reflect a relationship of a user to the organization (employee, customer, distributor, supplier), their department within an organization (sales, marketing, engineering) or any other affiliation or function (member of quality task force, hotline staff member) that defines their information needs, and thus their access rights or privileges. Examples of Roles include Employee, Customer, Distributor, Supplier, Sales, Marketing, Engineering, and Hotline Staff.

Access Roles are defined by information identifying a name of a role and by a functional group in which the role resides. A functional group is often a department in which similar functions exist. Examples of functional groups are Marketing, Sales, Engineering, Human Resources, and Operations. Access Roles are also associated with a User Type.

Access Roles determine what resources a User can access. Further, each Access Role may allow access to a subset of information that is available in resources. For example, a User who is an Employee in the Marketing department could access Price List and New Products Resources. Thus, Information Access System <b>100</b> enables the creation of resource profiles by assigning roles to resources, and by assigning roles to users to generate access rights. Information Access System <b>100</b> automatically links a user to the resources profiles that have been assigned the same roles, so that deployment of new resources may occur rapidly.

Information Access System <b>100</b> may manage such roles using the methods and mechanisms disclosed in co-pending application Ser. No. 09/248,764, filed Feb. 12, 1999, the entire disclosure of which is hereby incorporated by reference as if fully set forth herein.

User Login

The Information Access System <b>100</b> also enables Users to log-in to the system once, and thereafter access one or more resources on a network during an authenticated session. Users may, for example, log in either with a digital certificate or by opening a login page URL with a web browser and entering a name and password. In the past, users have had to log in individually to each application that they are authorized to use. In the preferred embodiment, users always access the same login page regardless of the number of resources to which they need access. Thus, the system provides a mechanism of single secure log-in to resources available on a network.

When a user attempts log in, Information Access System <b>100</b> establishes a session. Specifically, a unique session number is generated, and port and connection information (“session information”) is stored in association with the session number. The combination of a session number and session information is referred to as a session. Session information includes information that identifies a user, and that indicates whether the user has been authenticated. A session associated with a user that has been authenticated is referred to as an authenticated session until the authenticated session expires. An authenticated session may, for example, expire after the elapse of threshold period of time. Until the authenticated session expires, the user associated with the authenticated session may access one or more resources protected by the Information Access System <b>100</b>.

If the Login attempt is successful, that is, the user has been authenticated and is authorized to access resources protected by Information Access System <b>100</b>, the Information Access System <b>100</b> presents the user with a personalized menu. The personalized menu assists the User in identifying and selecting a resource to access. In one embodiment, a personalized menu is an HTML page containing a list of authorized resources. The personalized menu displays only resources to which the User has access. The user can then select and access a Resource.

Session information may be structured and managed using the methods and mechanisms disclosed in co-pending application Ser. No. 09/363,315, filed Jul. 28, 1999, the entire disclosure of which is hereby incorporated by reference as if fully set forth herein.

Integrating Authentication Mechanisms

FIG. 2 shows Information Access System <b>100</b> in greater detail. Access Server <b>106</b> stores a log-in page, and is coupled to the Authentication and Authorization Module <b>114</b>. The Access Server <b>106</b> may receive authentication input regarding a particular user for a particular session and transmit it to the Authentication and Authorization Module <b>114</b>, which uses the information to authenticate a user. The Authentication and Authorization Module <b>114</b> returns information that specifies whether the user is authenticated, and the access roles for the user.

The Authentication and Authorization Module <b>114</b> authenticates the user in one or more ways. The Authentication and Authorization Module <b>114</b> may authenticate a user by verifying the password with the Registry Server <b>108</b>. Alternatively, the Authentication and Authorization Module <b>114</b> may use authentication services of one of the Remote Security Services <b>140</b> to authenticate the user.

The Registry Server <b>108</b> manages a registry repository <b>109</b>, which may be structured as a database. The registry repository contains information about how to authenticate users and what authorizations a user has, including a mapping of a particular user to access roles. Information about how to authenticate a particular user is referred to as an authentication profile, and may include data indicating a user id, password, and which Proxy Security Servers <b>130</b> to use to authenticate a user. An authorization is a privilege to perform a particular action with respect to a set of resources on a computer system. For example, an authorization may define access to a particular Web page or a set of directories.

For each user it authenticates, the Authentication and Authorization Module <b>114</b> generates data representing the authorizations of the user in the form of access roles. The Authentication and Authorization Module <b>114</b> generates the access roles using authorization information recorded by Registry Server <b>108</b>, or authorization information obtained from Remote Security Service <b>140</b> through a Proxy Security Server <b>130</b>. It then encrypts data representing the access roles and sends the encrypted data in a cookie to the user's browser. A “cookie” is a packet of data sent to web browsers. Each cookie is saved by browser <b>103</b> until the cookie expires. A returned cookie is required for access to resources protected by Information Access System <b>100</b>.

A Session Manager <b>112</b> manages sessions throughout Information Access System <b>100</b>. Session Manager <b>112</b> establishes new sessions upon request by various components of Information Access System <b>100</b>, including, for example, Access Server <b>106</b> when Access Server <b>106</b> is logging in a user. Session Manager <b>112</b> also expires sessions according to various criteria and techniques.

Logging Service <b>116</b> receives information about the actions taken by various modules of Information Access System <b>100</b> and records actions as events in one or more logs. For example, when Session Manager <b>112</b> expires an authenticated session, Session Manager <b>112</b> transmits a message to record the expiration of the authenticated session.

The Topology Mechanism <b>118</b> tracks various components of Information Access System <b>100</b> when the components starts up. In particular, Topology Mechanism <b>118</b> receives messages from a particular component when it starts up, and, in response, may transmit messages to other components to inform them that the particular component has started.

Integration Tools <b>115</b> are selectively executed on Information Access System <b>100</b> and function to customize the particular configuration of the foregoing components. For example, Integration Tools <b>115</b> are used to customize the form or content of screen displays presented by browser <b>103</b> for user login and logout, or to enforce password selection rules, or to program and develop Proxy Security Servers <b>130</b>. Integration Tools <b>115</b> include Proxy Security Server Base Class <b>117</b>, which are later described.

Proxy Configuration Data <b>113</b> is data that specifies the configuration of each of Proxy Security Servers <b>130</b>. Proxy Configuration Data <b>113</b> specifies, for example, whether a particular Proxy Security Server <b>130</b> provides authorization services. Proxy Configuration Data <b>113</b> shall later be described in greater detail.

In one embodiment, Information Access System <b>100</b> is stored on and executed by one physical server or computer. In alternate embodiments, one or more components are installed on separate computers.

Starting Up the Authentication and Authorization Module and Proxy Security Servers

In an embodiment, the Session Manager <b>112</b>, Logging Service <b>116</b>, and Topology Mechanism <b>118</b> start up before Authentication and Authorization Module <b>114</b> and any of Proxy Security Servers <b>130</b>. Relative to each other, a Proxy Security Server <b>130</b> and the Authentication and Authorization Module <b>114</b> may start-up in any order.

When the Authentication and Authorization Module <b>114</b> starts up, it reads Proxy Configuration Data <b>113</b> and stores data representing the Proxy Configuration Data <b>113</b> in memory. Authentication and Authorization Module <b>114</b> then checks-in with the Topology Mechanism <b>118</b>. If any of Proxy Security Servers <b>130</b> have previously started up and checked-in with Topology Mechanism <b>118</b>, then Topology Mechanism <b>118</b> transmits a message to Authentication and Authorization Module <b>114</b> indicating the availability of the already running Proxy Security Servers <b>130</b>.

When a Proxy Security Server <b>130</b> starts up, it checks-in with Topology Mechanism <b>118</b>. If Authentication and Authorization Module <b>114</b> is already running, then Topology Mechanism <b>118</b> transmits a message indicating the availability of the Proxy Security Server <b>130</b> that has just checked in.

Proxy Security Service Framework

A Proxy Security Server <b>130</b> allows Authentication and Authorization Module <b>114</b> to access any Remote Security Servers <b>140</b> through a common API. The API enables Authentication and Authorization Module <b>114</b> to interface with any Remote Security Servers <b>140</b> in a common manner. The Authentication and Authorization Module <b>114</b> and Proxy Security Servers <b>130</b> may be compliant with Common Object Request Broker Architecture (CORBA) communicating to each other using the framework defined by CORBA. Proxy Security Servers <b>130</b> may be Java objects that are instantiations of Java classes.

Proxy Security Server Base Class <b>117</b> is an abstract class from which Proxy Security Server Subclasses inherit methods and data. A Proxy Security Server Subclass, represented in FIG. 2 by Proxy Security Servers <b>130</b>, is a class from which a Proxy Security Server <b>130</b> may be instantiated. The Proxy Security Server Base Class <b>117</b> defines methods of the API. Some of the methods are implemented in the base class. Other methods are implemented in a subclass of the base class.

A Proxy Security Server <b>130</b> may implemented as multi-threaded CORBA server that interacts with the Authentication and Authorization Module <b>114</b> and a Remote Security Servers <b>140</b>. The Proxy Security Servers Base Class <b>117</b> supplies the implementations to support CORBA, multi-threading, and other aspects of a Proxy Security Server <b>130</b>. Due to the power and simplicity of inheritance in object oriented development environment, a developer of a particular Proxy Security Server subclass does not have to address CORBA or the multi-threaded aspects of a Proxy Security Server subclass. A developer need only extend from the Proxy Security Server Base Class <b>117</b> to implement a limited set of methods needed for a particular Remote Security Server <b>140</b>.

Services Provided by Proxy Security Servers Through the Common API

A Proxy Security Server <b>130</b> makes available services provided by Remote Security Servers <b>140</b> to Information Access System <b>100</b>. These services are accessed by invoking a method of the API, and in particular, may be accessed by invoking methods of Proxy Security Servers <b>130</b>. The methods may be implemented in the Proxy Security Server Subclasses <b>200</b>, as shown in FIG. 3A, although for some of these methods a default behavior is implemented in the base class. A description of the methods that may be implemented, and the functionality they provide as services, follows. Additional details about these methods and their functionality, and about additional methods and functionality, may be found in Appendix I.

AUTHENTICATION: A Proxy Security Server Base Class <b>117</b> defines at least one method that may be invoked to authenticate a user. The authentication method <b>202</b> is implemented in a Proxy Security Server Subclass. See, for example, pam_sm_authenticate in Appendix I. Generally, the implementation for this method is specific to a particular Remote Security Server <b>140</b>. Authentication and Authorization Module <b>114</b> passes a session identifier and authentication input, such as a user id and password, digital signature, or biometric data, for example, a thumbprint image. The method is executed to authenticate the user associated with the session, in accordance with its then-current implementation. The architecture and configuration of elements disclosed herein, in combination with the power and versatility of object oriented languages that may be exploited to develop subclasses results in a set of Proxy Security Servers <b>130</b> that interface to a wide range of Remote Security Servers <b>140</b>.

REMOTE AUTHORIZATION: Proxy Security Server Base Class <b>117</b> may define at least one method that allows Authentication and Authorization Module <b>114</b> to modify authorizations on a Remote Security Server <b>140</b>. The remote authorization method <b>204</b> is implemented in a Proxy Security Server Subclass. See, for example, pam_chauthtok(String pamh), in Appendix I. The ability to modify authorizations on a Remote Security Server <b>140</b> is referred to as remote authorizations. A developer provides the implementation for the method. When Authentication and Authorization Module <b>114</b> invokes the method, it passes in a session identifier.

REMOTE PROFILING: Proxy Security Server Base Class <b>117</b> defines at least one method that provides the ability to modify a user profile on a Remote Security Server <b>140</b>. A user profile is data describing demographic information about a user, for example, the user's address, full name, and marital status. The method remote profiling <b>206</b> is implemented in a Proxy Security Server Subclass. See, for example, pam_chauthtok, in Appendix I. This ability to alter a user profile on a Remote Security Server <b>140</b> is referred to as remote profiling. A developer provides the implementation for the method. When Authentication and Authorization Module <b>114</b> invokes the method, it passes in the session identifier.

COMMUNICATING AVAILABLE FUNCTIONALITY: Not all Proxy Security Servers <b>130</b> provide the same set of services. For example, a Proxy Security Server <b>130</b> may provide authentication and remote profiling, but not remote authorization. When a Proxy Security Server <b>130</b> starts up, Authentication and Authorization Module <b>114</b> needs to know what services a particular Proxy Security Server <b>130</b> provides. For this purpose, a Proxy Security Server Base Class <b>117</b> provides at least one communication method. The communication method <b>208</b> is implemented in a Proxy Security Server Subclass. See, for example, getImplementedFunctions( ) in Appendix I.

Functionality Provided by Authentication and Authorization Module to Proxy Security Servers

To provide services to Authentication and Authorization Module <b>114</b>, a Proxy Security Server <b>130</b> may need to obtain information through Authentication and Authorization Module <b>114</b>, or request other services from Authentication and Authorization Module <b>114</b>. For example, a Remote Security Server <b>140</b> may need to query a user to get data for changing a user profile. Such services are accessed by invoking a method of the API defined in Proxy Security Server Base Class <b>117</b>. A description of these services follows and FIG. 3B depicts the structure of the methods. Additional details about these services and their functionality, and about additional services and methods, may be found in Appendix II.

INTERFACING WITH A HUMAN USER: Proxy Security Server Base Class <b>117</b> defines at least one method that be invoked to communicate with a human user. Such methods are referred herein to as conversation methods. See pam_conv in Appendix II. For example, to change a user profile, a method that implements remote profiling may invoke a conversation method <b>210</b> to obtain inputs from the user that are used to update the user profile. Input parameters passed to the conversation method may specify whether user input should be obtained using a text box, a label for the text box, and whether user input is echoed as it is entered, or a list of selections to be displayed in a list box presented to the human user.

ENVIRONMENT INFORMATION: Proxy Security Server Base Class <b>117</b> defines at least one method that may be invoked to obtain information about a user or the operating environment. For example, a method may be invoked to obtain the user id and password associated with a session, or the network address of the device from which the user is attempting to log in. These methods may comprise a Get Environment method <b>212</b>, Get Environment List method <b>214</b>, Get Configuration method <b>216</b>, and Get User Method <b>218</b>. See, pam_getenv, pam_getenvlist, pam_get_configuration, pam_get_user, for example, in Appendix II.

Registration and Self Registration

Registration refers to a process of receiving data that identifies a user and specifies an authentication profile for the user. A user may be registered in Information Access System <b>100</b> in a variety ways. For example, a system administrator may use an administrative user interface provided by Information Access System <b>100</b> for receiving data used to register users from a system administrator. In particular, Information Access System <b>100</b> receives input that specifies a user id, which Information Access System <b>100</b> stores in Register Server <b>108</b>. In addition, Information Access System <b>100</b> receives data from a system administrator specifying an authentication profile. The authentication profile may include data specifying a Proxy Security Server Name that corresponds to a Proxy Security Server <b>130</b> used to authenticate the user.

Self-Registration refers to a process in which a user registers itself, by supplying to the Information Access System <b>100</b> data that specifies an authentication profile. For example, when a user first logs into to Information Access System <b>100</b>, Access Server <b>106</b> presents a login page to the user. The login page includes a text box for the user to enter a user id and a password, and a list box listing Proxy Security Server Names as selections. The user enters the strings “John Doe” as the user id and “DoeString” as the password, and picks a selection from the list box. Information Access System <b>100</b> then transmits a message to a Proxy Security Server <b>130</b> that corresponds to the selected Proxy Security Server Name. In an embodiment, the message is transmitted by invoking the pam_auth method of the Proxy Security Server <b>130</b>.

The Proxy Server <b>130</b> then transmits a message indicating that the user is authenticated to Authentication and Authorization Module <b>114</b>. In response, Authentication and Authorization Module <b>114</b> registers the user id, storing in Registry Server <b>108</b> data specifying the user id and Proxy Security Server Name. The user may later add or delete Proxy Security Server Names, or other information in the user's authentication profile.

Dynamic Authorization Mapping

Once a registered user is authenticated, the authorizations for the user are determined. Typically, a user is associated with a default set of authorizations. In addition, a system administrator may have assigned access roles to a particular user. When a user logs into Information Access System <b>100</b>, the Authentication and Authorization Module <b>114</b> gets from Registry Server <b>108</b> the access roles assigned to the user. In addition, the Authentication and Authorization Module <b>114</b> will get authorizations from any Proxy Security Server <b>130</b> specified in the user's authentication profile.

The authorizations obtained from Proxy Security Server <b>130</b> may not be in the form of access roles, and thus may be converted to Access Roles in a process referred to as Dynamic Authorization Mapping. In a dynamic authorization mapping, authorizations provided by Proxy Security Servers <b>130</b> are converted to Access Roles based on a mapping. The mapping is stored in Proxy Configuration Data <b>113</b>, and shall be described in greater detail. The Access Roles generated by the conversion are merged with any Access Roles specified by Registry Server <b>108</b> for the user.

Migrating Authorizations from Remote Security Servers

Information Access System <b>100</b> may used to replace a legacy security system. The effort invested in configuring a legacy security system with authentication and authorization information may be preserved by implementing a Proxy Security Servers <b>130</b> for the legacy security system. However, it may be desired to eventually discontinue use of the legacy system, so the information on the legacy security system must be transferred to Information Access System <b>100</b>.

One technique described herein for efficiently transferring this information is referred to Dynamic Migration. Dynamic Migration is the process of permanently assigning Access Roles generated by converting information from a Remote Security Server <b>140</b>. These converted access roles are subsequently associated with the user whenever the user logs in. Dynamic Migration may be performed when a user self registers. Data in Proxy Configuration Data <b>113</b> specifies whether Dynamic Migration is performed for a Proxy Security Server <b>130</b>, that is, whether Dynamic Migration is performed for a user who self registers and selects the Proxy Security Server <b>130</b>.

Configuration Data

Configuration Data <b>113</b> is organized as one or more blocks of data, each of which is associated with a Proxy Security Servers <b>130</b>. Each block contains entries that specify an operational aspect of a Proxy Security Server <b>130</b>. Each entry contains a string specifying a parameter name, followed by a ‘=’ character, followed by string specifying a parameter value. An example of Configuration File <b>15</b> follows.

[UserPasswordPam]

name=UserPasswordPam

desc=Userid/Password

usrtag=Userid

pwdtag=Password

env=

translate=false

selfreg=false

authsourcename=UserPassword

config=getAccessRoot:c:\enCommerce\getAccess∥debug:false

[CertPam]

name=CertPam

desc=Certificate

usrtag=

pwdtag=

env=CLIENT_CERT∥COOKIE:CERTCOOKIE#

translate=false

selfreg=false

authsourcename=Certificate

config=getAccessRoot:c:\enCommerce\getAccess∥debug:false

A block begins with a tag, which may be a bracketed string, that specifies a Proxy Security Server Name. The example above has two blocks. The first block begins with the tag ‘[UserPasswordPam]’.

The first entry in the first block is the name value pair ‘name=UserPassword’, and it specifies a Proxy Security Server Name. ‘name’ is the parameter name, and ‘UserPassword’ is the Proxy Security Server Name.

The Proxy Security Server Name is used to associate a Proxy Security Server <b>130</b> with a block. A Proxy Security Server <b>130</b> is associated with a Proxy Security Server Name when the Proxy Security Servers <b>130</b> is started, by, for example, specifying the Proxy Security Server Name as input argument value in the command used to invoke the proxy server. A Proxy Security Server <b>130</b> associated with a Proxy Security Server Name is herein referred to as the named Proxy Security Server <b>130</b>.

The parameter ‘desc’ specifies a description that is displayed to the user to refer to the named Proxy Security Servers <b>130</b>.

Parameter ‘usrtag’ is the entry for the label displayed next to a text box used to receive user input specifying a user id.

Parameter ‘pwdtag’ is the entry for the label displayed next to a text box used to receive user input specifying a password.

Parameter ‘env’ is used to specify an environmental variable that is caught. The block beginning with the tag [CertPam] indicates certification parameters and shows a use of the parameter ‘env’. In this case, the environment variable could be called CLIENT_CERT, or can be sent in the form of cookies.

The parameter ‘selfreg” is used to specify whether a user may self register by selecting the named Proxy Security Server <b>130</b>.

The parameter ‘translate’ specifies whether dynamic mapping is performed for the authorizations supplied by the named Proxy Security Server <b>130</b>.

The ‘config’ entry depends on the Proxy Security Servers <b>130</b> itself. For example, a Proxy Security Servers <b>130</b> used to interface to a Remote Security Servers <b>140</b> that uses Windows NT Domain Authentication requires the number of domains to authenticate as well as the name of each of the domain.

Specifying a Mapping in the Configuration Data

To perform dynamic authorization mapping, a mapping is specified in the block associated with a Proxy Security Server <b>130</b>. The example entry illustrates a mapping for a Proxy Security Server <b>130</b> that interfaces with a Remote Security Server <b>140</b> that uses Windows NT Domain Authentication.

[NTDomainPam]

name=NTDomainPam

desc=NT Domain Authentication

usrtag=Userid

pwdtag=

env=

translate=true

selfreg=true

authsourcename=NTDomain

config=numberOfDomains=1∥domain1:Marketing

usertype=undef

Domain Users=emplye

Domain Admins=excacc.spradm

The example Proxy Configuration Data <b>113</b> above specifies to Authentication and Authorization Module <b>114</b> that a Proxy Security Server <b>130</b> associated with the Proxy Security Server Name NTDOMAIN can perform self-registration and dynamic authorization mapping. If the authorizations returned by the named Proxy Security Server <b>130</b> include the ‘Domain Users’ group, the user type will be translated to ‘emplye’. Likewise, if the returned authorizations include ‘Domain Admins’, then the user has the administrative role referred to as ‘excacc.spradm’.

Example Method of Operation

FIG. 4A is a flow diagram of an exemplary method of operation of the system of FIG. <b>2</b>. The method of FIG. 4A may be implemented in one or more computer programs, processes, data structures, or related elements that form Authentication and Authorization Module <b>114</b>.

In block <b>400</b>, a request to access a protected server is received from a client. For example, Browser <b>103</b> as shown in FIG. 1 contacts Access Server <b>106</b> and requests an electronic document of one of the Protected Servers <b>104</b>. Access Server <b>106</b> forwards the request to Authentication and Authorization Module <b>114</b>.

In block <b>402</b>, a proxy security server is requested to authenticate the client using information that identifies the client. For example, Authentication and Authorization Module <b>114</b> uses authentication method <b>202</b> to request one of the proxy security servers <b>130</b> to authenticate the client. In the course of executing the authentication step, the proxy security server may use one of the remote security services <b>140</b> to conduct authentication.

If the authentication request is unsuccessful, then the access server returns a message to the client indicating that access is refused. These steps are omitted from FIG. 4A for clarity. If the authentication is successful, then in block <b>404</b>, authorization is received from the proxy security server based on authentication results that are received from a remote security service that is associated with the proxy security server.

In block <b>406</b>, access rights for use with an application access system and associated with the client are established. The process of FIG. 4C may be used.

Optional processes may be carried out after block <b>406</b> or at any other appropriate time in the process, as indicated by block <b>408</b>. FIG. 4B is a block diagram of optional processes <b>408</b> that may be carried out. The optional processes <b>408</b> may include one or more of remote authorizations <b>410</b>, remote profiling <b>412</b>, or communications such as receiving information on available proxy services, as indicated by block <b>414</b>. Optional processes <b>408</b> may also include registration <b>416</b> or self registration <b>418</b>. These processes may be carried out using the mechanisms described above with respect to FIG. 2, FIG. 3A, and FIG. <b>3</b>B.

FIG. 4C is a flow diagram of further steps that may be used to carry out the process of block <b>406</b>.

In block <b>420</b>, authorizations associated with the current client are received form the proxy security server. In block <b>422</b>, a mapping of authorizations to access roles is obtained. The mapping may be stored in and obtained from Configuration Data <b>113</b>.

In block <b>424</b>, the authorizations are converted to access roles that can be used by an access control system such as Information Access System <b>100</b>. When conversion is complete, one of three paths may be followed. One path is that the process may terminate processing, as indicated by the “DONE” block. Another path is that the process may persistently store the converted access roles in a registry, for example, using Registry Repository <b>108</b>, for use later.

Still another path is that the process may carry out dynamic migration, as indicated by block <b>428</b>. In dynamic migration, the access roles are persistently stored in the access control system in association with user identifying information. The remote security server may be decoupled from the system, as shown by block <b>432</b>. Thereafter, the access roles are used to authenticate the user. In this way, authentication information in a legacy remote security server is automatically transferred to the access control system, and the legacy remote security server may be retired from service.

Hardware Overview

FIG. 5 is a block diagram that illustrates a computer system <b>500</b> upon which an embodiment of the invention may be implemented. Computer system <b>500</b> includes a bus <b>502</b> or other communication mechanism for communicating information, and a processor <b>504</b> coupled with bus <b>502</b> for processing information. Computer system <b>500</b> also includes a main memory <b>506</b>, such as a random access memory (RAM) or other dynamic storage device, coupled to bus <b>502</b> for storing information and instructions to be executed by processor <b>504</b>. Main memory <b>506</b> also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor <b>504</b>. Computer system <b>500</b> further includes a read only memory (ROM) <b>508</b> or other static storage device coupled to bus <b>502</b> for storing static information and instructions for processor <b>504</b>. A storage device <b>510</b>, such as a magnetic disk or optical disk, is provided and coupled to bus <b>502</b> for storing information and instructions.

Computer system <b>500</b> may be coupled via bus <b>502</b> to a display <b>512</b>, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device <b>514</b>, including alphanumeric and other keys, is coupled to bus <b>502</b> for communicating information and command selections to processor <b>504</b>. Another type of user input device is cursor control <b>516</b>, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor <b>504</b> and for controlling cursor movement on display <b>512</b>. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

The invention is related to the use of computer system <b>500</b> as an access control system. According to one embodiment of the invention, an access control system is provided by computer system <b>500</b> in response to processor <b>504</b> executing one or more sequences of one or more instructions contained in main memory <b>506</b>. Such instructions may be read into main memory <b>506</b> from another computer-readable medium, such as storage device <b>510</b>. Execution of the sequences of instructions contained in main memory <b>506</b> causes processor <b>504</b> to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor <b>504</b> for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device <b>510</b>. Volatile media includes dynamic memory, such as main memory <b>506</b>. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus <b>502</b>. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor <b>504</b> for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system <b>500</b> can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus <b>502</b>. Bus <b>502</b> carries the data to main memory <b>506</b>, from which processor <b>504</b> retrieves and executes the instructions. The instructions received by main memory <b>506</b> may optionally be stored on storage device <b>510</b> either before or after execution by processor <b>504</b>.

Computer system <b>500</b> also includes a communication interface <b>518</b> coupled to bus <b>502</b>. Communication interface <b>518</b> provides a two-way data communication coupling to a network link <b>520</b> that is connected to a local network <b>522</b>. For example, communication interface <b>518</b> may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface <b>518</b> may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface <b>518</b> sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link <b>520</b> typically provides data communication through one or more networks to other data devices. For example, network link <b>520</b> may provide a connection through local network <b>522</b> to a host computer <b>524</b> or to data equipment operated by an Internet Service Provider (ISP) <b>526</b>. ISP <b>526</b> in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” <b>528</b>. Local network <b>522</b> and Internet <b>528</b> both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link <b>520</b> and through communication interface <b>518</b>, which carry the digital data to and from computer system <b>500</b>, are exemplary forms of carrier waves transporting the information.

Computer system <b>500</b> can send messages and receive data, including program code, through the network(s), network link <b>520</b> and communication interface <b>518</b>. In the Internet example, a server <b>530</b> might transmit a requested code for an application program through Internet <b>528</b>, ISP <b>526</b>, local network <b>522</b> and communication interface <b>518</b>. In accordance with the invention, one such downloaded application provides for an access control system as described herein.

The received code may be executed by processor <b>504</b> as it is received, and/or stored in storage device <b>510</b>, or other non-volatile storage for later execution. In this manner, computer system <b>500</b> may obtain application code in the form of a carrier wave.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

APPENDIX I

Methods Used to Access Services Provided by Proxy Security Server

abstract protected int pam_sm_authenticate(String pamh, String args[ ])

Any Proxy Security Server Class should implement this method to provide authentication. This is the core of developing a Proxy Security Server Classes because authentication is the minimum action that a Proxy Security Server Classes performs. This method receives the Proxy Security Server Class handle (pamh) for the user session and a set of arguments. The Proxy Security Server Classes handle is the handle that provide extra information about the user, and the second parameter is an array of arguments that are passed to the authentication method. Currently, the second parameter is an empty array. This method should return one of the following return codes:

PAM_SUCCESS—This code is returned when the authentication process was successful.

PAM_ACCT_EXPIRED—This code is returned when the user account is inactive, but the user is authentic.

PAM_USER_UNKNOWN—This code is returned when the user is an unknown user or the userid, password combination is not valid.

PAM_NEW_AUTHTOK_REQD—This code is returned when a new password is required, this means that the current password has expired or is no longer valid for any other reason.

PAM_CRED_INSUFFICIENT—This code is returned when the credentials are not sufficient to validate the user.

PAM_AUTH_ERR—This code is returned when an unexpected error occurs.

PAM_FATAL—This code is returned if there is a fatal error in the remote security server.

abstract protected Thread getNewInstance(String pamh, PAMDataShare dataShare)

This method is called to thread out when multiple users are using a Proxy Security Server and to perform conversation back to the user.

public int getImplementedFunctions( )

This method should return the methods implemented by the Proxy Security Server Classes. By default, all Proxy Security Server Classes implement only authentication. A developer does not need to modify overwrite this method if the Proxy Security Server Class only performs authentication with no other actions. If the Proxy Security Server Class may change authentication profile and authorizations on a remote security server, then the Proxy Security Server communicates the methods that it can handle. The methods that may be handled are specified as return values set to a combination of codes shown below. To specify more than one code, append the codes together delimited by a ‘|’.

F_CHAUTHTOK—This code is returned if the Proxy Security Server allows passwords to be changed on a remote security server. That means that Authentication and Authorization Module <b>114</b> is free to call pam_chauthtok and this method should already be overwritten. Please refer to the pam_chauthtok method.

F_GETPRIVILEGES—This code is returned if the Proxy Security Server allows authorization to be changed on an remote security server. This means that Authentication and Authorization Module <b>114</b> is free to call pam_get_privileges and this method should already be overwritten. Please refer to the pam_get_privileges method.

F_GETPRIMARYPRIVILEGES—This code is returned if the Proxy Security Server Classes support primary privileges. What this means is that Information Access System <b>100</b> identifies primary privileges to be like a user type within the Information Access System <b>100</b>. The pam_get_primary_privileges method should be implemented because Authentication and Authorization Module <b>114</b> can call it after authentication.

F_SETPROFILES—This code is returned if the Proxy Security Server supports property setting to the external system. This means that attributes can be changed in the source system and this method is in charge of setting those attributes. Also, this method is in charge of displaying the current values or options to the users so that they are aware of the changes.

public int pam_chauthtok(String pamh) throws PAMHandleException

This method is called by Authentication and Authorization Module <b>114</b> when Proxy Security Servers <b>130</b> allows changing passwords on the system. The pam_chauthtok implements, for example, challenging the user and changing the user's password in a Remote Security Server <b>140</b>.

public String[ ]pam_get_privileges(String pamh) throws PAMHandleException

This method is called by Authentication and Authorization Module <b>114</b> when a Proxy Security Server allows authorizations to be changed on a Remote Security Server <b>140</b>. The pam_get_privileges is in charge of returning a list of privileges that the user has in the source system. For example, Windows NT users have groups associated with them; so, the Proxy Security Server Class can return the list of groups associated with the user. These privileges are then passed to Authentication and Authorization Module <b>114</b>, which is responsible for converting the privileges to access roles.

public String[ ]pam_get_primary_privileges(String pamh) throws PAMHandleException

This method is called by Authentication and Authorization Module <b>114</b> when remote authorization is enabled. The pam_get_primary_privileges returns a list of main privileges that the user has on the Remote Security Server <b>140</b>. For example, under Windows NT Domain Authentication, users have a primary group associated with them. The Proxy Security Server can return the group associated with the user. These primary privileges are then passed to Authentication and Authorization Module <b>114</b> and Authentication and Authorization Module <b>114</b> converts the privileges into user types.

public int pam_set_profile (String pamh) throws PAMHandleException

This method is called by Authentication and Authorization Module <b>114</b> when user profile information may be changed on a Remote Security Servers <b>140</b>. The pam_set_profile changes specific property or attribute information in a Remote Security Servers <b>140</b> source system. For example, a Proxy Security Server allows a user to change their name, address, and marital status stored in a user profile on a Remote Security Servers <b>140</b>. This method needs to perform the conversation to the user and ask the specific information from the user himself. This method should return one of the following return codes:

PAM_SUCCESS—This code is returned when the authentication process was successful.

PAM_ACCT_EXPIRED—This code is returned when the user account is inactive.

PAM_USER_UNKNOWN—This code is returned when the user is a unknown user or the userid, password combination is not valid.

PAM_AUTH_ERR—This code is returned when an unexpected error occurs.

PAM_FATAL—This code is returned if there is a fatal error in the external system. Either the dynamic library did not load correctly or can not communicate with the external system with the given configuration.

public String get_pam_unique_user(String pamh) throws PAMHandleException

This method is called by Authentication and Authorization Module <b>114</b> after authenticating the user. This is the unique userid for the user for a specific Proxy Security Server Class. The need for this method stems from the Proxy Security Server's ability to handle different users with the same userid that reside in different groupings. For example, Windows NT Domain Authentication differentiates users with the same userid from different domains by pre-pending the domain name followed by a back slash “\”. The default behavior for this method is to return the userid that was entered by the user. Therefore, this method does not need to be changed if there is no differentiation between users in different groupings.

public void pam_finish_auth(String pamh, String gaUserLogin) throws PAMHandleException

This method allows a Proxy Security Server to perform additional tasks after a user a authenticated. For example, the Proxy Security Server may save some information in a database or flat file. The string gaUserLogin is data identifying the user in issue. The default behavior is to do nothing. This method is only called after user login was successful and the user was authenticated.

public String[ ]get_associated_pam(String pamh, String gaUserLogin) throws PAMHandleException

This method is called after a successful self-registration and the Proxy Security Server decides to make the user login to another Proxy Security Server that is not the one that the current Proxy Security Server supports. For instance, a self-registration for userid/password can request Authentication and Authorization Module <b>114</b> to associate the user with LDAP [what is <b>1</b>dap?] because the Proxy Security Server might have created the LDAP account. Authentication and Authorization Module <b>114</b> calls pam_finish_auth right after the account is created, but before the association of the authentication method.

abstract public String pam_version( )

This method needs to be implemented by a Proxy Security Server Subclass to return its version.

abstract public String pam_author( )

This method needs to be implemented by a Proxy Security Server Subclass to return the Proxy Security Server Subclass author.

public anyPAAM( ) &amp; public anyPAAM(String name, String authSourceName)

There are two constructors for any Proxy Security Server Subclass that are used to initialize the base class. These constructor can also initialize private member variables after calling the base class.

public boolean setConfiguration(String array[ ])

This method is called by Authentication and Authorization Module <b>114</b> to set the configuration for a Proxy Security Server Class. Extra functionality can be added to this method after calling the base class.

APPENDIX II

Methods Used to Access Services Provided by Authentication and Authorization Module

protected String pam_get_configuration(String key)

This method is used to get the data about the configuration of a Proxy Security Server. You can get any configuration parameter by just giving the name of the configuration parameter. The parameters values are specified by the parameter ‘config’ in Proxy Configuration Data <b>113</b>.

protected String pam_getenv(String pamh, String name) throws PAMHandleException

This method is used to get any environment variables from the Authentication and Authorization Module <b>114</b>. Valid parameter names may be are:

REMOTE_ADDR—The IP address from where the user is accessing the information access system.

SERVER_NAME—The name of the server hosting the Web Server communicating with the users browser. [Note to inventor: Please explain what this parameter is].

SERVER_PORT—The port number where the Web Server is listening to HTTP requests.

HTTP_USER_AGENT—The name of the user's browser (Netscape, MSIE, etc.).

HTTP_REFERER—The referrer page. The page that sent the user to the current script.

REMOTE_USER—The userid of the user trying being authenticated.

protected Hashtable pam_getenvlist(String pamh) throws PAMHandleException

This method is used to get the list of all the environment variables that are sent by the Information Access System <b>100</b>. This can be used to find out what variables are currently be sent by the Information Access System <b>100</b>.

public String pam_get_item(String pamh, int itemType)

throws PAMHandleException, PAMSymbolException

This method is used to get a specific item of information related to a session. The possible values for itemType, and the corresponding information that is returned when the itemType is set, are shown below.

PAMDataShare.PAM_USER—The userid.

PAMDataShare.PAM_AUTHTOK—The user's password.

PAMDataShare.PAM_OLDAUTHTOK—The user's old password.

PAMDataShare.PAM_AUTH_PURPOSE—The login purpose. This item type is used when the Proxy Security Server Class is configured to perform different types authentication. The purposes can be:

1. AUTH_PURPOSE—Authentication purpose.

2. SELFREG_PURPOSE—Self-registration purpose.

3. OTHERSELFREG_PURPOSE—Adding authentication method purpose.

protected String pam_get_user(String pamh) throws PAMHandleException

This method is used to get the userid of the user. This function is exactly the same as calling pam_get_item with the PAM_USER as the item type.

protected String[ ]pam_conv(String pamh, int msgType[ ], String msg[ ])

This method is used by a Proxy Security Server to communicate back to the user. This is the only way in which a Proxy Security Server can ask specific questions to the user. This method requires the message type and the actual message. The message types allowed are:

PAM_PROMPT_ECHO_OFF—The message type causes the user input not to be displayed. That means the user will not see what he/she is typing. The text that is placed as the label will be translated with the message itself.

PAM_PROMPT_ECHO_ON—The message type is a normal input text. The label will be translated with the message of the same array index.

PAM_PROMPT_RW—This message type will display a translated label with a non-translated field that is read and write. This means that the user will see the current value for the label and change it.

PAM_PROMPT_R—This message type will display a translated label with a non-translated field that is read only. This means that the user will only see the current value for the label.

PAM_ERROR_MSG—This is an error message that will be displayed in the browser the user is using. The error message is a label that will be translated.

PAM_TEXT_INFO—This is a textual information that will be displayed to the user. The message is actually a label that will be translated.

PAM_NOXLATE_TEXT—This message type is the same as PAM_TEXT_INFO, but the message is not translated.

PAM_CHOICE—The message type is used to generate selections that may be selected by the user. Both the label and the choices will be translated. The delimiter between the label and the choice is a colon (“:”).

PAM_NOXLATE_CHOICE—This message type is the same as PAM_CHOICE with the only difference that the choices will not be translated.

protected void set_item_object(String pamh, Object obj) throws PAMHandleException

This method is used to set an object that will be later used by the Proxy Security Server Classes. This is very useful for storing information when doing self-registration because some methods are called at the end of the self-registration process to perform any action needed by the Proxy Security Server. The best way to use this method is to store a hashtable with information and then retrieve them. A sample usage is to store information that is used in the authentication method and then retrieve them in the pam_finish_auth method. The pam_finish_auth is called after a user self registers.

protected Object get_item_object(String pamh) throws PAMHandleException

This method is used to get an object that set from a previous called method. This method can be used in the pam_finish_auth to retrieve the information that was set previously.