Patent Application
20060294366
1. Field of the Invention
The present invention relates to an improved data processing system and, in particular, to a method and apparatus for multicomputer data transferring. Still more particularly, the present invention provides a method and apparatus for multicomputer communication using cryptography.
2. Description of Related Art
E-commerce web sites and web applications perform transactions over computer networks on behalf of users. In an e-commerce web-based environment, computer systems often implement authentication and/or authorization services as a form of sentry gate prior to allowing access to protected resources within a web site. Security processes that are performed by these authentication and authorization services can be categorized within two stages.
In a first stage, a client and a server establish a secure communication session, such as an SSL (Secure Sockets Layer) session, which may include certificate and key exchanges between a client and a remote server in order to set up a trust relationship and to negotiate a cryptographic key and ciphers to be used for encrypting messages within an SSL session. Many web sites employ the SSL protocol within their authentication services. SSL, or its successor protocol, Transport Layer Security (TLS), is a widely used protocol to establish secure connections from clients to servers in order to prevent message forgery, data tampering, and eavesdropping. The SSL handshake protocol allows a client and server to negotiate an encryption algorithm and cryptographic keys before an application protocol transmits or receives its first byte of data. In this manner, the SSL handshake provides a secure communication session or connection that may be employed by higher network layers for secure communications, including a subsequent transfer of credential information for a subsequent authentication operation or a subsequent authorization operation.
In a second stage, after the secure communication session has been completed, credential information is transferred from the client to the server for a subsequent authentication operation or a subsequent authorization operation. For example, after the SSL session has been established, the server requests the client to provide user credentials, and the client provides user credentials to the server, which then verifies the user credentials in a subsequent authentication or authorization operation. Based on the verification of the user credentials, the server either allows or prevents access to protected resources by the client. There may or may not be any direct interaction with a user of the client during the first or second stage.
The two-stage procedure for establishing a secure communication session and then employing the secure communication session to transfer credential information allows a user or a client to prove its identity and/or its access privileges to an appropriate level of certainty for security purposes. However, it would be advantageous to have a method and a system that supports the establishment of a secure communication session and a subsequent transfer of credential information for a subsequent authentication or authorization operation within a single stage, which would be more efficient than a two-stage procedure.
A method, system, apparatus, and computer program product is presented for is presented for supporting the establishment of a secure communication session within a data processing system. A certificate request command is sent from a server to a client. A certificate command is received at the server from the client in response to the certificate request command, and the certificate command is accompanied by a public key certificate and an attribute certificate that is digitally signed by a private key that is bound to the public key certificate. A secure communication session is established in response to successfully verifying the public key certificate. The attribute certificate contains credential information for an authentication operation or an authorization operation that is performed after establishment of the secure communication session.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, further objectives, and advantages thereof, will be best understood by reference to the following detailed description when read in conjunction with the accompanying drawings, wherein:
In general, the devices that may comprise or relate to the present invention include a wide variety of data processing technology. Therefore, as background, a typical organization of hardware and software components within a distributed data processing system is described prior to describing the present invention in more detail.
With reference now to the figures,
In the depicted example, distributed data processing system 100 may include the Internet with network 101 representing a worldwide collection of networks and gateways that use various protocols to communicate with one another, such as Lightweight Directory Access Protocol (LDAP), Transport Control Protocol/Internet Protocol (TCP/IP), File Transfer Protocol (FTP), Hypertext Transport Protocol (HTTP), Wireless Application Protocol (WAP), etc. Of course, distributed data processing system 100 may also include a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN). For example, server 102 directly supports client 109 and network 110, which incorporates wireless communication links. Network-enabled phone 111 connects to network 110 through wireless link 112, and PDA 113 connects to network 110 through wireless link 114. Phone 111 and PDA 113 can also directly transfer data between themselves across wireless link 115 using an appropriate technology, such as Bluetooth™ wireless technology, to create so-called personal area networks (PAN) or personal ad-hoc networks. In a similar manner, PDA 113 can transfer data to PDA 107 via wireless communication link 116.
The present invention could be implemented on a variety of hardware platforms;
With reference now to
Those of ordinary skill in the art will appreciate that the hardware in
In addition to being able to be implemented on a variety of hardware platforms, the present invention may be implemented in a variety of software environments. A typical operating system may be used to control program execution within each data processing system. For example, one device may run a Unix® operating system, while another device contains a simple Java® runtime environment. A representative computer platform may include a browser, which is a well known software application for accessing hypertext documents in a variety of formats, such as graphic files, word processing files, Extensible Markup Language (XML), Hypertext Markup Language (HTML), Handheld Device Markup Language (HDML), Wireless Markup Language (WML), and various other formats and types of files.
The present invention may be implemented on a variety of hardware and software platforms, as described above with respect to
The descriptions of the figures herein may involve certain actions by either a client device or a user of the client device. One of ordinary skill in the art would understand that responses and/or requests to/from the client are sometimes initiated by a user and at other times are initiated automatically by a client, often on behalf of a user of the client. Hence, when a client or a user of a client is mentioned in the description of the figures, it should be understood that the terms “client” and “user” can be used interchangeably without significantly affecting the meaning of the described processes.
Certain computational tasks may be described hereinbelow as being performed by functional units. A functional unit may be represented by a routine, a subroutine, a process, a subprocess, a procedure, a function, a method, an object-oriented object, a software module, an applet, a plug-in, an ActiveX™ control, a script, or some other component of firmware or software for performing a computational task.
The descriptions of the figures herein may involve an exchange of information between various components, and the exchange of information may be described as being implemented via an exchange of messages, e.g., a request message followed by a response message. It should be noted that, when appropriate, an exchange of information between computational components, which may include a synchronous or synchronous request/response exchange, may be implemented equivalently via a variety of data exchange mechanisms, such as messages, method calls, remote procedure calls, event signaling, or other mechanism.
With reference now to
Enterprise domain 200 supports multiple servers. Application servers 210 support controlled and/or uncontrolled resources through web-based applications or other types of back-end applications, including legacy applications. Reverse proxy server 214, or more simply, proxy server 214, performs a wide range of functions for enterprise domain 200. For example, proxy server 214 may cache web pages in order to mirror the content from an application server. Incoming and outgoing datastreams may be processed by input datastream filter 216 and output datastream filter 218, respectively, in order to perform various processing tasks on incoming requests and outgoing responses in accordance with goals and conditions that are specified within various policies or in accordance with a configuration of deployed software modules.
Session management unit 220 manages session identifiers, cached credentials, or other information with respect to sessions as recognized by proxy server 214. Web-based applications typically utilize various means to prompt users to enter authentication information, often as a username/password combination within an HTML form. In the example that is shown in
The above-noted entities within enterprise domain 200 represent typical entities within many computing environments. However, many enterprise domains have security features for controlling access to protected computational resources. A computational resource may be an application, an object, a document, a web page, a file, an executable code module, or some other computational resource or communication-type resource. A protected or controlled resource is a resource that is only accessible or retrievable if the requesting client or requesting user is authenticated and/or authorized; in some cases, an authenticated user is, by default, an authorized user.
Authentication server 222 may support various authentication mechanisms, such as username/password, X.509 certificates, or secure tokens; multiple authentication servers could be dedicated to specialized authentication methods. Authorization server 224 may employ authorization database 226, which contains information such as access control lists 228, authorization policies 230, information about user groups or roles 232, and information about administrative users within a special administrative group 234. Using this information, authorization server 224 provides indications to proxy server 214 whether a specific request should be allowed to proceed, e.g., whether access to a controlled resource should be granted in response to a request from client 206. It should be noted that the present invention may be implemented in association with a variety of authentication and authorization applications, and the embodiments of the present invention that are depicted herein should not be interpreted as limiting the scope of the present invention with respect to a configuration of authentication and authorization services.
With reference now to
The process is initiated when the user requests a server-side protected resource, such as a web page within the domain “ibm.com” (step 304). The terms “server-side” and “client-side” refer to actions or entities at a server or a client, respectively, within a networked environment. The web browser (or associated application or applet) generates an HTTP request that is sent to the web server that is hosting the domain “ibm.com” (step 306). The terms “request” and “response” should be understood to comprise data formatting that is appropriate for the transfer of information that is involved in a particular operation, such as messages, communication protocol information, or other associated information.
The server determines that it does not have an active session for the client (step 308), so the server requires the user to perform an authentication process by sending the client some type of authentication challenge (step 310). The authentication challenge may be in various formats, such as an HTML form. The user then provides the requested or required information (step 312), such as a user identifier and an associated password, or the client may automatically return certain information, such as a digital certificate.
The authentication response information is sent to the server (step 314), at which point the server authenticates the user or client (step 316), e.g., by retrieving previously submitted registration information and matching the presented authentication information with the user's stored information. Assuming the authentication is successful, an active session is established for the authenticated user or client.
The server then retrieves the requested web page and sends an HTTP response message to the client (step 318). At that point, the user may request another page within “ibm.com” (step 320) within the browser by clicking a hypertext link, and the browser sends another HTTP request message to the server (step 322). At that point, the server recognizes that the user has an active session based on session state information that is maintained by the server (step 324). For example, the server recognizes the appropriate session state information for the requesting user because the user's client returns a session ID within the HTTP Request message. Based on the cached user session information, the server determines that the user has already been authenticated, e.g., by the availability of a copy of the user's credentials; the server can then determine that certain operations, such as an authentication operation, is not required to be performed prior to fulfilling the user's request. The server sends the requested web page back to the client in another HTTP response message (step 326), thereby fulfilling the user's original request for the protected resource.
Although
With reference now to
In a typical second stage 404, after the SSL handshake has been completed, the server requests the client to provide user credentials, and the client provides user credentials to the server. Based on the verification of the user credentials, the server either disconnects the client or continues the secure connection with the client for further data exchanges. There may or may not be any direct interaction with a user of the client during this second stage, particularly with respect to error processing. Thereafter, the client and the server engage in typical transactions 406 during which the server responds to the client's requests to access protected resources.
With reference now to
In this manner, SSL uses a combination of public-key encryption and symmetric-key encryption. The SSL handshake allows the server to authenticate itself to the client by using public-key techniques. It then allows the client and server to cooperate in creating symmetric key/keys that is/are used for encryption, decryption, and tamper detection during the SSL session that follows. Public-key encryption provides more effective authentication techniques, which is desirable for generating the session key, while symmetric-key encryption is faster than public-key encryption, which is desirable during the transactions in which a client is requesting access to protected resources and a server is responding to those requests.
The process commences when the client sends a CLIENT_HELLO command to the server (step 412). The CLIENT_HELLO command includes: the highest SSL and TLS version supported by the client (it may be assumed that the client supports earlier versions in a backward-compatible manner); ciphers supported by the client and listed in the order of preference; data compression methods that are supported by the client; the session ID, which is equal to zero if the client is starting a new SSL session; random data that is generated by the client for use in the key generation process. The cipher suites are a list of encryption algorithms the client supports, such as RSA with 3DES or RSA with IDEA. The client provides a complete list of the ciphers it is able or willing to support so that the server may choose one. The list of compression algorithms is meant to function much like the list of cipher suites in which the client provides a list of what it can do and the server is meant to pick one. The session ID can be used to indicate the client wants to resume a previously negotiated session; the advantage to this is time is saved by not negotiating a new session key, although the client will usually send a session ID of zero to indicate a new session must be negotiated. The random data, known as a “nonce”, is one of the variables that is used in generating the session key and also prevents replay attacks.
In response, the server sends multiple commands. The server sends a SERVER_HELLO command to the client (step 414). The SERVER_HELLO command includes: the SSL or TLS version that will be used for the SSL session; the cipher that will be used for the SSL session; the data compression method that will be used for the SSL session; the session ID for the SSL session; random data that is generated by the server for use in the key generation process. The random data or nonce is a random value generated by the server that is used in the same fashion as the client's nonce. The session ID, cipher suite, and compression method are all values chosen by the server and imposed onto the client; the client has previously indicated the values that it can support, and the server chooses among the available options. If the server is not willing or able to support the client for whatever reason, the server aborts the handshake and closes the connection.
The server also sends a CERTIFICATE command to the client (step 416). The CERTIFICATE command is accompanied by the server's public key certificate and, optionally, a chain of digital certificates beginning with the digital certificate of the certificate authority (CA) that issued the server's public key certificate. In addition, the server sends a CERTIFICATE_REQUEST command to the client (step 418) to request the client certificate. The CERTIFICATE_REQUEST command contains the names of the certificate authorities that the server trusts so that the client can provide a certificate signed by one of those certificate authorities. The server then sends the SERVER_DONE command to the client (step 420). The SERVER_DONE command indicates that the server has completed this phase of the SSL handshake.
Prior to responding to the server's commands, the client may perform several verification steps. For example, after the client has received the server's certificate or certificate chain, the client may take a few steps to validate the certificate. The client can check the subject name on the certificate and compare it to the domain name that has been used to connect to the server. If the names do not match, the client can abort the handshake. The client can also check the valid dates on the certificate to ensure that the certificate has not expired. The client can also attempt to validate the digital signature on the server's certificate, assuming that the client trusts the issuer. If the client cannot validate the certificate, the client can abort the handshake. In some cases, the client may allow the user of the client to determine whether or not to abort the handshake by informing the user that an error has been detected and then allowing the user to choose whether to continue.
In response to receiving the server's commands, the client sends multiple commands. The client sends a CERTIFICATE command to the server (step 422), which is accompanied by the client's public key certificate and, optionally, a chain of digital certificates beginning with the digital certificate of the certificate authority that issued the client's public key certificate. The client also sends a CLIENT_KEY_EXCHANGE command to the server (step 424). This CLIENT_KEY_EXCHANGE command contains the premaster secret (PreMasterSecret) that was created by the client. The premaster secret is protected by encrypting it using the server's public key from the server's digital certificate; if the server is the legitimate owner of the digital certificate that it previously sent, then only the server should possess the private key that is necessary to decrypt the premaster secret. Both the client and the server separately generate the symmetric encryption key/keys using the premaster secret and the random data that accompanies the SERVER_HELLO and CLIENT_HELLO commands. If the server is actually an attacker posing as the owner of the digital certificate, it will be unable to decrypt the premaster secret, which means it will be unable to derive the session key; without the session key, the server is unable to complete the handshake because of the validation step associated with the FINISHED command, which is described hereinbelow.
The client also sends a CERTIFICATE_VERIFY command to the server (step 426). The CERTIFICATE_VERIFY command includes a digest of the SSL handshake messages that have been signed using the client's private key. The server calculates its own digest and uses the client's public key, which has been obtained from the client's digital certificate, to verify the digest sent by the client, hereby completing an authentication procedure to verify that the client possesses the corresponding private key for the public key from the client's digital certificate. The client also sends a CHANGE_CIPHER_SPEC command to the server (step 428). The CHANGE_CIPHER_SPEC command indicates that the contents of subsequent SSL record data sent by the client to the server during the SSL session will be encrypted; SSL record headers, however, are not encrypted. The client concludes by sending the FINISHED command to the server (step 430). The FINISHED command is encrypted with the session key and includes a digest of all the SSL handshake commands that have flowed between the client and the server up to this point. This command is sent to validate that none of the commands sent previously, which flow between the client and the server unencrypted, were altered in transmission, e.g., by a malicious user employing a so-called man-in-the-middle or replay attack. The nonce values sent in the CLIENT_HELLO and SERVER_HELLO messages help to ensure that the handshake messages from different SSL sessions are different, even if the sessions are between the same client and server. Without the nonce values, it may be possible under certain circumstances for an attacker to capture the handshake messages between the client and server and replay them later in an attempt to spoof one side.
In response to the client's commands, the server then sends a CHANGE_CIPHER_SPEC command to the client (step 432). This command indicates that all subsequent data sent by the server during the SSL session will be encrypted. The server concludes by sending a FINISHED command to the client (step 434), which is encrypted with the session key and includes a digest of all the SSL handshake commands that have flowed between the server and the client up to this point; the FINISHED command acts as a notification message that the SSL session has been successfully established, thereby concluding the typical SSL handshake process.
Given the background information that is discussed with respect to
With reference now to
More specifically,
With reference now to
However, whereas
Step 462 differs from step 422 because the client's digital certificate (and, optionally, digital certificate chain) at step 462 is additionally accompanied by an attribute certificate that has been issued in accordance with the client's digital certificate. The attribute certificate contains credentials for the client/user for performing an additional authentication or authorization operation, e.g., above the SSL layer within the application layer, thereby transferring additional credentials within the enhanced SSL handshake such that a subsequent transfer of the credentials is unnecessary, as explained in more detail hereinbelow.
The attribute certificate can be considered to be part of the client's certificate chain. The attribute certificate can be verified using the client's public key in the client's digital certificate since the client's private key would have been used to sign the attribute certificate. In a well-known manner of verifying a certificate chain, the verification procedure may also involve usage of other digital certificates within the client's certificate chain if transferred and/or necessary for the level of security that is implemented in the verification procedure.
With reference now to
Referring now to
With reference now to
Client 602 supports client-based application login module 604, which contains attribute certificate generation module 606. The form factor of client-based application login module 604 may vary in different implementations of the present invention. For example, client-based application login module 604 may be statically contained within a stand-alone application or an administrative utility, or client-based application login module 604 may be dynamically downloaded from a server. Client-based application login module 604 may be a Java™ Authentication and Authorization Service (JAAS) module; JAAS is a package that enables services to authenticate and/or enforce access controls upon users. In any case, various security measures may be required to operate client-based application login module 604, e.g., administrative personnel privileges or specific privileges that are possessed by a given user.
At an appropriate time, a user of the client operates client-based application login module 604, and client-based application login module 604 obtains credential information that forms the basis of the user's credentials; for example, the client may be configured to retrieve the credential information from a particular directory or database, or the user might be prompted to enter a source location or to perform some other input operation. The format of the credential information may vary for many different types of authentication/authorization operations. For example, the user might be prompted to enter a username-password value pair, or the user may be prompted to perform an action that allows biometric data to be obtained from the user. Alternatively, the credentials may be represented by a Kerberos ticket that is retrieved from an appropriate database, such as digital certificate database/keystore 608, which may be a secure datastore in which access is protected in some manner, e.g., by a master password or an additional biometric procedure.
Client-based application login module 604 retrieves the credential information and generates attribute certificate 610 that contains credential information 612. Additional information may also be bundled into attribute certificate 610, such as the domain name for which the attribute certificate is intended to be used. As part of the issuance process, attribute certificate 610 is signed using the appropriate private key, e.g., private key 616 that corresponds to, i.e. that is associated with or that is bound to, public key certificate 614. Attribute certificate 610 may be stored within an appropriate database until a later point in time when it is needed, such as certificate database/keystore 608, which contains other certificates in the associated user/client certificate chain, e.g., user/client certificate 614 and CA certificate 618, which is the public key certificate of the certificate authority that issued user/client certificate 614.
In effect, client 602 is acting as a certificate authority to issue attribute certificate 610, which contains attribute information to be associated with, i.e. attributed to, an entity, i.e. the client or the user, whose identity is bound to the private key and the corresponding digital certificate. Whereas a public key certificate provides a binding between an identity and a public key, an attribute certificate provides a binding between an identity and attribute information for that identity. The digital signature on the attribute certificate using the private key ties the attribute certificate to the public key certificate that corresponds to the private key.
The usage of generalized attribute certificates is well-known. The present invention is compatible with a variety of formats for public key certificates and attribute certificates. In an exemplary embodiment, the public key certificates may be formatted as described in Housley et al., “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 3280 (Request for Comments 3280), Internet Engineering Task Force (IETF), April 2002. Likewise, the attribute certificates may be formatted as described in Farrell et al., “An Internet Attribute Certificate Profile for Authorization”, RFC 3281, IETF, April 2002.
At some later point in time, client 602 employs enhanced SSL protocol client module 620 to interact with server 622 to perform an enhanced SSL handshake in accordance with the present invention; server 622 supports corresponding enhanced SSL protocol server module 624 for performing its actions with respect to the enhanced SSL handshake. In response to a CERTIFICATE_REQUEST command from server 622, client 602 sends certificate chain 626 to server 622. Certificate chain 622 contains user/client public key certificate 614 and attribute certificate 610, and, optionally, additional certificates that form the certificate chain for certificate 614. After receiving certificate chain 626, server 622 can verify certificate 614 and the credentials within attribute certificate 610. Certificate chain 626 or portions thereof, such as the credential information that is embedded within the attribute certificate or the entire attribute certificate, may be encrypted with the server's public key by client 602 prior to transmission in order to protect the confidentiality of credential information 612.
With reference now to
The attribute certificate is then signed with the private key from the appropriate public key certificate (step 706). The attribute certificate is then stored in an appropriate datastore for subsequent use (step 708), preferably within a local database at the client, and the process is concluded.
With reference now to
In the example that is illustrated in
With reference now to
The process commences when the server receives an attribute certificate and public key certificate in a CERTIFICATE command from the client (step 902). The server attempts to verify the public key certificate (step 904), and if successful, the server also attempts to verify the associated attribute certificate (step 906); if the public key certificate and the associated attribute certificate are both successfully verified, then the enhanced SSL handshake is continued in order to establish an SSL session (step 908).
It should be noted that the present invention may be implemented such that the public key certificate and the attribute certificate are not necessarily verified by the same software module at the server nor within the same network layer that may be ascribed to the verifying software modules. In the example that is shown in
Similarly, it should be noted that the present invention may be implemented such that the attribute certificate and its contained credential information are not necessarily verified by the same software module at the server nor within the same network layer that may be ascribed to the verifying software modules. In the example that is shown in
A preferred embodiment is shown in
In an alternative embodiment, though, the present invention may be implemented such that the attribute certificate and its contained credential information are verified while the SSL session is being established in accordance with the enhanced SSL handshake protocol. In this alternative embodiment, the enhanced SSL handshake may experience a fatal error if the credential information also fails to be verified; in other words, the public key certificate, the attribute certificate, and its contained credential information would be required to be verified to establish an SSL session in accordance with this alternative implementation of the enhanced SSL handshake protocol.
In yet another alternative embodiment, rather than returning only the credential information to the module that has requested the establishment of the SSL session, the entire attribute certificate could be returned, thereby providing the attribute certificate along with the credential information that is embedded within the attribute certificate.
Decryption operations can be performed as necessary. If the credential information was previously encrypted before being embedded within the attribute certificate, e.g., by the client using the server's public key, then the credential information is decrypted at the server, e.g., with the server's private key. If the entire attribute certificate and/or the entire certificate chain was previously encrypted by the client prior to transmission to the server, then the entire attribute certificate and/or the entire certificate chain would be decrypted at the server at appropriate points within the process that is illustrated in
The present invention may also be implemented to provide error handling with respect to a failure to establish an SSL session in accordance with the enhanced SSL session. If either the public key certificate or the attribute certificate fails to be verified, then a fatal error is generated (step 914), which terminates the enhanced SSL handshake. An error message may be sent by the server to the client (step 916). An error may be returned to the module that had requested the establishment of the SSL session (step 918). In any case in which a fatal error is generated, the SSL session is not established, and the process is concluded.
In the example that is shown in
It should be noted that, in the exemplary embodiments of the present invention that are illustrated with respect to
As noted above, in some cases, a user and a client device are recognized in the art as being entities that are sometimes interchangeable with respect to a perspective of the beneficiary of operations that are performed within data processing system. A natural person, such as the user of a client device, may be the Subject of a digital certificate, i.e. an entity whose identity is bound to a public key certificate as the named Subject of the public key certificate. However, a device, such as the client device, may also be the Subject whose identity is bound to a public key certificate. If the user of a client device is the entity with which the attribute information is associated, then the user's public key certificate is used to sign the attribute certificate; if the client device is the entity with which the attribute information is associated, then the client's public key certificate is used to sign the attribute certificate. In this manner, depending on the security operations that are performed by a server on behalf of a request from a client, which may be executing on behalf of a user or natural person, the present invention supports an enhanced SSL handshake in which credentials are transferred from a client to a server such that the credentials may be bound to, i.e. are associated with or are possessed by, a user or a client device.
It should also be noted that, in the exemplary embodiments of the present invention that are described above, only one attribute certificate is transferred from a client to a server. However, as noted above, attribute certificates may be created specifically for certain purposes, e.g., by placing the domain name of the intended recipient within the attribute certificate when it is created. Hence, in an alternative embodiment, multiple attribute certificates may be transferred from a client to a server during an enhanced SSL handshake; for example, multiple attribute certificates could be bundled together with the certificate chain that is transmitted. Each of the multiple attribute certificates would have been signed by the private key of the same public key certificate that is also transferred within the enhanced SSL handshake, and the client would be able to identify which attribute certificates of many available attribute certificates are required to be sent to a particular server by using the indicating information within the attribute certificates, such as the domain names. In this manner, the credential requirements of multiple server-side applications or operations can be fulfilled using the single stage authentication/authorization procedure that is embedded within the enhanced SSL handshake of the present invention. For example, if a client or a user needs to be logged into multiple server applications in order to effectively perform a set of tasks, then the credential information that is required by each of those multiple server applications could be transferred within the enhanced SSL handshake.
Alternatively, when an attribute certificate is generated, multiple sets of credential information may be bundled together within a single attribute certificate; the client and the server would possess corresponding logic for embedding or extracting the multiple sets of credential information. In this manner, a single attribute certificate could be used to transfer multiple sets of credentials, yet the credential needs of multiple server-side applications or operations can be fulfilled using the single stage procedure that is provided by the enhanced SSL handshake of the present invention.
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of instructions in a computer readable medium and a variety of other forms, regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include media such as EPROM, ROM, tape, paper, floppy disc, hard disk drive, RAM, and CD-ROMs and transmission-type media, such as digital and analog communications links.
A method is generally conceived to be a self-consistent sequence of steps leading to a desired result. These steps require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, parameters, items, elements, objects, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these terms and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
The description of the present invention has been presented for purposes of illustration but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments were chosen to explain the principles of the invention and its practical applications and to enable others of ordinary skill in the art to understand the invention in order to implement various embodiments with various modifications as might be suited to other contemplated uses.
