WO2011038752A1 - Authentication gateway - Google Patents

Authentication gateway Download PDF

Info

Publication number
WO2011038752A1
WO2011038752A1 PCT/EP2009/062606 EP2009062606W WO2011038752A1 WO 2011038752 A1 WO2011038752 A1 WO 2011038752A1 EP 2009062606 W EP2009062606 W EP 2009062606W WO 2011038752 A1 WO2011038752 A1 WO 2011038752A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
user
service provider
user device
details
Prior art date
Application number
PCT/EP2009/062606
Other languages
French (fr)
Inventor
Robert Seidl
Joerg Abendroth
Gerald Meyer
Markus Bauer-Hermann
Original Assignee
Nokia Siemens Networks Oy
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 Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Priority to PCT/EP2009/062606 priority Critical patent/WO2011038752A1/en
Publication of WO2011038752A1 publication Critical patent/WO2011038752A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to network resources
    • H04L63/102Entity profiles
    • GPHYSICS
    • G06COMPUTING; CALCULATING; 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
    • G06F21/41User authentication where a single sign-on provides access to a plurality of computers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0815Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network providing single-sign-on or federations

Abstract

An authentication gateway for providing authentication details to a service provider is described. The authentication gateway receives an authentication request, such as a log-in form, from a user, retrieves authentication details for the user (typically from an IDM), and responds to the authentication request. The response, which includes the authentication details, is sent directly to the service provider where the authentication request originated. Thus, the user device does not need to handle authentication details for the user, thereby improving the security of the system.

Description

Description

Title

Authentication Gateway

This invention is related to the field of identity management in conjunction with service access control. Figure 1 is a block diagram of a known system, indicated generally by the reference numeral 1, for providing user credentials to a service provider. The system 1 comprises a user 2, a service provider 4 and an identity provider or an identity management system (IDM) 6. The user 2 (typically in the form of a web browser) is in two-way communication with both the service provider 4 and the identity management system 6.

In use, the service provider 4 requires authentication information regarding the user 2 (such as user credentials) before the service provider will allow the user access to at least some services provided by the service provider. The service provider may, for example, present the user 2 with a log-in form. The requested user credentials are stored at the identity management system 6 and so the user 2 requests the user credentials from the IDM 6 and then completes the log- in form in order to gain access to the requested

service (s) . It is known to provide web browsers with the ability to recognize log- in forms in web pages and to fill in the necessary content automatically according to certain rules, policies and/or security settings. These settings may be controlled by the user, by a network administrator and/or by a network provider and are intended to ensure an appropriate security level for the publication of log-in credentials. Example tools include the "password store" tool provided in the Mozilla Firefox (RTM) browser and the password management tool called "Wand" provided as part of the Opera web browser.

Thus, the system 1 described above can be used to enable a browser at the user 2 to automatically recognize and complete a log- in form issued by the service provider 4 using user credentials stored at the identity management system 6. An advantage of such an arrangement is that the provision of user credentials on request by an IDM system avoids static storage of credentials within the browser extension. This can improve security since third parties may be able to access such statically stored credentials.

Nevertheless, although credentials are not statically stored at the user device, the credentials are temporarily available in the device's memory and might be vulnerable to attacks by viruses and other malicious software, such as Trojan horse applications. Additionally, it does not matter whether the credentials are temporarily visible in the device "as a whole" or just in sequential portions (e.g. as a sequence of keystrokes) .

Thus, a browser at the user 2 cannot guarantee attack- free operation of the system 1 and thus cannot guarantee the authenticity of the user.

Particular problems exist in circumstances where the user browser is not owned and administered by the user. This may be the case, for example, where a shared computer is being used, for example in an Internet cafe, or as a community PC.

The system 1 is one example of a system in which passwords and other security-related information are stored away from the user device. Such arrangements, which are sometimes referred to as "password safes", generally suffer from the problem of temporary content exposure and thus can be

attacked by malicious third parties. The present invention seeks to address at least some of the problems outlined above.

According to an aspect of the present invention, there is provided a method comprising: receiving an authentication request from a user device, wherein the request originates at a service provider; retrieving authentication details for the user of the user device; preparing a response to the

authentication request, the response including the retrieved authentication details; and sending the authentication response to the service provider. In a preferred embodiment of the invention, the authentication response is sent

directly to the service provider. Thus, the authentication details are not (or at least need not) be provided to the user device. In any event, the authentication response is not sent to the service provider via the user device. The authentication request is typically received at an

authentication gateway and the authentication response is typically prepared and sent by the authentication gateway.

According to an aspect of the invention, there is provided an apparatus (such as an authentication gateway) comprising: a first input adapted to receive an authentication request from a user device, wherein the request originates at a service provider; a second input adapted to receive authentication details for the user of the user device on request from the apparatus; a processor for preparing a response to the authentication request, the response including the retrieved authentication details; and a first output adapted to send the authentication response to the service provider. The authentication details are not (or at least need not be) provided to the user device. In particular, the

authentication response is not sent from the apparatus (e.g. an authentication gateway) to the service provider via the user device.

The invention provides means for auto-completion of web forms and the like which are used for authentication of a user. In contrast to existing solutions, the invention separates the detection of a log- in form in a web page or the like and the insertion of credentials. These steps can be performed in logically and spatially distinct entities.

In some forms of the invention, retrieving the authentication details comprises obtaining the authentication details from an identity provider or an identity management system. The user device may comprise an IDM satellite. The

authentication request may be received from the IDM

satellite. Thus, the authentication request may be sent from the service provider to the apparatus of the present

invention via the IDM satellite.

The said authentication request may be a log- in form

originating at the service provider. Alternatively, the authentication request may be some other form that requires the inclusion of user credentials.

The invention may additionally require the identification of the user. In other words, the apparatus of the invention (e.g. an authentication gateway) may be required to identify the user. The authentication request received from the user device may include sufficient information to enable the user to be identified (e.g. by the authentication gateway) . Thus, the authentication request may be received at the user device from the service provider, modified at the user device (e.g. by an IDM satellite) to include sufficient information to enable an IDM to identify the user, and then forwarded by the user device, e.g. to the apparatus of the invention. The information identifying the user may, for example, be

provided by using trusted platform module (TPM) technology, chip card technology (e.g. a SIM card), shared secrets, certificates or keys.

The apparatus of the present invention may be physically and/or logically separated from the user device. In one form of the invention, the apparatus is logically separated from the user device, but is not physically separated; for example, in one form of the invention, the apparatus is provided in a separated and protected domain to the user device and the IDM satellite.

In accordance with an aspect of the present invention, there is provided a method comprising: requesting access to a service provided by a service provider, wherein user

credentials are required to access said service; and

forwarding an authentication request originating at the service provider to an authentication gateway for completion by the authentication gateway, wherein the authentication gateway provides the requested user credentials to the service provider. Thus, the user credentials can be provided to the service provider without being provided to the user device. The method may further comprise sending

authentication information to said authentication gateway sufficient to enable the authentication gateway to obtain the said user credentials.

In accordance with an aspect of the present invention, there is provided an apparatus comprising: a first output for requesting access to a service provided by a service

provider, wherein user credentials are required to access said service; and a second output for forwarding an

authentication request originating at the service provider to an authentication gateway for completion by the

authentication gateway, wherein the authentication gateway provides the requested user credentials to the service provider without providing (or at least without needing to provide) the details to the user device. The apparatus may be a user device. The apparatus may be an IDM satellite and may, for example, be provided as a pluggable device, such as a USB memory stick or similar device.

The authentication request may be sent to the authentication gateway from an IDM satellite. Thus, the authentication request may be sent from the service provider to the

apparatus of the present invention via the IDM satellite.

The said authentication request may be a log- in form

originating at the service provider. Alternatively, the authentication request may be some other form that requires the inclusion of user credentials.

The invention may additionally require the identification of the user. In other words, the authentication gateway may be required to identify the user. The authentication request sent to the authentication gateway may include sufficient information to enable the user to be identified (e.g. by the authentication gateway) . Thus, the authentication request may be received at the user device from the service provider, modified at the user device (e.g. by an IDM satellite) to include sufficient information to enable an IDM to identify the user, and then forwarded by the user device, e.g. to the authentication gateway. The information identifying the user may, for example, be provided by using trusted platform module (TPM) technology, chip card technology (e.g. a SIM card), shared secrets, certificates or keys.

The apparatus of the present invention may be physically and/or logically separated from the user device. In one form of the invention, the apparatus is logically separated from the user device, but is not physically separated; for

example, in one form of the invention, the apparatus is provided in a separated and protected domain to the user device and the IDM satellite.

In accordance with an aspect of the present invention, there is provided a computer program comprising: code (or some other means) for receiving an authentication request from a user device, wherein the request originates at a service provider; code (or some other means) for retrieving

authentication details for the user of the user device; code (or some other means) for preparing a response to the authentication request, the response including the retrieved authentication details; and code (or some other means) for sending the authentication response to the service provider, such that the authentication details are not provided to the user device. The computer program may be a computer program product comprising a computer- readable medium bearing

computer program code embodied therein for use with a

computer . In accordance with an aspect of the present invention, there is provided a computer program comprising: code (or some other means) for requesting access to a service provided by a service provider, wherein user credentials are required to access said service; and code (or some other means) for forwarding an authentication request originating at the service provider to an authentication gateway for completion by the authentication gateway, wherein the authentication gateway provides the requested user credentials to the service provider. The requested user credentials may be proved directly to the service provider, i.e. without providing the details to the user device or IDM satellite. The computer program may be a computer program product comprising a computer- readable medium bearing computer program code embodied therein for use with a computer.

Exemplary embodiments of the invention are described below, by way of example only, with reference to the following numbered schematic drawings. Figure 1 is a block diagram of a known system for providing authentication information to a service provider;

Figure 2 is a block diagram in accordance with an aspect of the present invention; and

Figure 3 shows a message sequence in accordance with an aspect of the present invention.

Figure 2 is a block diagram of a system, indicated generally by the reference numeral 10, in accordance with an aspect of the present invention. The system 10 comprises a user 12, an identity management (IDM) satellite 13, a service provider 16, an authentication gateway 18 and an identity management system (IDM) 20. The user 12 and the IDM satellite 13 collectively form a user sub-system 14. The IDM satellite 13 is in two-way communication with both the service provider 16 and the authentication gateway 18. The authentication gateway 18 is also in two-way communication with the service provider 16 and the IDM 20.

In a similar manner to the system 1 described above, the service provider 16 requires the user 12 to provide user credentials (such as a user name and password pair) in order to access at least some services provided by the service provider. Those credentials are stored at the IDM 20.

The IDM satellite 13 typically resides at the user's

premises, or forms part of a user device, and is used to recognize that a web page may contain a form requiring the user to fill-in some log-in credentials. As discussed below, the authentication gateway 18 is used to populate the log- in form with the required user credentials. Accordingly, there is a functional separation between login-in form detection (carried out by the IDM satellite 13) and login form

completion (carried out by the authentication gateway 18) .

The separation between the IDM satellite 13 and the

authentication gateway 18 could be handled in a variety of ways. For example, a possible solution is as follows. Upon form submission (e.g. when a user clicks on a LOGIN-Button) , the satellite 13 recognizes that a login step should occur and does not send the whole request back to the server 16 (as a proxy usually does) but sends it to the authentication gateway 18 (which is an external network element) . Now the authentication gateway inserts the credentials, sends this all to the server 16, fetches the responses and sends the response back to the IDM satellite 13 who sends it back to the user browser 12. Figure 3 shows a message sequence, indicated generally by the reference numeral 30, showing an exemplary use of the system 10. The message sequence 30 shows the interaction between the participating parties and explains the functional

separation between log- in form detection and log- in form auto-completion. The message sequence 30 serves as an exemplary explanation of the principal functions of the present invention and does not describe the only possible implementation. For example, although the IDM satellite is described as being part of the user device 12, similar functionality could be provided by a proxy that forms part of an operator's network. The message sequence 30 begins with the user 12 sending a message 32 to the IDM satellite 13 requesting access to a web page provided by the service provider 16. The message 32 may, for example, be a simple HTTP GET request. The IDM satellite sends a message 34 to the service provider 16 requesting access to that web page and the service provider responds by providing a web page as message 36. The message 34 may, for example, be also be a simple HTTP GET request. The response 36 may be the HTTP-Response 200 that includes an HTML payload.

The web page provided in the message 36 (the payload) includes a log-in form. The IDM satellite 13 recognizes that there is a log- in form. This may be achieved in a variety of ways. For example, in the payload of the message 36, password input fields may be marked as type "password" instead of type "input" . Fields may also grouped together in a "form" which is submitted on a button click. By parsing the page for "type= ' password' " one can easily find these input fields and their names which are needed in the http-request .

On recognizing the log-in form, the IDM satellite delegates the form completion to the authentication gateway 18. In order to achieve this, the IDM satellite 13 has to send a 1 clear identification to the authentication gateway (i.e. it has to authenticate itself) . Of course, there are security issues to consider. It should not be possible to compromise this authentication. This requires attack-resistant storage of the necessary keys, shared secrets, certificates or the like which might be achieved, for example, by using trusted platform module (TPM) technology or chip card technology (e.g. a SIM card) . Various variants of authentication are possible here; the following non-exhaustive list contains three examples:

1. The IDM satellite 13 sends the necessary parameters to the authentication gateway 18 (e.g. the originator's address in order to determine which credentials are of interest) and signs them with a private key. The IDM satellite also forwards the corresponding public key which can later be inspected by the IDM 20 for validity. The public key

identifies the IDM satellite 13 towards the authentication gateway 18.

2. A challenge-response procedure is used between

authentication gateway 18 and IDM satellite 13. This means that there exists a shared secret between the IDM satellite 13 and the authentication gateway 18. First, the satellite 13 sends an authentication request (this could also contain the originator's address mentioned before) . The authentication gateway 18 reacts by sending a "challenge" . The satellite computes a response from the challenge and the shared secret and sends that response to the authentication gateway 18. The authentication gateway compares the result with the expected answer to determine whether or not the IDM satellite should be trusted.

3. A session binding exists between the IDM satellite 13 and the authentication gateway 18, e.g. by use of a non- compromisable identifier that is forwarded from the IDM satellite to the authentication gateway. The authentication gateway inspects the user's identifier to determine the identity of the user. The binding can be reached by out of band means (e.g. the user's mobile communication device), a one-time password (like an RSA (Rivest, Shamir and Adleman) Token) or simple web login. If the non-compromisable

identifier is used, it is stored on the IDM satellite by using cryptographic protection, e.g. on a SIM card or other chip card or using TPM (Trusted Platform Module) mechanisms.

In any event, the authentication gateway 18 receives the request 38 from the IDM satellite 13 and, in response, sends a message 40 to the IDM 20 requesting the user credentials required in order to complete the log- in form provided by the service provider 16. The message 38 may be an HTTP POST, including the payload discussed above. The message 40 may be a SAML attribute query, requesting the user credentials required to complete the login form provided by the service provider 16.

In response to the message 40, the IDM 20 provides the requested user credentials in a message 42. The message 42 may take the form of a SAML attribute response.

The authentication gateway is now able to modify the payload of the HTTP POST message 38 to include the user credentials for the user, as obtained from the IDM 20. Thus, the

authentication gateway 18 completes the log- in form issued by the service provider 16 by including the requested user credentials and sends the completed form, as message 44, to the service provider 16. The message 44 may take the form of an HTTP POST message with the modified payload. The form itself is not generally shown to the user, since this is handled at protocol level. The authentication gateway 18 receives an HTTP Post containing the URL of the receiver and the form fields in the body. The authentication gateway replaces the values for the form fields (and maybe also the URL to protect against phishing)

The service provider 16 sends a response to the 1 authentication gateway 18, which gateway acts as a kind of second proxy for the user 12, as message 46. The message 46 may be an HTTP Response, with an HTML page as a payload. It should be noted that although the service provider sent the original log-in form to the IDM satellite 13, it is generally acceptable for the response to arrive from a different source (the authentication gateway 18 in this case) . Typically the service provider is expecting to receive the requested credentials together with a cookie identifying the session. As the authentication gateway 18 can obtain both the cookie identifying the session and the requested credentials, the authentication gateway can provide all the information required to satisfy the service provider 16. The authentication gateway 18 forwards the response to the IDM satellite 13, which is the first proxy for the user 12, as message 48. Finally, the IDM satellite 13 delivers the response to the user as message 50. The messages 48 and 50 may therefore be HTTP responses, with the payload referred to above .

Thus, the user 12 is authenticated at the service provider and can use the restricted services provided by the service provider without the user credentials being sent via the user device or the IDM satellite 13. Thus, using the system 10, it is not possible for malicious software at the user device to obtain the user credentials.

The IDM satellite 13 at the user client 12 may take the form of a pluggable device, such as a Universal Serial Bus (USB) memory stick or similar device. Thus, the IDM satellite can aid user mobility since it can be moved from one user device to another. For example, the user may use the IDM satellite at a user device at an Internet cafe. In such an

environment, the IDM satellite can be used to instruct the authentication gateway 18 to provide log-in details to the service provider 16, with the user credentials not needing to pass through the machine at the Internet cafe. Since the 1 identity information that enables the IDM satellite 13 to log into the IDM 20 may be stored in a secure place (such as a SIM), malicious software on the actually used client (e.g. a personal computer at an Internet cafe) cannot access and misuse it.

The elements of the system 10 could be located in many different places. For example, the IDM satellite 13 may communicate with any one, two or all of the service provider 16, authentication gateway 18 and IDM 20 via the Internet. Alternatively, some of the elements of the system 10 may be located within an Intranet. For example, the user 12 and the IDM satellite 13 may be located outside an Intranet, but may be able to communicate with resources, such as the service provider 16 and/or the authentication gateway 18 that are located within the Intranet.

As described above, log- in forms and other web forms are sensitive to attacks by malicious software because the user credentials are handled in a non-encrypted way, at least for a short time. In the present invention, this function is handled by the authentication gateway 18 rather than the user device 12 or the IDM satellite 13. The authentication gateway 18 is functionally, and possibly also physically, separated from the IDM satellite 13 (and the user device 12) . Accordingly, user credential data is no longer accessible to attacks by viruses or Trojan horses on the client device. The authentication gateway may be controlled by a network operator, which is not vulnerable to client-driven attacks.

In an alternative form of the invention, the authentication gateway 18 runs on the machine of the user (thereby forming part of the user sub- system 14) , but in a separate and protected domain to the user 12 and the IDM satellite 13. This solution utilises virtualisation technology and may require the operator to verify the virtualisation host prior to deploying his authentication gateway. Such an arrangement enables computation and availability demands to be distributed, although the added complexity of administration should not be neglected. In general terms, the idea here is to run a second "virtual machine" on the physical hardware and takes one step into so-called cloud computing. The second virtual machine runs in a protected environment and (maybe) also protects itself. So even if the outer machine is compromised, you still have the "secure and trusted second machine" which handles your user credentials and similar data .

The embodiments of the invention described above are

illustrative rather than restrictive. It will be apparent to those skilled in the art that the above devices and methods may incorporate a number of modifications without departing from the general scope of the invention. It is intended to include all such modifications within the scope of the invention insofar as they fall within the scope of the appended claims.

Claims

CLAIMS :
1. A method comprising:
receiving an authentication request from a user device, wherein the request originates at a service provider;
retrieving authentication details for the user of the user device;
preparing a response to the authentication request, the response including the retrieved authentication details; and sending the authentication response to the service provider, such that the authentication details are not provided to the user device.
2. A method as claimed in claim 1, wherein retrieving the authentication details comprises obtaining the authentication details from an identity provider.
3. A method as claimed in claim 1 or claim 2, wherein the user device includes an IDM satellite.
4. A method as claimed in any one of claims 1 to 3 , wherein said authentication request is a log-in form.
5. A method as claimed in any preceding claim, further comprising identifying the user.
6. A method as claimed in any preceding claim, wherein said authentication request includes sufficient information to identify the user.
7. An apparatus comprising:
a first input adapted to receive an authentication request from a user device, wherein the request originates at a service provider;
a second input adapted to receive authentication details for the user of the user device on request from the
apparatus ; a processor for preparing a response to the authentication request, the response including the retrieved authentication details; and
a first output adapted to send the authentication response to the service provider, wherein the authentication details are not provided to the user device.
8. An apparatus as claimed in claim 7, wherein the
apparatus is physically separated from the user device.
9. An apparatus as claimed in claim 7 or claim 8, wherein the apparatus is logically separated from the user device.
10. An apparatus as claimed in any one of claims 7 to 9 , wherein said authentication details are obtained from an identity provider.
11. An apparatus as claimed in any one of claims 7 to 10, wherein said authentication request identifies the said user.
12. A method comprising:
requesting access to a service provided by a service provider, wherein user credentials are required to access said service; and
forwarding an authentication request originating at the service provider to an authentication gateway for
completion by the authentication gateway, wherein the
authentication gateway provides the requested user
credentials to the service provider without providing the details to the user device.
13. A method as claimed in claim 12, further comprising sending authentication information to said authentication gateway sufficient to enable the authentication gateway to obtain the said user credentials.
14. An apparatus comprising: a first output for requesting access to a service provided by a service provider, wherein user credentials are required to access said service; and
a second output for forwarding an authentication request originating at the service provider to an
authentication gateway for completion by the authentication gateway, wherein the authentication gateway provides the requested user credentials to the service provider.
15. A computer program product comprising:
means for receiving an authentication request from a user device, wherein the request originates at a service provider;
means for retrieving authentication details for the user of the user device;
means for preparing a response to the authentication request, the response including the retrieved authentication details; and
means for sending the authentication response to the service provider, such that the authentication details are not provided to the user device.
16. A computer program product comprising:
means for requesting access to a service provided by a service provider, wherein user credentials are required to access said service; and
means for forwarding an authentication request originating at the service provider to an authentication gateway for completion by the authentication gateway, wherein the authentication gateway provides the requested user credentials to the service provider.
PCT/EP2009/062606 2009-09-29 2009-09-29 Authentication gateway WO2011038752A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2009/062606 WO2011038752A1 (en) 2009-09-29 2009-09-29 Authentication gateway

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2009/062606 WO2011038752A1 (en) 2009-09-29 2009-09-29 Authentication gateway

Publications (1)

Publication Number Publication Date
WO2011038752A1 true WO2011038752A1 (en) 2011-04-07

Family

ID=42352253

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/062606 WO2011038752A1 (en) 2009-09-29 2009-09-29 Authentication gateway

Country Status (1)

Country Link
WO (1) WO2011038752A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2484487A1 (en) * 2002-04-26 2003-11-06 International Business Machines Corporation Efficient browser-based identity management providing personal control and anonymity
WO2005125077A1 (en) * 2004-06-16 2005-12-29 Sxip Networks Srl Graduated authentication in an identity management system
US20080071808A1 (en) * 2006-09-14 2008-03-20 Sxip Identity Corporation Internet Identity Manager

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2484487A1 (en) * 2002-04-26 2003-11-06 International Business Machines Corporation Efficient browser-based identity management providing personal control and anonymity
WO2005125077A1 (en) * 2004-06-16 2005-12-29 Sxip Networks Srl Graduated authentication in an identity management system
US20080071808A1 (en) * 2006-09-14 2008-03-20 Sxip Identity Corporation Internet Identity Manager

Similar Documents

Publication Publication Date Title
US9154488B2 (en) Secured access to resources using a proxy
KR100872099B1 (en) Method and system for a single-sign-on access to a computer grid
US6985953B1 (en) System and apparatus for storage and transfer of secure data on web
US8881257B2 (en) Method and apparatus for trusted federated identity management and data access authorization
US8532620B2 (en) Trusted mobile device based security
JP4949032B2 (en) System and method for preventing identity theft using a secure computing device
KR101019458B1 (en) Extended one­time password method and apparatus
EP2936371B1 (en) Privacy enhanced key management for a web service provider using a converged security engine
Singh et al. Cloud security issues and challenges: A survey
KR101721032B1 (en) Security challenge assisted password proxy
US9191394B2 (en) Protecting user credentials from a computing device
US8019995B2 (en) Method and apparatus for preventing internet phishing attacks
US20100115594A1 (en) Authentication of a server by a client to prevent fraudulent user interfaces
US8776176B2 (en) Multi-factor password-authenticated key exchange
US20090013063A1 (en) Method for enabling internet access to information hosted on csd
US8635457B2 (en) Data certification methods and apparatus
KR101148627B1 (en) Method and apparatus for preventing phishing attacks
Jøsang et al. Usability and privacy in identity management architectures
EP2533172B1 (en) Secure access to data in a device
JP5658745B2 (en) HTTP-based authentication
US9300653B1 (en) Delivery of authentication information to a RESTful service using token validation scheme
US9461982B2 (en) Disposable browsers and authentication techniques for a secure online user environment
US8353016B1 (en) Secure portable store for security skins and authentication information
US20130340028A1 (en) Secure web container for a secure online user environment
US8510811B2 (en) Network transaction verification and authentication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09783543

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct app. not ent. europ. phase

Ref document number: 09783543

Country of ref document: EP

Kind code of ref document: A1