WO2002013114A1 - Systems and methods for integrating independent secure application service providers - Google Patents

Systems and methods for integrating independent secure application service providers Download PDF

Info

Publication number
WO2002013114A1
WO2002013114A1 PCT/US2001/041457 US0141457W WO0213114A1 WO 2002013114 A1 WO2002013114 A1 WO 2002013114A1 US 0141457 W US0141457 W US 0141457W WO 0213114 A1 WO0213114 A1 WO 0213114A1
Authority
WO
WIPO (PCT)
Prior art keywords
asp
user
partner
account
payroll
Prior art date
Application number
PCT/US2001/041457
Other languages
French (fr)
Inventor
Craig Sullivan
Brian Chess
Original Assignee
Netledger, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Netledger, Inc. filed Critical Netledger, Inc.
Publication of WO2002013114A1 publication Critical patent/WO2002013114A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2119Authenticating web pages, e.g. with suspicious links

Definitions

  • the invention relates to application service providers, and in particular to systems and methods for integrating software from application service providers where only partial trust exists between the providers.
  • ASPs Application service providers
  • This software runs on a server hosted by the ASP and has the advantage that the ASP can handle maintenance and upgrades centrally.
  • ASP Application service providers
  • Businesses are able to enjoy lower IT costs, seamless upgrades, and economies of scale. economies of scale benefit the business in two ways.
  • sharing the cost of the maintenance and upgrade costs of applications means that each business using the ASP saves money.
  • Second, the business is able to utilize highly reliable enterprise applications, such as Oracle databases, that would otherwise be beyond their means.
  • Another benefit of the ASP model is the potential for anytime, anywhere access.
  • a single client application such as a Web browser
  • a user can access the ASP from any personal computer with an Internet connection.
  • an employee with appropriate authorization on a business trip overseas can review accounting, sales or customer information, and upload or download updates before returning home.
  • Security is of paramount importance for an ASP.
  • Network security includes four interrelated areas: secrecy, authentication, non-repudiation, and integrity.
  • Secrecy is the ability to keep information out of the hands of unauthorized users.
  • Authentication deals with determining the identity of a user before divulging confidential information or entering into a business deal.
  • Non-repudiation deals with proving if a given user sent the message, while integrity control deals with making sure the message sent by a user was really the one sent and not maliciously modified.
  • the present mvention describes systems and methods for integrating independent secure systems where only partial trust exists.
  • ASPs Application Service Providers
  • the invention pertains to implementation by and between Application Service Providers (ASPs) and their software/hardware systems.
  • ASPs Application Service Providers
  • the ASP system and the partner system are the software/hardware resources used to deliver software to users over the Internet.
  • user we refer to a current subscriber of at least one ASP.
  • Either ASP may group users within an account, where each user has a specific set of permissions within that account. Integration between the two systems takes place on a case- by-case basis at the request of the user. Because integration and data exchange are implemented in a highly secure manner, each ASP can participate as long as it adheres to certain requirements intended to benefit the user. For example, for a partner system to be available for integration with the ASP system, the manager/operators of the systems should agree to certain requirements, for example, specifically, the actions that one system is permitted to perform in the other system on behalf of the user.
  • each ASP may desire independent choice of network security to ensure secrecy, authentication, non-repudiation, and integrity of its users. It permits continued use of the security measures if desired to ensure only authorized users are able to access and modify data relating to the secure account. These security measures typically require a user login at each ASP to access its software, and do not take in to account the requirements for maintaining security in circumstances where complementary software and systems share data.
  • the present invention provides a method to maintain security at each ASP by not requiring the sharing of sensitive authentication information, such a users password, while providing the ability for data to be exchanged seamlessly between the ASP systems once integration has occurred.
  • a user with only an Internet connection and a Web browser can adopt and use complementary services from more than one ASP and request that those ASPs exchange data on their behalf.
  • the invention provides means of authenticating and authorizing users and their associated transaction/query transmissions of systems in circumstances where only a partial trust relationship exists without the need for systems to divulge or store the respective sensitive authentication information of their users.
  • Figure 1 is a diagram of a system, which can be used as a partner system and/or the ASP system.
  • Figure 2 illustrates the user initiating integration of the partner system with the ASP system and the associated mapping between the partner account and the ASP account in the ASP system database.
  • Figure 3 illustrates confirmation of the integration being transmitted to the user and to the partner system as a result of completing the integration between the partner system and the ASP system.
  • Figure 4 is a flow diagram illustrating how software permits integration of a partner system with the ASP system.
  • Figure 5 illustrates communications supporting integration of a partner system with the ASP system.
  • Figure l is a diagram of a Web application architecture, which can be used by both the partner system and ASP system.
  • Web-based applications can be implemented using three software components: a Web server, an application server, and a database.
  • the Web site may have dozens of computers running each component in order to service a large number of simultaneous users.
  • ASPs commonly dedicate some of these components to specialized tasks like server-to- server data exchange.
  • Figure l shows a configuration with two Web servers, two application servers, and a single database.
  • the purpose of the Web server is to accept requests and generate responses using the Hyper Text Transfer Protocol (HTTP). More than half of the Web sites on the Internet today use the Apache Web server. Apache, which comes packaged with most Linux operating system packages, is suitable because of its power, flexibility, ease of use, and availability for multiple platforms. Wainwright, Professional Apache (1999) describes one Web server and how to configure it, and is incorporated by reference. However, it is not essential that the present invention use Apache. It could be implemented using a variety of Web servers including Microsoft-IIS running on Windows 2000 or the Netscape-Enterprise Web server. It is also not essential to the invention what operating system is used. Further, it is not essential what hardware is used to run the software components described here. It can be Intel, Sun, HP, or any other suitable hardware platform.
  • HTTP requests are Web browsers like Microsoft's Internet Explorer or Netscape's Navigator.
  • one Web server and one application server are dedicated to servicing requests from Web browsers.
  • Another source of HTTP requests are other Web-based applications.
  • the configuration in Figure l shows a second Web server (with a data exchange configuration) and a second application server dedicated to servicing data exchange requests from such applications.
  • a Web server can fulfill the request itself by reading the response directly out of a file. If, on the other hand, servicing the request requires dynamically generated or personalized content, the Web server must pass the request to a more specialized piece of software like an application server such as Apache JServ. The application server will generate a response and send it back to the Web server, and the Web server will in turn forward the response back to the requester.
  • HTTP Hyper Text Markup Language
  • Apache JServ includes software components, written in the C and Java languages, which communicate using a known protocol such as Apache JServe Protocol (AJP). Because it is a Java application, Apache JServ runs inside a Java Virtual Machine (JVM). The Java Programming Language, third edition (2000) describes the language and is incorporated by reference. The person of ordinary skill will know from the specification how to implement all of the data structures, session management, security checks, and other functions, e.g., in Java, that compose the applications.
  • Java servlet A Java program that accepts an HTTP request and produces an HTTP response is called a Java servlet or simply a servlet.
  • Professional Java Server Programming (1999) describing servlets and related server-side technologies is incorporated by reference.
  • a servlet API library and a servlet engine can be downloaded as a Java Servlet Development Kit (JSDK) at http://java.sun.com/products/serylet/.
  • the present invention can also use a servlet named GNU JSP to implement the Java Server Page standard.
  • GNU JSP Java Server Pages
  • JSP Java Server Pages
  • Java beans objects that persist over multiple HTTP requests. Java beans are used to store session information like a user name and a password so that a user does not have to provide authentication information every time they request a new page.
  • Java DataBase Connection allows the Java applications (e.g., servlets) to communicate with a database.
  • the Java driver is type 4, an all-Java driver issuing requests directly to the database, which does not require additional libraries or middleware to install.
  • Many major database vendors provide type 4 JDBC drivers for their databases.
  • the user may integrate independent secure ASPs by taking the following steps:
  • the user uses a Web browser to go to a partner system, e.g., Web site, and logs on by entering authentication information such as a user name and a password. If authenticated, the user is presented an option to integrate the partner account with the ASP account by clicking on a hypertext link in a Web page from the partner's system. This link is preferably only available to users with privileges sufficient to perform integration.
  • a partner system e.g., Web site
  • the partner system Upon selecting the link, the partner system will cause the user's browser to perform a redirect action to the partner's specific Web page on the ASP system, e.g., Web site as shown in Figure 3.
  • the ASP Web server receives the request and passes the request to a Java servlet, which determines the validity of the authentication token appended to the URL delivered by the user's browser.
  • the Java servlet If the authentication token is valid, the Java servlet generates a Web page. From the page the user may choose either to login to the ASP or sign-up as discussed in the account creation section below. Whether logging in or signing up the user provides authentication information to the ASP by filling out a form and submitting the form to the ASP Web server.
  • the ASP Web server passes the request to a Java servlet.
  • the Java servlet determines whether the user has authority to enable the integration by querying the ASP database. For example, if the user is logging on, the password must correspond to the user name. In addition, the user's permission in the ASP must allow for them to enable integration with other systems.
  • the Java servlet will generate a Web page to provide the user with a choice on whether to permit the ASP and partner systems to exchange data and perform various actions on behalf of the user. Additionally, this Web page may also provide the user with the option to enable single sign-on between the systems as discussed below.
  • a Java servlet will write the partner system's identifiers for the user (e.g., ACCOUNTED and USER_ID), the name of the partner, and the corresponding ASP identifiers for the user in the ASP partner authentication table in the database.
  • the Java servlet will generate a Web page confirming to the user that the integration with the partner system has been successful.
  • the servlet may also generate a confirmation message to the partner system indicating that the integration is complete.
  • the partner system may then record in its database that the integration with the ASP has taken place.
  • a partner system chooses, when the user selects the sign-up option, a Java servlet will generate a form that is preferably populated with information already stored with the partner system. To populate the form, the Java servlet will submit a request to the partner system for account information for the user. The request will contain the partner system's identifiers for the user's account (e.g., ACCOUNTJD and USER_ID) as previously provided by the partner system. The partner system will then return the appropriate account information.
  • the partner system will contain the partner system's identifiers for the user's account (e.g., ACCOUNTJD and USER_ID) as previously provided by the partner system.
  • the partner system will then return the appropriate account information.
  • the purpose of the authentication token is to prove the identity of the user as defined in the partner system.
  • the authentication token contains the identity of the user or provides access to the information identifying the user.
  • the authentication token is preferably encrypted or digitally signed by the partner in order to prevent tampering or render tampering ineffective.
  • the authentication token could contain the partner system's unique identifiers (e.g., ACCOUNTJD and USER_ID), and a timestamp giving the time the authentication token was generated.
  • the timestamp could be formatted as the number of milliseconds since January l, 1970, 00:00:00 GMT.
  • the authentication token could be a URL.
  • the partner may encrypt the authentication token using a known cryptography technique, such as a public-key algorithm like the RSA algorithm or a shared secret key.
  • the ASP Java servlet When the ASP Java servlet receives an authentication token from a partner system, it will determine the partner's identity. This is determined from the token itself or from the URL associated with the token. For example, if the partner system redirects the user to https://system.theASP.com/partners/di7berf.jsp, the ASP system will recognize the partner is "Dilbert.”
  • the ASP may use the timestamp to ensure the authentication token is valid. For example, the ASP may define that a valid authentication token must be received within ⁇ 10 minutes of its timestamp to account for variability of the clocks at the ASP system and the partner system.
  • the ASP can provide a single sign-on method to allow users of independent secure systems to move seamlessly between the systems without the need to perform a second authentication process. This assumes the user has integrated accounts and selected the option for single sign-on as presented in the confirmation Web page described earlier.
  • Single sign-on includes the following steps:
  • the user uses a Web browser to go to a partner Web site and logs on by entering authentication information such as the user name and a password.
  • the user is presented an option such as a hypertext link to access the ASP account without the need to re-authenticate at the ASP Web site.
  • the partner system Upon selecting the option, the partner system will cause the user's browser to perform a redirect action to the partner's specific Web page on the ASP Web site.
  • the partner system appends an authentication token as discussed above in the redirect URL.
  • the ASP Web server receives the request and passes the request to a Java servlet, which determines the validity of the authentication token appended to the URL delivered by the user's browser.
  • the Java servlet queries the ASP database using the user's identity in the partner system to determine whether the user selected the single sign-on option during the integration process (as discussed earlier) and the user's identity in the ASP system. If the user has selected the single sign-on option, the Java servlet will use the user identity to log the user into the ASP account without the need to re-authenticate.
  • Reverse single sign-on refers to users wishing to access the partner system from the ASP without being required to re-authenticate, i.e., perform a second login at the partner system.
  • the single sign-on process described above would be implemented with the ASP system communicating the user's identity in the partner system in an authentication token to the partner system.
  • the systems can automatically exchange data with one another on behalf of the user.
  • the data exchange can be implemented by using secure socket layer (SSL) client and server certificates to verify the identity of both the originator and recipient of data.
  • SSL secure socket layer
  • the partner system has data that it wishes to transmit to the ASP system to update the user's ASP account. For the partner system to transmit the data to the ASP, the following occurs:
  • the partner system generates a data file containing the information to be transmitted and the unique identifier for the user's account in the partner system.
  • the partner system opens a secure connection to a data exchange server in the ASP system, using a protocol such as HTTPS.
  • the partner system requests a server-side certificate from the ASP data exchange Web server to verify its identity.
  • the ASP data exchange Web server then verifies the identity of the partner by requesting an SSL client- side certificate.
  • the partner system transmits the data file to the ASP data exchange server.
  • the ASP Java servlet receives the data file and determines whether the partner system has permission to perform the action requested by querying the ASP database.
  • the servlet queries the database using the user's identity in the partner system to determine the ASP user identity. Using this information the partner data can be written in the ASP database.
  • the servlet generates a confirmation message and transmits it to the partner system.
  • the partner system wishes to perform a query in the ASP system.
  • the partner system wishes to perform the query, the following occurs:
  • the partner system generates a data file containing the query to be transmitted and the unique identifier for the user's account in the partner system.
  • the partner system opens a secure connection to a data exchange server in the ASP system, using a protocol such as HTTPS.
  • the partner system requests a server-side certificate from the ASP data exchange Web server to verify its identity.
  • the ASP data exchange Web server then verifies the identity of the partner by requesting an SSL client- side certificate.
  • the partner system transmits the data file to the ASP data exchange server.
  • the ASP Java servlet receives the data file and determines whether the partner system has permission to perform the action requested by querying the ASP database.
  • the servlet queries the database using the user's identity in the partner system to determine the ASP user identity. Using this information the ASP system performs the query.
  • the servlet When the query has been completed, the servlet generates a data file for transmission to the partner system.
  • the ASP system has data that it wishes to transmit to the partner system to update the user's partner account.
  • the ASP system transmits the data to the partner system, the following occurs:
  • the ASP system generates a data file containing the information to be transmitted and the unique identifier for the user's account in the partner system.
  • the ASP system data exchange Web server opens a secure connection to the partner system, using a protocol such as HTTPS.
  • the ASP system data exchange Web server requests a server-side certificate from the partner system to verify its identity.
  • the partner system then verifies the identity of the ASP system data exchange Web server by requesting an SSL client-side certificate.
  • both SSL certificates are valid, the ASP system data exchange Web server transmits the data file to the partner system.
  • the partner system receives the data file and determines whether the ASP system has permission to perform the action requested.
  • the partner system queries the database using the user's identity in the partner system. Using this information the ASP data can be written in the partner system database.
  • the partner system generates a confirmation message and transmits it to the ASP system data exchange Web server.
  • the ASP system wishes to perform a query in the partner system.
  • the ASP system wishes to perform the query, the following occurs:
  • the ASP system generates a data file containing the query to be transmitted and the unique identifier for the user's account in the partner system.
  • the ASP system data exchange Web server opens a secure connection to the partner system, using a protocol such as HTTPS.
  • the ASP system data exchange Web server requests a server-side certificate from the partner system to verify its identity.
  • the partner system then verifies the identity of the ASP data exchange Web server by requesting an SSL client-side certificate.
  • the ASP system data exchange server transmits the data file to the partner system.
  • the partner system receives the data file and determines whether the ASP system has permission to perform the action requested by querying the partner system database.
  • the partner system queries the database using the user's identity in the partner system. Using this information the partner system performs the query. • When the query has been completed, the partner system generates a data file for transmission to the ASP system data exchange Web server.
  • Partner A partner application service provider that is being integrated with the ASP.
  • Payroll System The software/hardware resources used to deliver the Web- based payroll application to users over the Internet.
  • Account A grouping of users.
  • Permissions refers to the privileges (or rights) a given user or partner has within the ASP. For example, only certain users may be given rights to modify payroll data in the payroll system.
  • Integration Agreement In order to become a partner, an integration agreement is first signed. This agreement will contain the terms of integration, specific to the partner, for its integration with the ASP. General terms of integration might include: the method of integration, privacy requirements, security requirements, non-competition, service level agreements and customer support arrangements.
  • the integration agreement will contain a schedule that describes the permissions that are assigned to the partner for its integration with the ASP. These permissions are partner specific and are assigned on an as needed basis.
  • the ASP Upon completion of the integration agreement, the ASP will add the payroll system to the partner permissions table and enable the appropriate permissions based upon the contents of the integration agreement.
  • SSL Secure Socket Layer
  • Client-side certificates Enables each system to confirm its identity when initiating communication.
  • the systems will perform integration testing to ensure they have been configured correctly and perform as expected.
  • the ASP Upon completion of this process, the ASP would allow communication between its servers and the payroll system in a production environment;
  • the user has an account in the payroll system identified as follows:
  • the user has an account with the ASP identified as follows:
  • the user selects the link that is published in the payroll system for the purpose of performing integration with the ASP.
  • the payroll system generates an authentication token as described above and includes it in the re-direct URL that is transmitted back to the user's browser.
  • the user is re-directed to the ASP system that then analyzes the authentication token included in the re-direct URL to determine the user's identity in the payroll system. Decrypting the authentication token reveals the user's identity in the payroll system:
  • the ASP system then performs a database query to determine whether it recognizes this user. If the ASP is unable to locate an entry in its database that matches the user's identity in the payroll system, it is assumed that the user has not yet performed integration and a Web page is displayed explaining the benefits of the integration and provides the user with the option to login to the ASP system to complete the process. The user selects the login option and enters their authentication information for the ASP system.
  • the ASP system determines whether the user has the appropriate Permissions to enable integration for data exchange between the ASP system and the payroll system.
  • the ASP system determines whether the payroll system has been enabled for integration by querying the partner permissions table. If the payroll system has an entry in the partner permissions table it is assumed that they have been enabled for integration.
  • the user is presented with a Web page that informs them that they are performing integration with their account on the payroll system and describes the Permissions that are assigned to the payroll system for the ASP system account. At this time the user is also given the option to enable single sign-on between their accounts, which they choose to accept in this example.
  • the ASP system Upon confirming the integration and enabling single sign-on, the ASP system writes the following data to its database:
  • the ASP system transmits a confirmation message to the payroll system.
  • the user is re-directed to the ASP system that analyzes the authentication token included in the re-direct URL to determine the user's identity in the payroll system.
  • the ASP system then performs a database query to determine whether it recognizes this user. If the ASP system is unable to locate an entry in its database that matches the user's identity in the payroll system, it is assumed that the user has not yet performed integration.
  • the ASP system is able to locate the following user/account mapping information.
  • the ASP system is also able to confirm that single sign-on has previously been enabled.
  • data exchange between the two systems can be performed.
  • data exchange between the two systems will be performed using XML as described in the ASP data exchange for integrated accounts document and a suitable Document Type Definitions (DTD) or a XML schema such as that described as follows: http://www.smbxml.org
  • the first data that is exchanged between the two systems would be to synchronize pre-existing data.
  • the payroll system will contain employee records, payroll history, earnings/deductions codes, etc.
  • the payroll system generates an XML document with a header containing the following basic information:
  • the payroll system opens an HTTPS connection to the ASP system partner XML server.
  • the payroll system requests a server-side certificate from the ASP system data exchange Web server to verify its identity.
  • the ASP system data exchange Web server then verifies the identity of the partner by requesting an SSL client-side certificate.
  • the payroll system Upon successful validation of the SSL client-side certificate, the payroll system transmits the XML document to company.
  • the ASP system receives the data file and determines whether the payroll system has permission to perform a create paycheck action by querying the partner permission table in its database.
  • ASP reads the XML document header and performs a query in the partner Authentication Table using the payroll system's account (ChristyCat) to determine if a valid integration for this account has been completed.
  • the ASP system Upon determining that the payroll system has permission and that a valid integration has been completed for this account, the ASP system queries the database using the user's identity in the payroll system to determine the ASP system account identity. Using this information the partner data can be written in the ASP system database.
  • the paycheck can be created in the ASP system account.
  • the ASP system generates a confirmation message and transmits it to the payroll system.
  • ASP Upon finding the payroll system account "ChristyCat" in the table and determining that this account has been integrated to the ASP "Christy's Catering” account, ASP and routes the XML data accordingly.
  • the ASP generates an XML confirmation message and transmits it to the partner system.

Abstract

In Figure 3, the user uses a Web browser (100) to go to a partner system (102), e.g., Web site and logs on by entering authentication information such as a user name and a password. If authenticated, the user (100) is presented an option to integrate the partner account with the application service provide account (ASP) (103) by clicking on a hypertext link in a web page form the partner's system (102). Upon selecting the link, the partner system (102) will cause the user's browser to a perform a redirect action (104) to the partner's specific web page on the ASP system (103).

Description

Systems and Methods for Integrating Independent Secure Application Service Providers
Inventors: Craig Sullivan & Brian Chess
Background:
The invention relates to application service providers, and in particular to systems and methods for integrating software from application service providers where only partial trust exists between the providers.
In the past, software has been primarily distributed for personal computers in the form of CD-ROMs or floppy disks. More recently hardware manufacturers such as Dell Computer, HP, and Compaq have installed software directly on the hard disks of new computers before they leave the factory. Complementary software has often been marketed in packages such as Microsoft Office Suite. Unfortunately, software applications are frequently revised. Upgrading all computers to a new version of a program requires taking action on each computer individually, often causing disruption and loss of productive time.
This client-based approach to software particularly burdens small and medium sized businesses. The specialist resources required to support an internal IT infrastructure are expensive and are not part of the main focus of most businesses. Businesses of this size benefit greatly when they do not need to worry about software upgrades, maintenance, and support.
Application service providers (ASPs) have arisen to distribute Web-based applications as a service to users. This software runs on a server hosted by the ASP and has the advantage that the ASP can handle maintenance and upgrades centrally. By outsourcing the maintenance of their IT systems to an ASP, businesses are able to enjoy lower IT costs, seamless upgrades, and economies of scale. Economies of scale benefit the business in two ways. First, sharing the cost of the maintenance and upgrade costs of applications means that each business using the ASP saves money. Second, the business is able to utilize highly reliable enterprise applications, such as Oracle databases, that would otherwise be beyond their means.
Another benefit of the ASP model is the potential for anytime, anywhere access. By providing a single client application, such as a Web browser, a user can access the ASP from any personal computer with an Internet connection. For example, an employee with appropriate authorization on a business trip overseas can review accounting, sales or customer information, and upload or download updates before returning home.
Security is of paramount importance for an ASP. Network security includes four interrelated areas: secrecy, authentication, non-repudiation, and integrity. Secrecy is the ability to keep information out of the hands of unauthorized users. Authentication deals with determining the identity of a user before divulging confidential information or entering into a business deal. Non-repudiation deals with proving if a given user sent the message, while integrity control deals with making sure the message sent by a user was really the one sent and not maliciously modified.
An inherent feature of a Web-based application is the ability to interact and exchange data with other Web-based applications. When undertaking such interaction it is critical to ensure that this only takes place when approved by the user and then only in a secure manner. Summary of the Invention:
The present mvention describes systems and methods for integrating independent secure systems where only partial trust exists. For the purposes of this application we will discuss the invention as it pertains to implementation by and between Application Service Providers (ASPs) and their software/hardware systems. However, it is not intended that this would be the limit to the usefulness of the invention; it could, for example, be implemented to integrate software applications that both reside within a single system, such as a local area network.
To distinguish between activities of each ASP, we describe one as simply the ASP and the other as the partner. The ASP system and the partner system are the software/hardware resources used to deliver software to users over the Internet. By user, we refer to a current subscriber of at least one ASP. Either ASP may group users within an account, where each user has a specific set of permissions within that account. Integration between the two systems takes place on a case- by-case basis at the request of the user. Because integration and data exchange are implemented in a highly secure manner, each ASP can participate as long as it adheres to certain requirements intended to benefit the user. For example, for a partner system to be available for integration with the ASP system, the manager/operators of the systems should agree to certain requirements, for example, specifically, the actions that one system is permitted to perform in the other system on behalf of the user.
The present invention understands that each ASP may desire independent choice of network security to ensure secrecy, authentication, non-repudiation, and integrity of its users. It permits continued use of the security measures if desired to ensure only authorized users are able to access and modify data relating to the secure account. These security measures typically require a user login at each ASP to access its software, and do not take in to account the requirements for maintaining security in circumstances where complementary software and systems share data. The present invention provides a method to maintain security at each ASP by not requiring the sharing of sensitive authentication information, such a users password, while providing the ability for data to be exchanged seamlessly between the ASP systems once integration has occurred.
As a result of implementing this invention, a user with only an Internet connection and a Web browser, can adopt and use complementary services from more than one ASP and request that those ASPs exchange data on their behalf. This opens a path to an incredible array of innovative ASP offerings that leverage the features and functionality of other ASPs to automatically perform data entry and transaction processing duties on behalf of the user, whilst at the same time providing the flexibility of anytime, anywhere access.
In order to leverage the functionality of complementary applications across the Internet as described above, the invention provides means of authenticating and authorizing users and their associated transaction/query transmissions of systems in circumstances where only a partial trust relationship exists without the need for systems to divulge or store the respective sensitive authentication information of their users.
Brief Description of the Drawings:
Figure 1 is a diagram of a system, which can be used as a partner system and/or the ASP system.
Figure 2 illustrates the user initiating integration of the partner system with the ASP system and the associated mapping between the partner account and the ASP account in the ASP system database.
Figure 3 illustrates confirmation of the integration being transmitted to the user and to the partner system as a result of completing the integration between the partner system and the ASP system.
Figure 4 is a flow diagram illustrating how software permits integration of a partner system with the ASP system.
Figure 5 illustrates communications supporting integration of a partner system with the ASP system.
Description of the Preferred Embodiments:
The following description includes the best mode of carrying out the invention. The detailed description is made for the purpose of illustrating the general principles of the invention and should not be taken in a limiting sense. The scope of the invention is best determined by reference to the claims.
Figure l is a diagram of a Web application architecture, which can be used by both the partner system and ASP system. Web-based applications can be implemented using three software components: a Web server, an application server, and a database. The Web site may have dozens of computers running each component in order to service a large number of simultaneous users. ASPs commonly dedicate some of these components to specialized tasks like server-to- server data exchange. Figure l shows a configuration with two Web servers, two application servers, and a single database.
The purpose of the Web server is to accept requests and generate responses using the Hyper Text Transfer Protocol (HTTP). More than half of the Web sites on the Internet today use the Apache Web server. Apache, which comes packaged with most Linux operating system packages, is suitable because of its power, flexibility, ease of use, and availability for multiple platforms. Wainwright, Professional Apache (1999) describes one Web server and how to configure it, and is incorporated by reference. However, it is not essential that the present invention use Apache. It could be implemented using a variety of Web servers including Microsoft-IIS running on Windows 2000 or the Netscape-Enterprise Web server. It is also not essential to the invention what operating system is used. Further, it is not essential what hardware is used to run the software components described here. It can be Intel, Sun, HP, or any other suitable hardware platform.
The most common sources of HTTP requests are Web browsers like Microsoft's Internet Explorer or Netscape's Navigator. In Figure 1, one Web server and one application server are dedicated to servicing requests from Web browsers. Another source of HTTP requests are other Web-based applications. The configuration in Figure l shows a second Web server (with a data exchange configuration) and a second application server dedicated to servicing data exchange requests from such applications.
If a Web browser requests a static object, a Hyper Text Markup Language (HTML) page for example, a Web server can fulfill the request itself by reading the response directly out of a file. If, on the other hand, servicing the request requires dynamically generated or personalized content, the Web server must pass the request to a more specialized piece of software like an application server such as Apache JServ. The application server will generate a response and send it back to the Web server, and the Web server will in turn forward the response back to the requester.
As the name suggests, the purpose of the application server is to implement all of the customized logic that defines the application. Since creating that logic is the job of the ASP, an application server will come with only certain predefined functionality. Apache JServ includes software components, written in the C and Java languages, which communicate using a known protocol such as Apache JServe Protocol (AJP). Because it is a Java application, Apache JServ runs inside a Java Virtual Machine (JVM). The Java Programming Language, third edition (2000) describes the language and is incorporated by reference. The person of ordinary skill will know from the specification how to implement all of the data structures, session management, security checks, and other functions, e.g., in Java, that compose the applications.
A Java program that accepts an HTTP request and produces an HTTP response is called a Java servlet or simply a servlet. Professional Java Server Programming (1999) describing servlets and related server-side technologies is incorporated by reference. A servlet API library and a servlet engine can be downloaded as a Java Servlet Development Kit (JSDK) at http://java.sun.com/products/serylet/. The present invention can also use a servlet named GNU JSP to implement the Java Server Page standard. A Java Server Pages (JSP) combines a markup language, such as HTML or XML, with Java code to produce a dynamic Web page. Unless otherwise noted, where reference is made to "the ASP System" performing an action, that action is preferably carried out by a servlet.
The present invention also uses Java beans— objects that persist over multiple HTTP requests. Java beans are used to store session information like a user name and a password so that a user does not have to provide authentication information every time they request a new page.
Useful applications allow users to save their work and resume hours, days, or weeks later. A relational database like Oracleδi is well suited to the task of providing reliable persistent data storage although other enterprise databases may be used. The Java DataBase Connection (JDBC) protocol allows the Java applications (e.g., servlets) to communicate with a database. Preferably, the Java driver is type 4, an all-Java driver issuing requests directly to the database, which does not require additional libraries or middleware to install. Many major database vendors provide type 4 JDBC drivers for their databases.
Referring now to Figures 2-5, the user may integrate independent secure ASPs by taking the following steps:
The user uses a Web browser to go to a partner system, e.g., Web site, and logs on by entering authentication information such as a user name and a password. If authenticated, the user is presented an option to integrate the partner account with the ASP account by clicking on a hypertext link in a Web page from the partner's system. This link is preferably only available to users with privileges sufficient to perform integration.
Upon selecting the link, the partner system will cause the user's browser to perform a redirect action to the partner's specific Web page on the ASP system, e.g., Web site as shown in Figure 3. The partner system provides an authentication token as discussed below in the redirect URL. For example, the user will be redirected to https://system.theASP.com/partners/<partner name> .jsp?a= < authentication token> .
The ASP Web server receives the request and passes the request to a Java servlet, which determines the validity of the authentication token appended to the URL delivered by the user's browser.
If the authentication token is valid, the Java servlet generates a Web page. From the page the user may choose either to login to the ASP or sign-up as discussed in the account creation section below. Whether logging in or signing up the user provides authentication information to the ASP by filling out a form and submitting the form to the ASP Web server.
The ASP Web server passes the request to a Java servlet. The Java servlet determines whether the user has authority to enable the integration by querying the ASP database. For example, if the user is logging on, the password must correspond to the user name. In addition, the user's permission in the ASP must allow for them to enable integration with other systems.
If the user has authority, the Java servlet will generate a Web page to provide the user with a choice on whether to permit the ASP and partner systems to exchange data and perform various actions on behalf of the user. Additionally, this Web page may also provide the user with the option to enable single sign-on between the systems as discussed below.
If the user grants permission, a Java servlet will write the partner system's identifiers for the user (e.g., ACCOUNTED and USER_ID), the name of the partner, and the corresponding ASP identifiers for the user in the ASP partner authentication table in the database.
The Java servlet will generate a Web page confirming to the user that the integration with the partner system has been successful. The servlet may also generate a confirmation message to the partner system indicating that the integration is complete. The partner system may then record in its database that the integration with the ASP has taken place.
Account Creation
Where the user is creating an account as a result of being redirected to the ASP from the partner system, it is possible for the partner system to assist the user in completing this process in the ASP. If a partner system chooses, when the user selects the sign-up option, a Java servlet will generate a form that is preferably populated with information already stored with the partner system. To populate the form, the Java servlet will submit a request to the partner system for account information for the user. The request will contain the partner system's identifiers for the user's account (e.g., ACCOUNTJD and USER_ID) as previously provided by the partner system. The partner system will then return the appropriate account information.
Authentication Token
The purpose of the authentication token is to prove the identity of the user as defined in the partner system. The authentication token contains the identity of the user or provides access to the information identifying the user. The authentication token is preferably encrypted or digitally signed by the partner in order to prevent tampering or render tampering ineffective.
In one embodiment, the authentication token could contain the partner system's unique identifiers (e.g., ACCOUNTJD and USER_ID), and a timestamp giving the time the authentication token was generated. For example, the timestamp could be formatted as the number of milliseconds since January l, 1970, 00:00:00 GMT. In another embodiment, the authentication token could be a URL. The partner may encrypt the authentication token using a known cryptography technique, such as a public-key algorithm like the RSA algorithm or a shared secret key.
When the ASP Java servlet receives an authentication token from a partner system, it will determine the partner's identity. This is determined from the token itself or from the URL associated with the token. For example, if the partner system redirects the user to https://system.theASP.com/partners/di7berf.jsp, the ASP system will recognize the partner is "Dilbert."
After interpreting the authentication token, the ASP may use the timestamp to ensure the authentication token is valid. For example, the ASP may define that a valid authentication token must be received within ± 10 minutes of its timestamp to account for variability of the clocks at the ASP system and the partner system.
Single Sign-on Method
The ASP can provide a single sign-on method to allow users of independent secure systems to move seamlessly between the systems without the need to perform a second authentication process. This assumes the user has integrated accounts and selected the option for single sign-on as presented in the confirmation Web page described earlier. Single sign-on includes the following steps:
The user uses a Web browser to go to a partner Web site and logs on by entering authentication information such as the user name and a password.
If authenticated, the user is presented an option such as a hypertext link to access the ASP account without the need to re-authenticate at the ASP Web site.
Upon selecting the option, the partner system will cause the user's browser to perform a redirect action to the partner's specific Web page on the ASP Web site. The partner system appends an authentication token as discussed above in the redirect URL.
The ASP Web server receives the request and passes the request to a Java servlet, which determines the validity of the authentication token appended to the URL delivered by the user's browser.
If the authentication token is valid, the Java servlet queries the ASP database using the user's identity in the partner system to determine whether the user selected the single sign-on option during the integration process (as discussed earlier) and the user's identity in the ASP system. If the user has selected the single sign-on option, the Java servlet will use the user identity to log the user into the ASP account without the need to re-authenticate.
Reverse Single Sign-on Method
Reverse single sign-on refers to users wishing to access the partner system from the ASP without being required to re-authenticate, i.e., perform a second login at the partner system. To achieve this, the single sign-on process described above would be implemented with the ASP system communicating the user's identity in the partner system in an authentication token to the partner system.
Data Exchange for Integrated Accounts
After the user has completed integration of the ASP and partner systems, the systems can automatically exchange data with one another on behalf of the user. The data exchange can be implemented by using secure socket layer (SSL) client and server certificates to verify the identity of both the originator and recipient of data. In addition, it is preferred to use a separate Web server as shown in Figure l for data exchange than is used for serving Web pages. In the first example, the partner system has data that it wishes to transmit to the ASP system to update the user's ASP account. For the partner system to transmit the data to the ASP, the following occurs:
• The partner system generates a data file containing the information to be transmitted and the unique identifier for the user's account in the partner system.
• The partner system opens a secure connection to a data exchange server in the ASP system, using a protocol such as HTTPS.
• The partner system requests a server-side certificate from the ASP data exchange Web server to verify its identity. The ASP data exchange Web server then verifies the identity of the partner by requesting an SSL client- side certificate.
• If both SSL certificates are valid, the partner system transmits the data file to the ASP data exchange server.
• The ASP Java servlet receives the data file and determines whether the partner system has permission to perform the action requested by querying the ASP database.
• If the partner system has permission, the servlet queries the database using the user's identity in the partner system to determine the ASP user identity. Using this information the partner data can be written in the ASP database.
• The servlet generates a confirmation message and transmits it to the partner system.
In the second example, the partner system wishes to perform a query in the ASP system. For the partner system to perform the query, the following occurs:
• The partner system generates a data file containing the query to be transmitted and the unique identifier for the user's account in the partner system. • The partner system opens a secure connection to a data exchange server in the ASP system, using a protocol such as HTTPS.
• The partner system requests a server-side certificate from the ASP data exchange Web server to verify its identity. The ASP data exchange Web server then verifies the identity of the partner by requesting an SSL client- side certificate.
• If both SSL certificates are valid, the partner system transmits the data file to the ASP data exchange server.
• The ASP Java servlet receives the data file and determines whether the partner system has permission to perform the action requested by querying the ASP database.
• If the partner system has permission, the servlet queries the database using the user's identity in the partner system to determine the ASP user identity. Using this information the ASP system performs the query.
• When the query has been completed, the servlet generates a data file for transmission to the partner system.
In the third example, the ASP system has data that it wishes to transmit to the partner system to update the user's partner account. For the ASP system to transmit the data to the partner system, the following occurs:
• The ASP system generates a data file containing the information to be transmitted and the unique identifier for the user's account in the partner system.
• The ASP system data exchange Web server opens a secure connection to the partner system, using a protocol such as HTTPS.
• The ASP system data exchange Web server requests a server-side certificate from the partner system to verify its identity. The partner system then verifies the identity of the ASP system data exchange Web server by requesting an SSL client-side certificate. • If both SSL certificates are valid, the ASP system data exchange Web server transmits the data file to the partner system.
• The partner system receives the data file and determines whether the ASP system has permission to perform the action requested.
• If the ASP system has permission, the partner system queries the database using the user's identity in the partner system. Using this information the ASP data can be written in the partner system database.
• The partner system generates a confirmation message and transmits it to the ASP system data exchange Web server.
In the fourth example, the ASP system wishes to perform a query in the partner system. For the ASP system to perform the query, the following occurs:
• The ASP system generates a data file containing the query to be transmitted and the unique identifier for the user's account in the partner system.
• The ASP system data exchange Web server opens a secure connection to the partner system, using a protocol such as HTTPS.
• The ASP system data exchange Web server requests a server-side certificate from the partner system to verify its identity. The partner system then verifies the identity of the ASP data exchange Web server by requesting an SSL client-side certificate.
• If both SSL certificates are valid, the ASP system data exchange server transmits the data file to the partner system.
• The partner system receives the data file and determines whether the ASP system has permission to perform the action requested by querying the partner system database.
• If the ASP system has permission, the partner system queries the database using the user's identity in the partner system. Using this information the partner system performs the query. • When the query has been completed, the partner system generates a data file for transmission to the ASP system data exchange Web server.
The following is an example of how the foregoing could be used to integrate an on-line accounting system and a payroll system. It includes the following steps:
• Integration Agreement
• Enable Integration
• User Authentication for Data Exchange
• Single sign on (optional)
• Data Exchange
The following terms will be used throughout the example:
ASP Application service provider of a Web-based accounting application.
Partner A partner application service provider that is being integrated with the ASP.
ASP System The software/hardware resources used to deliver the Web- based accounting application to users over the Internet.
Payroll System The software/hardware resources used to deliver the Web- based payroll application to users over the Internet.
User An individual subscriber to the payroll system.
Account A grouping of users.
Permissions Refers to the privileges (or rights) a given user or partner has within the ASP. For example, only certain users may be given rights to modify payroll data in the payroll system.
Integration Agreement In order to become a partner, an integration agreement is first signed. This agreement will contain the terms of integration, specific to the partner, for its integration with the ASP. General terms of integration might include: the method of integration, privacy requirements, security requirements, non-competition, service level agreements and customer support arrangements.
In addition, the integration agreement will contain a schedule that describes the permissions that are assigned to the partner for its integration with the ASP. These permissions are partner specific and are assigned on an as needed basis.
In this example the payroll system would be granted only the permissions described in the table below:
Figure imgf000018_0001
Upon completion of the integration agreement, the ASP will add the payroll system to the partner permissions table and enable the appropriate permissions based upon the contents of the integration agreement.
Enable Integration
This example assumes that the payroll system has undertaken the application development and operates the system infrastructure (an example of which is described above) necessary to implement the method described above. Specifically, both the partner system and the ASP system employ the following principal technologies in order to perform integration:
• Secure Socket Layer (SSL) - Secures data transmission between systems.
• Client-side certificates - Enables each system to confirm its identity when initiating communication.
• RSA public/private key cryptography - Used to encrypt data in the authentication token.
As part of the deployment of the integration between the partner system and the ASP, the systems will perform integration testing to ensure they have been configured correctly and perform as expected.
Upon completion of this process, the ASP would allow communication between its servers and the payroll system in a production environment;
User Authentication for Data Exchange
In this example, the user has an account in the payroll system identified as follows:
Account: ChristyCat User: catoi
Password: catering
The user has an account with the ASP identified as follows:
Account: Christy's Catering User: catoi(S>christvcat.com
Password: Christy It can be assumed that the user has the appropriate permissions in the ASP account to perform integration between it and the payroll system.
In order to perform integration between the payroll system and the ASP for their account, the user would perform the following actions.
• The user accesses the payroll system using their Web browser by entering their authentication information on the login Web page.
• Payroll system account: ChristyCat
• Payroll system user: catoi
• Password: catering
The user selects the link that is published in the payroll system for the purpose of performing integration with the ASP. The payroll system generates an authentication token as described above and includes it in the re-direct URL that is transmitted back to the user's browser.
The user is re-directed to the ASP system that then analyzes the authentication token included in the re-direct URL to determine the user's identity in the payroll system. Decrypting the authentication token reveals the user's identity in the payroll system:
• Payroll system account: ChristyCat
• Payroll system user: catoi
• The ASP system then performs a database query to determine whether it recognizes this user. If the ASP is unable to locate an entry in its database that matches the user's identity in the payroll system, it is assumed that the user has not yet performed integration and a Web page is displayed explaining the benefits of the integration and provides the user with the option to login to the ASP system to complete the process. The user selects the login option and enters their authentication information for the ASP system.
• ASP user: catoi(Schristyeat.com
• ASP Password: Christy
Where the user has more than one account in the ASP system, they will also be required to select the specific account that they are integrating with. In this instance:
• ASP account: Christy's Catering.
The ASP system determines whether the user has the appropriate Permissions to enable integration for data exchange between the ASP system and the payroll system.
The ASP system determines whether the payroll system has been enabled for integration by querying the partner permissions table. If the payroll system has an entry in the partner permissions table it is assumed that they have been enabled for integration.
The user is presented with a Web page that informs them that they are performing integration with their account on the payroll system and describes the Permissions that are assigned to the payroll system for the ASP system account. At this time the user is also given the option to enable single sign-on between their accounts, which they choose to accept in this example.
Upon confirming the integration and enabling single sign-on, the ASP system writes the following data to its database:
• Partner Name: payroll system
• Payroll system account: ChristyCat
• Payroll system user: catoi • ASP account: Christy's Catering
• ASP user: catoi@christvcat.com
• Single Sign-on: Enabled
• The user is then logged in to their account in the ASP system.
• The ASP system transmits a confirmation message to the payroll system.
• The integration has been completed for this account.
Single Sign-on
Following the completion of the integration process above and when the single sign-on option has been selected, it is possible for the user to move between the payroll system and the ASP system (and vice-versa) without re-authentication.
• The user accesses the payroll system using their Web browser by entering their authentication information on the login Web page.
• Payroll system account: ChristyCat
• Payroll system user: catoi
• Payroll system Password: catering
• The user selects the link that is published in the payroll system to access the ASP system using single sign-on.
• The user is re-directed to the ASP system that analyzes the authentication token included in the re-direct URL to determine the user's identity in the payroll system.
• Decrypting the authentication token reveals the user's identity in the payroll system to the ASP system: • Payroll system account: ChristyCat
• Payroll system user: catoi
The ASP system then performs a database query to determine whether it recognizes this user. If the ASP system is unable to locate an entry in its database that matches the user's identity in the payroll system, it is assumed that the user has not yet performed integration.
As the user has previously performed integration between the payroll system and the ASP system, the ASP system is able to locate the following user/account mapping information. The ASP system is also able to confirm that single sign-on has previously been enabled.
Partner Name: payroll system Payroll system account: ChristyCat Payroll system user: catoi ASP account: Christy's Catering ASP user: catoi(5)christycat.com Single Sign-on: Enabled
• The ASP system then logs the user in as:
• ASP account: Christy's Catering
ASP user: catoi(5)christvcat.com
XML Data Exchange
Once user authentication for data exchange has been completed and the ASP and the payroll system have an active integration in place, data exchange between the two systems can be performed. In one embodiment, data exchange between the two systems will be performed using XML as described in the ASP data exchange for integrated accounts document and a suitable Document Type Definitions (DTD) or a XML schema such as that described as follows: http://www.smbxml.org
Typically, the first data that is exchanged between the two systems would be to synchronize pre-existing data. In this case, the payroll system will contain employee records, payroll history, earnings/deductions codes, etc.
Data exchange between and the payroll system will be performed as follows:
• The payroll system generates an XML document with a header containing the following basic information:
• Payroll system's account: ChristyCat
• The payroll system opens an HTTPS connection to the ASP system partner XML server.
• The payroll system requests a server-side certificate from the ASP system data exchange Web server to verify its identity. The ASP system data exchange Web server then verifies the identity of the partner by requesting an SSL client-side certificate.
• Upon successful validation of the SSL client-side certificate, the payroll system transmits the XML document to company.
• The ASP system receives the data file and determines whether the payroll system has permission to perform a create paycheck action by querying the partner permission table in its database.
Figure imgf000024_0001
Figure imgf000025_0001
ASP reads the XML document header and performs a query in the partner Authentication Table using the payroll system's account (ChristyCat) to determine if a valid integration for this account has been completed.
Upon determining that the payroll system has permission and that a valid integration has been completed for this account, the ASP system queries the database using the user's identity in the payroll system to determine the ASP system account identity. Using this information the partner data can be written in the ASP system database.
• Partner Name: payroll system
• Payroll system account: ChristyCat
• ASP account: Christy's Catering
Upon determining the ASP system account identity, the paycheck can be created in the ASP system account.
• ASP account: Christy's Catering
• Action: Create Paycheck (e.g., Employee:ooι, Net
Pay=$ιoo)
The ASP system generates a confirmation message and transmits it to the payroll system.
Upon finding the payroll system account "ChristyCat" in the table and determining that this account has been integrated to the ASP "Christy's Catering" account, ASP and routes the XML data accordingly. The ASP generates an XML confirmation message and transmits it to the partner system.

Claims

We Claim:
l. A method of integrating independent secure systems, comprising: authenticating a user in a partner system; redirecting the user to an ASP system; transferring user identity information with the redirect from the partner system to the ASP system; validating the identity information at the ASP system; and authenticating the user identity in the ASP system.
PCT/US2001/041457 2000-08-05 2001-07-27 Systems and methods for integrating independent secure application service providers WO2002013114A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US63460700A 2000-08-05 2000-08-05
US09/634,607 2000-08-05

Publications (1)

Publication Number Publication Date
WO2002013114A1 true WO2002013114A1 (en) 2002-02-14

Family

ID=24544500

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/041457 WO2002013114A1 (en) 2000-08-05 2001-07-27 Systems and methods for integrating independent secure application service providers

Country Status (1)

Country Link
WO (1) WO2002013114A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815665A (en) * 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US6023684A (en) * 1997-10-01 2000-02-08 Security First Technologies, Inc. Three tier financial transaction system with cache memory
US6226752B1 (en) * 1999-05-11 2001-05-01 Sun Microsystems, Inc. Method and apparatus for authenticating users

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815665A (en) * 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US6023684A (en) * 1997-10-01 2000-02-08 Security First Technologies, Inc. Three tier financial transaction system with cache memory
US6226752B1 (en) * 1999-05-11 2001-05-01 Sun Microsystems, Inc. Method and apparatus for authenticating users

Similar Documents

Publication Publication Date Title
US7350229B1 (en) Authentication and authorization mapping for a computer network
US7610390B2 (en) Distributed network identity
US7814536B2 (en) User authentication
US7124203B2 (en) Selective cache flushing in identity and access management systems
US7231661B1 (en) Authorization services with external authentication
US7464162B2 (en) Systems and methods for testing whether access to a resource is authorized based on access information
US7080077B2 (en) Localized access
US7134137B2 (en) Providing data to applications from an access system
US7039714B1 (en) Method of enabling an intermediary server to impersonate a client user&#39;s identity to a plurality of authentication domains
US7249369B2 (en) Post data processing
EP1654852B1 (en) System and method for authenticating clients in a client-server environment
JP4782986B2 (en) Single sign-on on the Internet using public key cryptography
US8117649B2 (en) Distributed hierarchical identity management
US8204999B2 (en) Query string processing
US9038170B2 (en) Logging access system events
US20050120214A1 (en) Systems and methods for enhancing security of communication over a public network
US20040139319A1 (en) Session ticket authentication scheme
US20030074580A1 (en) Access system interface
EP1520217A2 (en) Distributed hierarchical identity management
CA2458257A1 (en) Distributed hierarchical identity management
WO2002013114A1 (en) Systems and methods for integrating independent secure application service providers
Authority Registration Authority Desktop Guide

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP KR US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP