EP1264463A2 - Mecanisme d'authentification base sur le web et possedant une procedure d'ouverture unique - Google Patents
Mecanisme d'authentification base sur le web et possedant une procedure d'ouverture uniqueInfo
- Publication number
- EP1264463A2 EP1264463A2 EP01913338A EP01913338A EP1264463A2 EP 1264463 A2 EP1264463 A2 EP 1264463A2 EP 01913338 A EP01913338 A EP 01913338A EP 01913338 A EP01913338 A EP 01913338A EP 1264463 A2 EP1264463 A2 EP 1264463A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- user
- service
- token
- connection
- authentication
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
Definitions
- the present invention relates to authentication mechanisms for computer networks, and more specifically, relates to single sign-on authentication mechanisms for enforcing authorized access to a plurality of services distributed over a network (for example, the Internet).
- a network for example, the Internet
- server 185 offering a service passes authentication request 190 received from user 187 to authenticating agent 189.
- authenticating agent 189 if it successfully authenticates the user, transmits data 192 to server 185 authorizing the provision of the service to user 187.
- service 185 provides service 194 to user 187. In this way, authentication can be performed for a plurality of servers offering services through a single authenticating agent, and hence a single sign-on mechanism.
- the authenticating procedures are not entirely divorced from the service server.
- the service server needs to have functionality allowing it to recognize a user's request for authentication and forward this request to the authenticating agent. Further, the service server has to have functionality allowing it to recognize a transmission from the authenticating server authorizing or refusing to authorize the user's request.
- each new service added to the plurality of services secured by the authenticating agent requires installation and maintenance of this functionality.
- a service server has to initiate an authentication negotiation with the authentication agent anew each time the user attempts to use a service on a new server from the plurality of servers during a session.
- the fact that the user has already been successfully authenticated during a session is of no benefit at all for verifying the authorization of a user to access a new service during the session; the new service must forward a new user request for authentication to the authentication agent and wait for a response.
- a single sign-on mechanism for accessing a plurality of services distributed over a network is needed in which authentication-related functionality is separated from the services, and in which authentication need not be renegotiated for access to a new service from the plurality of services during a session.
- a request is received from a user for authorization to access a service.
- a token corresponding to the service is transmitted to the user.
- the token corresponding to the service is received from the user.
- whether the user is authorized to receive the service is determined, based on the token.
- the user is connected to the service, if the user is authorized to use the service.
- Figure la is a block diagram of a system in accordance with a prior, known method.
- Figure lb is a block diagram of a system in accordance with the present invention.
- Figure lc is a block diagram of a section of a system in accordance with an embodiment of the present invention.
- Figure 2 illustrates a flow diagram of a first embodiment of the present invention
- Figure 3 illustrates a flow diagram of a second embodiment of the present invention.
- FIG. 4 is a block diagram of a system in accordance with the second embodiment. DETAILED DESCRIPTION OF THE INVENTION
- Embodiments of the present invention disclose a single sign-on method and system for accessing a plurality of services distributed over a network in which authentication-related functionality is separated from the services, and in which authentication need not be renegotiated for access to a new service from the plurality of services during a session. Additional benefits accruing from embodiments of the invention include notification of the plurality of services when a user has terminated a session, and the use of secure, short-lived authentication tokens to verify a user's identity for subsequent access to the plurality of services.
- Figure lb shows a system in accordance with embodiments of the present invention.
- Figure lb also shows paths of data flows in the system that are depicted with dotted lines labeled with numbers in braces (the dotted lines may signify network connections between the entities at the end points of the dotted lines).
- user 130 is connected to Internet 10.
- Internet 10 includes a plurality of resources in a network, such as servers 30, 40, 50 and Cloud 20.
- Cloud 20 comprises a collection of servers, for example servers 60, 70, 80 and 90, that offer a plurality of services for authorized Cloud users.
- service 95 which is located on server 90, is one of the services offered on Cloud 20.
- a “remote” connection is said to exist between two entities, if the entities are connected through one or more network connections. If two connected entities are not connected through at least one network connection, a "local” connection may be said to exist between the two entities. An entity connected to another entity by a remote connection may be said to be “remote” from the other entity.
- Gateway 100 is responsible for registering users of Cloud 20 and authenticating registered users for connection to services offered on Cloud 20.
- Gateway 100 is shown to be connected to user 130, the Internet 10 and Cloud 20.
- Gateway 100 may be connected to a plurality of users and/or a plurality of networks.
- Gateway 100 includes a registration proxy 1 15, an authentication proxy 120 and a data proxy 1 10.
- Registration proxy 1 15, authentication proxy 120 and data proxy 1 10 are logical units that may be implemented in hardware or software. In particular, any or all of the functionality within Gateway 100, including that of authentication proxy 120, data proxy 1 10 and registration proxy 1 15, may be spread over one or more physical units.
- data proxy 1 10 may comprise a plurality of logical units, each located on a server at a different node within a network, e.g., the Internet, or on the same unit.
- a user of Cloud 20 initially registers with registration proxy 1 15 in order to use the web-based authentication mechanism for access to services available on Cloud 20.
- the user begins the registration procedure by connecting to the registration proxy.
- the user may use a standard web browser to connect to registration proxy 1 15 using the Uniform Resource Locator ("URL") of Gateway 100 or registration proxy 1 15.
- the connection may be made using the Secure Sockets Layer (“SSL”) protocol for ensuring data security during the registration procedure.
- SSL Secure Sockets Layer
- this connection may be made through any secure communications protocol, e.g., the Transport Layer Security ("TLS") protocol (e.g., RFC 2246).
- TLS Transport Layer Security
- a secure communications protocol allows communication in a way that is designed to prevent eavesdropping, tampering, or message forgery.
- the user may register by choosing and communicating to registration proxy 1 15 credentials that may be used for authentication to Cloud 20. For example, the user may choose a user name and a password, or a user name and a digital certificate, e.g., a X.509 standard certificate, as credentials for authentication purposes. The user must choose at least one credential to complete the registration procedure.
- the user may additionally be required to specify billing information, including a credit card number or a bank account number, for use in paying for Cloud services.
- billing information including a credit card number or a bank account number, for use in paying for Cloud services.
- the dotted line labeled "(1)" in Figure lb between user 130 and registration proxy 1 15 indicates the data flow in connection with the registration to Cloud 20. This connection may be made through Internet 10. Once the registration process has been completed, this connection may be dropped.
- user 130 may access one or more services on Cloud 20. However, before user 130 can be connected to a Cloud service, he may be required to authenticate his identity to Gateway 100. A user that authenticates his identity is authorized to access one or more services on Cloud 20. User 130 authenticates his identity by connecting to authentication proxy 120 and presenting his authentication credentials. User 130 may establish a connection to authentication proxy 120 by specifying the URL of Gateway 100, authentication proxy 120, or any service within the Cloud to his web browser. User 130 may then specify his user name and password, or he may specify his user name and present a digital certificate, in response to a prompt from authentication proxy 120. The connection between authentication proxy 120 and user 130 may be made using the SSL protocol, or any other secure communications protocol, for data security purposes.
- the dotted line labeled "(2)" in Figure lb between user 130 and authentication proxy 120 indicates data flow during authentication (as well as the flow of tokens from authentication proxy 120 to user 130, which will be discussed shortly).
- This connection which may be said to establish a channel between user 130 and authentication proxy 120, may be made through Internet 10.
- a network control connection For example, after user 130 successfully authenticates his identity, authentication proxy 120 may send user 130's browser a web page with a JavaScript program that contains a unique URL, and then terminate the connection to user 130. The JavaScript program received by user 130's browser may then reconnect to authentication proxy 120 through the unique URL.
- This connection may in particular be a mutually authenticated SSL connection, or a connection using any other secure communications protocol.
- authentication proxy 120 After user 130 authenticates his identity to authentication proxy 120, he may receive services on Cloud 20 for which he is authorized without any other authentication procedures that are apparent to user 130 (i.e., transparently), as long as the network control connection between authentication proxy 120 and user 130 remains intact.
- authentication proxy 120 may store user 130's identification information in an authenticated connections table ("ACT'). User 130's identification information may remain in the ACT until the connection between user 130 and authentication proxy 120 is severed.
- Authentication proxy 120 may share the list of active Cloud users stored in the ACT with data proxy 110.
- authentication proxy 120 may continually transmit a plurality of tokens to user 130 over the connection.
- Each token may contain information specific to one or more services, for example, identification numbers of the services to which the token corresponds. Additionally, each token transmitted to user 130 may include identification information specific to user 130 and a time value indicating the expiration time of the token.
- each token may be encrypted by authentication proxy 120 using a secret key that is generated by authentication proxy 120.
- Authentication proxy 120 may also store a unique identifier corresponding to the secret key in the ACT. Authentication proxy 120 may also place the unique identifier in the token that is encrypted by the corresponding key.
- each token may be embedded in a http-protocol cookie.
- a list of registered users together with the services the registered users are authorized to access may be stored in a memory in Gateway 100.
- a user may be sent only tokens corresponding to the services for which he is registered.
- authentication proxy 120 may transmit a token that is substantially similar to the token about to expire, but having a new expiration time value, and/or encrypted with a different key.
- the length of the interval of time in which a token is valid may be predetermined and equal to a multiple of the lifetime of the encryption key. In other embodiments, the length of time in which a token is valid may be generated randomly.
- a token may be invalidated by removing the unique identifier corresponding to the key used for encrypting the token from the ACT. This has the effect of invalidating all tokens corresponding to that key in the system. Additionally, when user 130 terminates a work session by, for example, closing the browser, the browser may remove all cookies containing the tokens stored in user 130's browser. Furthermore, tokens may be invalidated upon the system comprising Gateway 100 determining that a security event indicating a possible breach or unauthorized access has occurred. Gateway 100 may invalidate tokens, for example, by simply changing keys and distributing the new keys to data proxy 1 10, which effectively logs off all users. Alternatively, if keys are issued on a per user basis, Gateway 100 may log off one or more users individually.
- the interruption of the network connection between authentication proxy 120 and user 130 may cause authentication proxy 120 to remove user 130's identification information from the ACT.
- authentication proxy 120 treats any token received from a user whose identification information does not appear in the ACT as being invalid.
- a user's tokens are invalidated upon removal of the user's identification information from the ACT.
- user 130 may attempt to connect to a Cloud service by specifying the URL of the service on user 130's browser. Alternatively, user 130 may be automatically redirected to the desired service. The domain name entered by user 130 in his browser may cause the browser to detect that the requested service is protected by Gateway 100.
- the browser may then connect to data proxy 1 10 and transmit the cookie containing the token (or tokens) corresponding to the service requested by user 130.
- the connection to data proxy 1 10 (forming a second channel, in addition to the first channel between user 130 and authentication proxy 120) may be made using the SSL protocol, or any other secure communications protocol, to assure data security.
- Data proxy 110 may extract an encrypted token (or tokens) from the cookie, decrypt the token (or tokens), verify its validity and extract the identification information contained within.
- data proxy 1 10 may extract the unique key identifier corresponding to the key used to encrypt the token.
- Data proxy 1 10 may verify that connection of user 130 to the requested service is authorized by checking the ACT for a match with the extracted unique key identifier.
- data proxy 110 may check that the extracted identification information matches one of the users listed in the ACT. Matches between information stored in the token and information stored in the ACT may indicate the validity of the token.
- the dotted line labeled "(3)" in Figure lb between user 130 and data proxy 1 10 indicates the data flow for transmission of tokens from user 130 and the verification of their validity at data proxy 1 10. This connection may be made through Internet 10.
- data proxy 110 may initiate a proxy connection to the service requested by user 130 using the SSL protocol, or any other secure communications protocol, on user 130's behalf.
- user 130 may begin to use the requested service through its connection to data proxy 110 and through data proxy 1 10's connection to the service, after completion of the procedure as described above.
- the dotted line labeled "(4)" in Figure lb between service 95 and data proxy 1 10 indicates the data flow over the connection between user 130 and data proxy 110.
- Figure lc shows the transmission of cookies among authentication proxy 120, user 130 and data proxy 110 over Internet 10, in one embodiment of the present invention.
- user 130 After user 130 authenticates his identity, he receives a stream of tokens through a first connection (i.e. a first channel) from authentication proxy 120, wherein each token corresponds to one or more services on Cloud 20.
- a first connection i.e. a first channel
- user 130 may receive cookies 145 and 150.
- his browser will be redirected and connect to data proxy 1 10 through a second connection (i.e. a second channel).
- User 130's browser will then transmit the cookie or cookies corresponding to the requested service to data proxy 1 10 through the second connection.
- user 130's browser may transmit cookies 160 and 175 to data proxy 1 10.
- the disclosed system provides authentication functionality allowing authorized users to access services over a network.
- the system comprises a gateway that authenticates users for access to the services.
- all of the authentication functionality of the system exists only on the gateway. For example, a new service added to the services for which the gateway performs authentication functionality does not require any augmentation for proper functioning of the authentication functionality of the system.
- An authentication token may be passed to the user in a the "Set-Cookie” field of a Hypertext Transfer Protocol ("http") header.
- http Hypertext Transfer Protocol
- cookie-name the name of the cookie. This value is equal to GeoPlexIdSecure for the cookies used over the secure connections (https). For regular http connections this name is set to GeoPlexId.
- Wdy - is the day of the week (for example, Mon or Tues); DD is a two-digit representation of the day of the month; Mon is a three- letter abbreviation for the month (for example, Jan or Feb); YY is the last two digits of the year; HH:MM:SS are hours, minutes, and seconds, respectively.
- the authentication proxy may set this value to be the current time plus the cookie validity period.
- the expiration of a cookie may be enforced by the authentication proxy.
- the presence of an expiration value on the user's side sets the guidelines for the use of the cookie for the user's browser.
- SECURE - this specifier denotes authentication tokens that are sent only over secure connections.
- the authentication proxy sets this attribute only for cookies destined to SSL protected domains (https).
- https SSL protected domains
- the presence of this value on the users' s side sets the guidelines for the use of the cookie for the user's browser.
- Cookie-Value - base-64 encoded authentication token base-64 - encoded struct ⁇ uint ⁇ TokenMagic [4]; uint32 Version; uint32 HashType; opaque HashValue[20]; uint32 WorkKeyld; uint32 CipherType; uint32 ContentLength; encrypted struct ⁇ opaque TokenContent[AuthenticationToken. ContentLength]; select (CipherType) ⁇ case block: uint8 padding[Padding.padding_length]; uint ⁇ padding_length; ⁇ Padding;
- TokenMagic is a four-byte value that allows the quick recognition of the structure of AuthenticationToken:
- TokenMagic ⁇ 'G', ⁇ O', 'X' ⁇ ;
- HashType the identifier of a hash algorithm used to compute the cryptographic checksum stored in the HashValue field, enum ⁇ HashType_md5, HashType_shal
- HashType is the hash value of the following data fields in the cryptographic token:
- the hash value is stored in first 16 bytes of the HashValue field.
- the hash value for the shal hash function is 20 bytes long.
- CipherType the identifier of a cipher used to encrypt the token, enum ⁇ CipherType_des, CipherType_3des,
- CipherType_rc4 CipherType
- Token-Type the identifier of the token, enum ⁇ TokenType_http ⁇ TokenType;
- TokenContent the encrypted token, struct ⁇ opaque random[8]; uint32 GeoPlexUserid; TokenType type; select (type) ⁇ case http: uint32 Secure; uint32 DomainLength; uint8 Domain[TokenContent.DomainLength]; ⁇ TokenContent; ⁇ GeoTokenContent;
- Random - eight random bytes help to prevent a known plain text attack when a stream cipher such as RC4 is used.
- GeoPlexUserid - user id of the token owner
- Padding - padding of the TokenContent field to be a multiple of eight. This field is present only when a block cipher was used to encrypt the token.
- authentication tokens have a limited validity period, which is enforced by the authentication proxy.
- the authentication proxy updates the tokens issued to all active users by sending a new set of http cookies.
- Each updated set of tokens issued to a user is encrypted with a key different from the one used to encrypt the previous set of tokens. This measure prevents replay attacks against the authentication proxy when a malicious user may send a stolen token to gain access to a protected resource. Immediate replay attacks are made impossible since fresh tokens are delivered over a SSL protocol-protected (or other secure communications protocol- protected) network connection.
- the authentication proxy updates its pool of random data, called the master secret, every T minutes. When a master secret object is created, it is assigned a handle that uniquely identifies the object. The authentication proxy keeps one preceding instance of the master secret so that the tokens issued under the older master secret are still valid for some time.
- the update period T is a configurable parameter ("KeyGenerationlnterval") set by the System Administrator.
- Each newly generated master secret object is marshaled by the authentication proxy and is saved in the ACT.
- the authentication proxy stores the two most recent marshaled master secret objects in the ACT.
- a new marshaled master secret object replaces the older, saved, marshaled master secret object in the ACT.
- authentication proxy 120 periodically and automatically sends tokens to user 130 over the network control connection.
- authentication proxy 120 automatically sends user 130 tokens encrypted with new keys after an update of the master secret.
- the gateway "pushes" updated tokens to the user.
- This embodiment may be implemented, for example, where user 130's browser supports multi-part data types defined in the MIME 1.0 specification.
- authentication proxy may be implemented, for example, where user 130's browser supports multi-part data types defined in the MIME 1.0 specification.
- authentication proxy may be implemented, for example, where user 130's browser supports multi-part data types defined in the MIME 1.0 specification.
- authentication proxy may be implemented, for example, where user 130's browser supports multi-part data types defined in the MIME 1.0 specification.
- authentication proxy 120 will send user 130 a meta http tag after user 130 reconnects to the authentication proxy through the network control connection.
- the meta http tag causes user 130's browser to periodically and automatically send a request signal to authentication proxy 120 through the network control connection.
- authentication proxy 120 sends tokens encrypted with new keys to user 130, as long as authentication proxy 120 has received the last scheduled request signal, and/or has received at least one request signal during a predetermined amount of time.
- the user "pulls" updated tokens from the gateway.
- This embodiment may be implemented, for example, where user 130's browser does not support multi-part MIME data types.
- FIG. 2 shows one embodiment of the present invention.
- a request from a user for authorization to access a service is received.
- the user may request authorization to access services on Cloud 20, for example, by attempting to log on through authentication proxy 120 for access to services on Cloud 20.
- User 130 may make such a request by directing his browser to a web site corresponding to authentication proxy 120.
- a token corresponding to a service is transmitted to the user.
- authentication proxy 120 may transmit a token corresponding to a Cloud service after user 130 properly authenticates himself to authentication proxy 120 (or logs on) at step 200. Additionally, tokens corresponding to other Cloud services may also be transmitted to user 130.
- the token corresponding to the service is received from the user.
- user 130 to access the service, may direct his browser to a web site corresponding to the service, e.g., the web site "geoplex.service.com.”
- the browser may then be redirected to the web address of data proxy 1 10 and transmit the cookie containing the token corresponding to the service to data proxy 1 10.
- the cookie, and hence the token may then be received at data proxy 1 10.
- a determination of whether the user is authorized to receive the service is made.
- data proxy 1 10 may extract and decrypt the token embedded in the received cookie.
- Data proxy 110 may then determine whether the received cookie authorizes the user to receive the requested service.
- data proxy 1 10 may extract the user identification information in the token and compare it to the user identification list contained in the ACT. If the user identification information does not match any of the users in the ACT, then the user will not be connected to the requested service. Further, data proxy 110 may extract the expiration time of the token and compare it to the current time. If data proxy 110 determines that the token has expired, then the user will not be connected to the requested service.
- the user may be connected to the requested service and may begin using the requested service at step 250.
- FIG. 3 shows another embodiment of the present invention.
- This embodiment illustrates the interaction of Alice, a registered Cloud user, with the Gateway.
- Alice directs her browser to the authentication web site (for example, the web site of the Gateway) that is managed by the authentication proxy.
- the authentication web site for example, the web site of the Gateway
- Alice may enter the following command in her browser: "https://www.login.domain/login.html”. This will establish a connection between Alice's browser and the authentication proxy that uses the Secure Sockets Layer protocol for data security.
- the authentication proxy presents Alice with a form that asks for her login name and, possibly a password.
- Alice provides her login name in the form. She also types in the login password if she uses the password- based authentication method. If she uses certificate-based authentication, she does not need to type her password and this field is left blank. Alice presses the "login" button on her browser to submit the form to the authentication proxy.
- the authentication proxy verifies Alice's login name. If the authentication proxy does not recognize the name provided by Alice, it asks her to repeat step 310.
- step 320 the authentication proxy verifies the validity of the password. If the password provided by Alice is incorrect, the authentication proxy asks Alice to repeat step 310. If Alice uses certificate-based authentication, then step 320 is skipped and step 325 is executed.
- the authentication proxy sends Alice a web page with a JavaScript program that contains a unique URL reachable through a SSL protocol connection.
- the web page contains Alice's login page for the new session.
- the authentication proxy then closes the network connection with Alice's browser.
- Alice receives the login page.
- the embedded JavaScript program creates a new pop-up window in Alice's browser. This window attempts to reconnect to the login page using the unique URL provided by the authentication proxy.
- the authentication proxy waits for Alice to reconnect to the authentication proxy through the unique URL.
- the authentication proxy accepts the new connection if Alice provided a proper certificate when the SSL protocol negotiation for the connection took place. Otherwise, the new connection from Alice is rejected.
- the authentication protocol sends Alice a stream of http protocol cookies, where each cookie corresponds to a domain.
- the authentication proxy also sends a logout page to the pop-up window on Alice's computer.
- Alice's browser receives the cookies.
- the pop-up window displays the received logout button.
- the authentication proxy sends standby messages to the pop-up window to maintain a persistent connection.
- the authentication protocol also updates Alice's cookies when they are about to expire.
- the pop-up window in Alice's browser is in standby mode. Alice may discontinue her session at any time by pressing the logout button or by simply closing the pop-up window. Alice uses the cookies to transparently authenticate herself to the data proxy when establishing connections with services in the Cloud.
- FIG 4 shows another illustration of the embodiment of the invention discussed in connection with Figure 3.
- Browser state 410 shows the state of Alice's browser after Alice directs her browser to the authentication web site (i.e., after step 300 of Figure 3).
- Browser state 410 is essentially a form that Alice may complete in order to logon to use services in the Cloud (i.e. to login to the Gateway), which are located behind firewall 415.
- Firewall 415 is implemented through authentication proxy 420 and data proxy 440.
- authentication proxy 420 After Alice properly authenticates herself, authentication proxy 420 stores Alice's user identification in the list of active users in ACT 435. Authentication proxy 420 also sends Alice a page with a JavaScript program that contains a unique URL. Furthermore, authentication proxy 420 closes its connection with Alice's browser.
- the JavaScript program received by Alice's browser creates pop-up window 425 and causes Alice's browser to reconnect to authentication proxy 420 through the unique URL. While the connection to the unique URL is extant, Alice receives a stream of cookies, for example, cookies 450, 455, 460 and 465, from authentication proxy 420 containing tokens corresponding to services in the Cloud.
- Alice logouts of the Gateway by, for example, clicking on the logout box within pop-up window 425, the stream of cookies sent by authentication proxy 420 is stopped. While Alice remains logged on, she may access any Cloud service by simply directing her browser to that service.
- she may direct her browser to the web site "geoplex.domain.com/server.”
- Her browser detecting that the requested web site corresponds to a Cloud service, connects to data proxy 440 and sends cookie 450 corresponding to the requested Cloud Service to data proxy 440.
- Data proxy 440 then extracts the user identification information and other validity information embedded in the cookie (or embedded in a token embedded in the cookie).
- Other validity information may include the token expiration date, or information on the security grade over which the cookie is sent.
- data proxy 440 may determine that the token is invalid and refuse to connect Alice to the requested service.
- Data proxy 440 may also check the user identification information against the list of users stored in ACT 435. If no match is established, then data proxy 435 may determine that the received token is invalid and refuse to connect Alice to the requested service.
- data proxy 440 establishes that the received token is valid, then data proxy 440 connects Alice's browser to service 445. Alice will then see home page 430 of the requested service on her screen.
- the various embodiments of the present invention describe a single sign-on method and system for accessing a plurality of services distributed over a network in which authentication-related functionality is separated from the services, and in which authentication need not be renegotiated for access to a new service from the plurality of services during a session. Additional benefits accruing from embodiments of the invention include notification of the plurality of services when a user has terminated a session, and the use of secure, short-lived authentication tokens to verify a user's identity for subsequent access to the plurality of services.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
L'invention concerne un procédé et un dispositif comportant une procédure d'ouverture unique afin d'accéder à une pluralité de services distribués sur un réseau dans lequel la fonctionnalité relative à l'authentification est séparée des services et dans lequel l'authentification n'a pas besoin d'être renégociée pour accéder à un nouveau service parmi la pluralité de services pendant une session. D'autres avantages de l'invention consistent en la notification de la pluralité de services quand l'utilisateur a terminé une session et en l'utilisation de jetons d'authentification courts et sécurisés servant à vérifier l'identité de l'utilisateur pour un accès ultérieur à la pluralité de services. Ce procédé consiste à recevoir une demande d'un utilisateur d'autorisation d'accès à un service; à transmettre un jeton à l'utilisateur correspondant à ce service; à recevoir le jeton correspondant au service par l'utilisateur; à déterminer si l'utilisateur est autorisé à recevoir le service basé sur le jeton; et à mettre en contact l'utilisateur avec le service si cet utilisateur est autorisé à utiliser ce service.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US528189 | 1995-09-14 | ||
US52818900A | 2000-03-17 | 2000-03-17 | |
PCT/US2001/007282 WO2001072009A2 (fr) | 2000-03-17 | 2001-03-07 | Mecanisme d'authentification base sur le web et possedant une procedure d'ouverture unique |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1264463A2 true EP1264463A2 (fr) | 2002-12-11 |
Family
ID=24104602
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP01913338A Withdrawn EP1264463A2 (fr) | 2000-03-17 | 2001-03-07 | Mecanisme d'authentification base sur le web et possedant une procedure d'ouverture unique |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1264463A2 (fr) |
CA (1) | CA2400623C (fr) |
WO (1) | WO2001072009A2 (fr) |
Families Citing this family (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2821685A1 (fr) * | 2001-03-01 | 2002-09-06 | Couponet S A | Systeme d'echange d'informations entre des ordinateurs par l'intermediaire d'un reseau |
US7590859B2 (en) | 2001-08-24 | 2009-09-15 | Secure Computing Corporation | System and method for accomplishing two-factor user authentication using the internet |
US20030084302A1 (en) * | 2001-10-29 | 2003-05-01 | Sun Microsystems, Inc., A Delaware Corporation | Portability and privacy with data communications network browsing |
US7100197B2 (en) * | 2001-12-10 | 2006-08-29 | Electronic Data Systems Corporation | Network user authentication system and method |
US7221935B2 (en) | 2002-02-28 | 2007-05-22 | Telefonaktiebolaget Lm Ericsson (Publ) | System, method and apparatus for federated single sign-on services |
AU2003217103A1 (en) * | 2002-02-28 | 2003-09-09 | Telefonaktiebolaget L M Ericsson | System, method and apparatus for federated single sign-on services |
NO318842B1 (no) * | 2002-03-18 | 2005-05-09 | Telenor Asa | Autentisering og tilgangskontroll |
ES2281599T3 (es) * | 2003-06-26 | 2007-10-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Aparato y metodo para la autentificacion de identificacion unica a traves de una red de acceso no confiable. |
CN100461780C (zh) * | 2003-07-17 | 2009-02-11 | 华为技术有限公司 | 一种基于媒体网关控制协议的安全认证方法 |
JP2008506139A (ja) * | 2004-07-09 | 2008-02-28 | 松下電器産業株式会社 | ユーザ認証及びサービス承認を管理し、シングル・サイン・オンを実現して、複数のネットワーク・インタフェースにアクセスするためのシステム及び方法 |
KR100813791B1 (ko) * | 2004-09-30 | 2008-03-13 | 주식회사 케이티 | 유무선 통합서비스 망에서의 개인 이동성을 위한 통합인증 처리 장치 및 그 방법 |
GB0423301D0 (en) | 2004-10-20 | 2004-11-24 | Fujitsu Ltd | User authorization for services in a wireless communications network |
WO2006045402A1 (fr) | 2004-10-26 | 2006-05-04 | Telecom Italia S.P.A. | Procede et systeme permettant d'authentifier de maniere transparente un utilisateur mobile pour acceder a des services web |
US7748046B2 (en) | 2005-04-29 | 2010-06-29 | Microsoft Corporation | Security claim transformation with intermediate claims |
US7690026B2 (en) | 2005-08-22 | 2010-03-30 | Microsoft Corporation | Distributed single sign-on service |
GB0523871D0 (en) * | 2005-11-24 | 2006-01-04 | Ibm | A system for updating security data |
US8458775B2 (en) | 2006-08-11 | 2013-06-04 | Microsoft Corporation | Multiuser web service sign-in client side components |
US7856104B2 (en) | 2007-02-05 | 2010-12-21 | Sony Corporation | System and method for ensuring secure communication between TV and set back box |
US8539559B2 (en) | 2006-11-27 | 2013-09-17 | Futurewei Technologies, Inc. | System for using an authorization token to separate authentication and authorization services |
GB2445172A (en) * | 2006-12-29 | 2008-07-02 | Symbian Software Ltd | Use of an interaction object in transactions |
US8099597B2 (en) | 2007-01-09 | 2012-01-17 | Futurewei Technologies, Inc. | Service authorization for distributed authentication and authorization servers |
US8429713B2 (en) | 2007-04-02 | 2013-04-23 | Sony Corporation | Method and apparatus to speed transmission of CEC commands |
US8510798B2 (en) | 2007-04-02 | 2013-08-13 | Sony Corporation | Authentication in an audio/visual system having multiple signaling paths |
US8285990B2 (en) | 2007-05-14 | 2012-10-09 | Future Wei Technologies, Inc. | Method and system for authentication confirmation using extensible authentication protocol |
US8806201B2 (en) * | 2008-07-24 | 2014-08-12 | Zscaler, Inc. | HTTP authentication and authorization management |
US8151333B2 (en) | 2008-11-24 | 2012-04-03 | Microsoft Corporation | Distributed single sign on technologies including privacy protection and proactive updating |
US8924569B2 (en) * | 2009-12-17 | 2014-12-30 | Intel Corporation | Cloud federation as a service |
WO2011078723A1 (fr) * | 2009-12-25 | 2011-06-30 | Starodubtsev Valeriy Ivanovich | Système de commande et d'achat de produits et de services (variantes), procédé de mise à la vente et de passage de commande, et procédé de vente de produits et de services |
US9965614B2 (en) * | 2011-09-29 | 2018-05-08 | Oracle International Corporation | Mobile application, resource management advice |
JP5485246B2 (ja) | 2011-11-05 | 2014-05-07 | 京セラドキュメントソリューションズ株式会社 | 画像形成装置 |
US8769651B2 (en) | 2012-09-19 | 2014-07-01 | Secureauth Corporation | Mobile multifactor single-sign-on authentication |
US9479490B2 (en) * | 2013-06-07 | 2016-10-25 | Apple Inc. | Methods and systems for single sign-on while protecting user privacy |
US10237732B2 (en) | 2013-06-12 | 2019-03-19 | Telecom Italia S.P.A. | Mobile device authentication in heterogeneous communication networks scenario |
US10129243B2 (en) * | 2013-12-27 | 2018-11-13 | Avaya Inc. | Controlling access to traversal using relays around network address translation (TURN) servers using trusted single-use credentials |
US9769668B1 (en) | 2016-08-01 | 2017-09-19 | At&T Intellectual Property I, L.P. | System and method for common authentication across subscribed services |
CN113439427B (zh) * | 2019-07-24 | 2023-10-27 | Oppo广东移动通信有限公司 | 一种资源发布方法和设备 |
CN111917732B (zh) * | 2020-07-10 | 2022-04-26 | 杭州海康威视数字技术股份有限公司 | 一种大数据组件的访问方法、装置、***及电子设备 |
CN115051809A (zh) * | 2022-06-15 | 2022-09-13 | 道和邦(广州)电子信息科技有限公司 | SMG-wscomm-Msession-ECToken一种基于加密CookieToken免登录认证动态令牌技术 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5684950A (en) * | 1996-09-23 | 1997-11-04 | Lockheed Martin Corporation | Method and system for authenticating users to multiple computer servers via a single sign-on |
US6000033A (en) * | 1997-11-26 | 1999-12-07 | International Business Machines Corporation | Password control via the web |
-
2001
- 2001-03-07 EP EP01913338A patent/EP1264463A2/fr not_active Withdrawn
- 2001-03-07 CA CA002400623A patent/CA2400623C/fr not_active Expired - Fee Related
- 2001-03-07 WO PCT/US2001/007282 patent/WO2001072009A2/fr active Application Filing
Non-Patent Citations (1)
Title |
---|
See references of WO0172009A3 * |
Also Published As
Publication number | Publication date |
---|---|
WO2001072009A3 (fr) | 2002-04-11 |
CA2400623A1 (fr) | 2001-09-27 |
WO2001072009A2 (fr) | 2001-09-27 |
CA2400623C (fr) | 2007-03-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2400623C (fr) | Mecanisme d'authentification base sur le web et possedant une procedure d'ouverture unique | |
US7197568B2 (en) | Secure cache of web session information using web browser cookies | |
US7100054B2 (en) | Computer network security system | |
EP1766840B1 (fr) | Authentification graduee dans un systeme de gestion d'identites | |
JP5926441B2 (ja) | マルチパーティシステムにおける安全な認証 | |
US6993652B2 (en) | Method and system for providing client privacy when requesting content from a public server | |
JP4867663B2 (ja) | ネットワーク通信システム | |
EP1280317B1 (fr) | Autorisation et authentification multi-domaine | |
US9998448B2 (en) | Delegating authorizations | |
US20030115341A1 (en) | Method and system for authenticating a user in a web-based environment | |
EP0940960A1 (fr) | Authentification entre serveurs | |
US20030097592A1 (en) | Mechanism supporting wired and wireless methods for client and server side authentication | |
US20030163691A1 (en) | System and method for authenticating sessions and other transactions | |
US20050108575A1 (en) | Apparatus, system, and method for faciliating authenticated communication between authentication realms | |
JP5602165B2 (ja) | ネットワーク通信を保護する方法および装置 | |
EP1388060A1 (fr) | Procede et appareil pour desservir un contenu depuis un serveur semi-securise | |
CN103503408A (zh) | 用于提供访问凭证的***和方法 | |
CA2475150A1 (fr) | Systeme et procede de verification des autorisations par le client pour les protocoles de gestion cles | |
WO2007073603A1 (fr) | Infrastructure a cle publique basee sur les sessions | |
NO318842B1 (no) | Autentisering og tilgangskontroll | |
EP3788758B1 (fr) | Procédé et système pour autoriser une connexion sécurisée via un dispositif mobile | |
JP2001186122A (ja) | 認証システム及び認証方法 | |
CN117354032A (zh) | 一种基于代码服务器的多重认证方法 | |
KR100366403B1 (ko) | 인터넷 환경에서의 사용자 인증방법 및 이를 위한 시스템 | |
Miyake et al. | Notification of Certificate Revocation Status between Different Domains under a PKI System |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20021004 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR |
|
RBV | Designated contracting states (corrected) |
Designated state(s): DE FR GB |
|
17Q | First examination report despatched |
Effective date: 20070525 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20071005 |