WO2009046758A1 - Procédé, appareils et programmes d'ordinateur pour lier des informations d'un utilisateur entre des serveurs fournissant des assertions d'authentification - Google Patents

Procédé, appareils et programmes d'ordinateur pour lier des informations d'un utilisateur entre des serveurs fournissant des assertions d'authentification Download PDF

Info

Publication number
WO2009046758A1
WO2009046758A1 PCT/EP2007/060687 EP2007060687W WO2009046758A1 WO 2009046758 A1 WO2009046758 A1 WO 2009046758A1 EP 2007060687 W EP2007060687 W EP 2007060687W WO 2009046758 A1 WO2009046758 A1 WO 2009046758A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
user
communication
identifier
terminal
Prior art date
Application number
PCT/EP2007/060687
Other languages
English (en)
Inventor
Carolina Canales Valenzuela
Miguel Angel Monjas Llorente
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/EP2007/060687 priority Critical patent/WO2009046758A1/fr
Publication of WO2009046758A1 publication Critical patent/WO2009046758A1/fr

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the present invention relates to method and apparatuses for linking information of a user between a first and a second server, each of said servers arranged for providing an authentication assertion of said user to a further service server .
  • a typical service provision scenario comprises: a user terminal, a service provider and one or more interconnection networks providing the necessary connectivity.
  • the user terminal can be a personal computer PC, a mobile phone terminal MT, a personal data assistant PDA, etc.
  • a service provider is an organization having one or more service servers (also known as application servers, ASs) arranged to provide one or more services to some users.
  • a service server of a SP is commonly implemented as a computer-based apparatus comprising hardware and software implementing the necessary service logic and communication capabilities so as to provide some service (s) to a user terminal, or also to other servers .
  • a service provider SP can own part or all of the telecommunications system (s) and interconnection network (s) necessary to accomplish with a service provision to a user terminal.
  • a mobile network operator or a fixed network operator, can have within its network domain, and in addition to the - say- traditional telecommunications nodes forming the so called access/core network (such as Mobile Switching Centers MSCs, Serving or Gateways GPRS nodes SGSN/GGSN, etc) , service servers forming the so called service network arranged to provide some additional services to its subscribers and users.
  • access/core network such as Mobile Switching Centers MSCs, Serving or Gateways GPRS nodes SGSN/GGSN, etc
  • a web-based calendar, a payment brokering service, a location-dependent information service, etc, are examples of services going beyond the (mere) provision of voice, text and/or multimedia communications, which can be provided by a mobile network operator to some subscribers/users, wherein some of them could be also accessible through other communications networks, such as the Internet.
  • SPs there can be other kind of SPs, which does not own any kind of access network (e.g. fixed or mobile) , and which merely devote to provide final services to users that can connect to their service servers through other systems and networks.
  • a service or its content is to be adapted according to the particular served user (e.g. depending on his preferences, characteristics, service history, etc) , and/or when the service is to be rendered only to users who have a service account with the SP.
  • the SP In the particular case in which the provision of a service is subject to user identification, the SP usually needs to implement authentication mechanisms, which commonly requires storage and management of user credentials (such as user identifiers and passwords).
  • user credentials such as user identifiers and passwords.
  • it can be cumbersome to handle a plurality of credentials in a plurality of different SPs in which he may have service accounts, since he is required, not only to remember these credentials, but to authenticate before every one of these SPs.
  • SSO Single Sign On
  • An identity federation framework can extend across one or more telecommunications systems and comprises one or more SPs, which provide service (s) to the final users, and at least one Identity Provider (IDP) .
  • An IDP can be a SP having a server arranged for providing authentication assertions of usually a plurality of users to a plurality of service servers of the same, or other, SP.
  • such a server stores credentials of said user (usually a user identifier and a password, which used for authenticating the user in a given session) , and also a plurality of identifiers (usually referred as pseudonyms or aliases) each shared in common with, respectively, a plurality of SPs with which said user has federated his identity.
  • the IDP can then use information of said user (e.g. shared identifier, authentication state, etc) for issuing an authentication assertion of said user for a given SP, which can then use the received authentication assertion to, e.g., identify the user and provide a requested service.
  • an authentication assertion comprises digital information that asserts to the receiver that the referred subject has been properly authenticated.
  • SAML Security Assertion Markup Language
  • HTTP Hypertext Transfer Protocol
  • SOAP Simple Object Access Protocol
  • identity federation framework provides a general overview of the features in an identity federation framework.
  • pages 35 to 38 provides some details on how an identity federation takes place for a user between his IDP and a SP; and pages 39 to 49 provides details related to SSO processes.
  • identity federation for a user between a SP and his IDP takes place by storing a common identifier between them, which can then be used to refer to said user in further (direct or indirect) transactions between them, such as for generating authentication assertions in the IDP to accomplish with SSO for providing a service from the SP to said user.
  • COT Compute Of Trust
  • IDP authentication provider
  • server i.e. having at least one server arranged for providing authentication assertions to a number of SPs, e.g. as described above with reference to LAP
  • third-party SPs providing services to the operator's users .
  • Service provisioning by means of SSO mechanisms has also been envisaged for inter-COT scenarios, so as to allow users access seamlessly to services provided by any of the SPs belonging to different COTs.
  • a major advantage is that a given user already authenticated by e.g. an IDP the first COT does not need to authenticate before an IDP of the second COT to access even in a personalized way (e.g. with a service account in said SP storing some personalization data) to a service provided by a SP of the second COT.
  • IDP proxying mechanism is provided by LAP. In short, the mechanism operates as follows .
  • a user federated to, e.g., IDPl of COT-I access IDPl from his PC with a web browser and authenticates, for example, by means of user identifier and password. Then, the user accesses with his browser a SP-2 belonging to COT- 2 where he has a service account and related data. As the service requested by the user to SP-2 is subject to authentication, the user's browser is redirected to the IDP of COT-2 known to SP-2, IDP2, which then redirects the user towards his own IDP, IDPl. As the user is already authenticated for the current session, the IDPl issues an authentication assertion and redirects the user back to IDP2. Then, the IDP2 consumes the authentication assertion issued by the IDPl and creates another one for said user which is usable to be consumed by the SP-2. Finally, the user browser is redirected back to SP-2, which then provides the service to the user.
  • Fig.l provides a simplified signaling flow illustrating such a case.
  • IDPl and IDP2 represents servers arranged for providing authentication assertions in, respectively, different COTs: COT-I and COT- 2, and UE represents a user's equipment having a HTTP browser suited for communicating with IDP servers according to LAP specifications.
  • flow 101 the user access to IDPl, which requests back in flow 102 user credentials for authentication.
  • These credentials are provided from the UE in flow 103.
  • the user is successfully authenticated by IDPl, which can cause a confirmation to be sent in flow 104.
  • IDPl the user accesses to IDP2 and, for example, selects an option that comprises federating identity information for his account with another IDP (e.g. the COT-2 offers this service trough server IDP2) .
  • the user might have already a service account with IDP2, or said account could be created within the current session.
  • Flows 106 to 108 represent an authentication of the user before IDP2 similar as described before with reference to flows 102 to 104. If the user requested to IDP2 identity federation with another IDP (e.g.
  • IDP2 can redirect the communication to IDPl and send a federation request comprising an authentication assertion generated for said user and an alias for him (e.g. a SAML message comprising an "AuthRequest” including "Nameld” as an alias to refer to said user hereinafter) in flow 109.
  • IDPl sends back a federation confirmation response to IDPl (e.g. a SAML message comprising an "AuthResponse" including the generated "Nameld” for said user) .
  • the IDP proxying features can open interesting business opportunities especially for telecommunications operators wishing to make more attractive their service offering by including seamless service access to services provided by other operators, as SSO features can be granted between operators having IDP servers as described earlier. This can allow, for example, offering special services to roaming/visiting users, even in a personalized manner.
  • a typical of inter-operator service provisioning scenario as described above can comprise a mobile network operator and a fixed network operator, specially, but not necessarily limited to, the case when both operators are branches of the same mother company.
  • a given user can have subscriptions with both operators, for example for using his mobile terminal everywhere, and for having fixed telephony services and accessing to the Internet trough a Digital Subscriber Line DSL installed at home.
  • both, the fixed network operator and the mobile network operator perform as authentication providers for offering services using LAP identity federation features by implementing separate IDP servers on each network domain.
  • the mechanism described above with reference to Fig.l for linking information of a user between two different IDPs could be not suitable in some cases.
  • the mechanism assumes the federation process is executed by means of a web browser and within the same web session, wherein the user authenticates against both IDPs.
  • a second, and more limiting, assumption is that the user is able to authenticate explicitly before any of those IDPs, and this is commonly due to that access to services in the fixed and the mobile domain is not usually done in the same way.
  • Services in the fixed domain are commonly accessed with a web browser on a personal computer PC, and the user employs usually a username/password pair as credentials to get authenticated against an IDP of the fixed network operator and thus be granted to access the services provided therein
  • the mobile phone e.g. with a Wireless Access Protocol, WAP, browser
  • WAP Wireless Access Protocol
  • the users does not need to explicitly re-authenticate for accessing some services provided therein with credentials such as username and password, since access-network authentication in the mobile network is commonly re-used by the IDP (s) of the mobile operator for this purpose, thus alleviating the user and/or the terminal of running (again) an authentication procedure.
  • an IDP of the mobile operator considers a given user as properly authenticated if he already has been authenticated from his mobile terminal (e.g. via SIM or AKA authentication mechanisms) by the access network and, thus, can grant said user access to some services provided by the -say- service network.
  • the invention relates to a method for linking information of a user between a first and a second server as claimed in claim 1.
  • the invention also relates to servers as claimed in claims 7 and 13, and to computer programs as claimed in claims 18 and 19. Embodiments of the invention are set out in the dependent claims.
  • the method, apparatuses and computer programs of the invention provide a solution for linking information of a user between a first and a second server, each of said servers providing authentication assertions of said user to further service servers.
  • the first server and a first terminal of the user establish a second communication through a messaging server. In the second communication it is used a reference obtained in a previous first communication between a second terminal of the user and the second server. If user consent is received in the second communication, the first and second servers link their information relative to the user by storing a common identifier in relationship with information of said user held respectively in said servers.
  • Accounts of user in domains of different identity authentication providers can be linked in an alternative way, when some assumptions of prior-art techniques can not be accomplished, and without renouncing to user consent.
  • Figure 1 shows a simplified signaling flow illustrating the establishment of an identity federation of digital information of a user between identity providers IDPs of different circle of trust COTs.
  • Figure 2 shows a flowchart illustrating some steps of a method of the invention.
  • Figure 3 shows a simplified signaling flow according to one embodiment of the invention.
  • Figure 4 details the routing of some of the messages illustrated in Fig.3.
  • FIG. 5 shows a simplified signaling flow according to another embodiment of the invention.
  • Figure 6 details the routing of some of the messages illustrated in Fig.5.
  • Figure 7 shows a schematic representation of some functional modules of a server according to one embodiment of the invention.
  • Two communications are established for accomplishing with the linking of user information between two servers, each arranged for providing authentication assertions of said user to further service servers.
  • the first communication is established in step 210 between one of these servers providing authentication assertions IDP2 and a terminal or said user UE2.
  • the second communication is established in step 230 between the other one of these servers providing authentication assertions IDPl and another terminal of said user UEl.
  • a reference is obtained in step 220.
  • Said reference can be generated by any of the communication peers in the first communication UE2, IDP2 and transmitted to the other peer in said communication for further use in the second communication 230.
  • the second communication 230 is used to establish in step 240 a user consent of the user for linking user information between these two servers IDPl, IDP2 by storing therein a common identifier in relationship with digital information of said user held respectively in these two servers in step 250.
  • the method therefore allows combination of two different signaling technologies for accomplishing with digital information linkage in different servers providing authentication information to further service servers for service provision through SSO features.
  • a given signaling technology is not available for all terminals connectable to different authentication providers belonging to different network domains
  • the invention provides a solution wherein a first signaling technology can be used between a first terminal of the user UEl and an authentication server IDPl of a first authentication provider in a first network domain, and a second signaling technology can be used between a second terminal of the user UE2 and an authentication server IDP2 of a second authentication provider in a second network domain.
  • FIGS 3 to 6 shall now be used to illustrate two different embodiments wherein, for the sake of a clearer description, an inter-operator service provisioning scenario comprising a mobile network operator and a fixed network operator is considered as an example in all the cases. Both operators acts act identity providers by means of IDP servers IDPl and IDP2, belonging, respectively, to the network domain of the mobile operator and to the network domain of the fixed operator. The same user is subscribed to both operators and uses: a mobile terminal UEl connectable to the network of the mobile operator, and a personal computer UE2 connectable to the network of the fixed operator.
  • Figures 3 and 4 illustrate an embodiment wherein the initiative for establishing the second communication is taken by the IDP server of the mobile operator network.
  • Flow 301 represents the user accessing to the IDP server IDP2 of his fixed network operator from his terminal UE2 via a web browser, and being authenticated from said server, for example, by means of user identifier and password input by the user in terminal UE2.
  • the example assumes that the user, once authenticated from IDP2, is presented with some services one of which is to federate his user account with another identity provider in which he may have also a service account.
  • the benefits for the user are a seamlessly access to services provided by SPs which trust authentication assertions issued by an IDP server, e.g. IDPl, of said another identity provider, e.g.
  • IDP2 ask the user, e.g. via a HTML form, in flow 302 for an identifier usable to address another terminal of the user connectable to the network domain where the other IDP server IDPl belongs to.
  • the user provides, for example, a Mobile Subscriber Integrated Services Digital Network MSISDN number associated to his mobile terminal UEl.
  • IDP2 sends in flow 304 a SAML "AuthRequest" message requesting federation for a user towards IDPl.
  • the messaging in flow 304 includes the MSISDN provided by said user, for example, as a new attribute in the "AuthRequest” message, as an HTTP header, or by means of any other suitable mechanism.
  • the "AuthRequest” message of flow 304 can also include a "Nameld” as an alias to refer to said user in the name space of IDP2.
  • IDPl establishes a communication with a terminal of the user UEl connectable to its domain for receiving a user consent for the identity federation. This is accomplished in the illustrated embodiment by interactions carried out in flows 305 and 306, which are further detailed in Fig.4. IDPl can use the addressing identifier received in flow 304, e.g. MSISDN, or another usable identifier related to the same user it can obtain from internal or external data storage, e.g. a Home Location Register, or a Home
  • Subscriber Server of the mobile network operator such as a Uniform Resource Identifier URI usable also to address a terminal of the same user connectable to the network of the mobile operator.
  • URI Uniform Resource Identifier
  • IDP IDPl enhanced for accomplishing with this embodiment of the invention is shown in Fig.4, which is suited to communicate with a messaging server MSG SRV in order to send and/or receive short messages SMS, multimedia messages MMS, or any other kind of information messages that can be exchanged with a user terminal.
  • the IDP server main (say, standard) functional unit IDP-m of server IDPl is further provided with a messaging originating functional unit MT-OUT and with a messaging terminating functional unit MT-IN.
  • the messaging server MSG SRV is a SMS service centre
  • MT-OUT and MT-IN units can be adapted to exchange signaling according to short message peer-to-peer protocol SMPP.
  • the messaging server MSG SRV is a MMS service centre
  • MT-OUT and MT-IN units can be adapted to exchange SOAP over HTTP messages, as standardized for the so called "MM7" interface.
  • Flow 305 then comprises initially a first (e.g. internal) request MTl to send a mobile terminating short message to the MT-OUT unit of IDP- 1. This causes the MT-OUT unit to generate a request MT2 to the messaging service centre MSG SRV, which finally forwards the message MT3 to the terminal of the user UEl.
  • a first request MTl e.g. internal
  • MSG SRV messaging service centre
  • the IDPl ask the user for his consent for identity federation with another IDP, IDP2.
  • a reference identifier can be included in the message, so as to facilitate in IDPl a correlation between the message sent in flow 305 with a subsequent reply of terminal UEl, flow 306.
  • a mobile originating short message MOl sent towards the service centre MSG SRV, which can include the reference identifier cited above.
  • MO-IN unit which delivers it to functional unit IDP-m, which shall take care of the consented identity federation.
  • the IDPl can associate the interaction with UEl by using an identifier of said terminal received in the messaging flow 306.
  • IDPl sends in flow 307 a standard SAML "AuthResponse" to IDP2 containing the newly created "Nameld", which, from that point on, is shared between both servers, IDPl and IDP2, in relationship with the involved user by storing it in relationship with digital information they respectively store with regard to said user.
  • Flow 308 represents an optional confirmation sent towards the user via his terminal UE2, which notifies the success of the identity federation operation. Alternatively, or additionally, a similar confirmation could be sent from IDPl to UEl (not shown in Fig.5) .
  • Figures 5 and 6 illustrate another embodiment wherein the initiative for establishing the second communication is taken by the user via a terminal UEl connectable to the network of the mobile operator, and wherein the user does not need to reveal his identifier in one of the network, or COT, domains, e.g. his MSISDN to an IDP in the another network, or COT, domain.
  • Flow 501 is equivalent to flow 301 described earlier with reference to Fig.3, and represents the user accessing to the IDP server IDP2 of his fixed network operator from his terminal UE2 via a web browser, and being authenticated from said server, for example, by means of user identifier and password input by the user in terminal UE2.
  • the example illustrated in Fig.5 assumes that the user, once authenticated from IDP2, is presented with a service that comprises federating his user account with another identity provider in which he may have also a service account. This can be accomplished, for example, by sending in flow 502 a HTML page towards the user's browser on terminal UE2.
  • the information sent in flow 502 can comprise a code generated by IDP2 for this service and this user, for example, some kind of one-time password which is uniquely associated in IDP2 to the concerned user and the offered service.
  • This code can later be used by IDP2 to correlate the service offered in flow 502 to the user of terminal UE2 with an eventual further transaction with said another identity provider comprising said code, so as to determine a user consent of said user for said service. That is, the IDP2 creates a code, and checks it later in order to validate a subsequent federation request if it comprises said code.
  • the communication in flow 502 can also comprise an identifier usable to address the corresponding another identity provider through a messaging server, for example, a MSISDN usable to address a SMS towards IDPl.
  • the illustrated example considers that the user consents in the account federation and, for indicating so, he establishes from his terminal UEl a communication with the concerned IDP server IDPl in flow 503.
  • an identifier of IDPl received from IDP2 can be used for addressing purposes.
  • UEl includes the code received in UE2 from IDP2, so as to indicate user consent for federating user's identity in both IDPs.
  • an IDP enhanced to accomplish with this embodiment of the invention needs only be suited with messaging receiving capabilities for MMS and/or SMS.
  • flow 503 comprises the establishment of a communication between UEl and IDPl via e.g. Short Message Service SMS sent from the user equipment
  • the SMS sent by UEl MOl is received in the messaging server MSG SRV and forwarded towards IDP2, as illustrated by flow MO2.
  • the SMS is received by the MO-IN unit and delivered to functional unit IDP-m in M03, which further process it.
  • the standard (e.g. according to LAP specifications) processing functionality of the server IDPl can be enhanced so as to start the invocation of an identity federation against another IDP server upon reception of a SMS or MMS message of a user by using a certain reference included in said message.
  • the account federation service is supposed to be run between two known IDP servers (e.g. both belong to the same company branch: one of them belong to the network domain of the company's mobile network operator, and the other one belongs to the network domain of the company's fixed network operator), then an identifier of the IDP to which IDPl should further contact so accomplish with the service might be redundant. However, if this is not the case, preferably, communication in flow 502 further comprises an identifier usable to address a communication to IDP2 from IDPl, which should then be included in flow 503 by UEl. In flow 504 IDPl sends a "AuthRequest" message requesting federation for a user towards IDP2.
  • the messaging in flow 504 includes the code received in flow 503, which was generated by IDP2, for example, as a new attribute in the "AuthRequest” message, as an HTTP header, or by means of any other suitable mechanism.
  • the "AuthRequest” message of flow 504 can also include a "Nameld” parameter with an alias to refer to said user.
  • the IDP2 verifies that the received code was generated and delivered for certain user, flow 502, for an inter-COT federation process, and determines that a user consent was issued by said user for said federation.
  • IDP2 sends in flow 505 a standard SAML "AuthResponse" to IDPl, confirming the approval of the federation service, and containing the newly created "Nameld", which, from that point on, is shared between both servers, IDPl and IDP2, in relationship with the involved user by storing it in relationship with digital information they respectively store with regard to said user.
  • Flow 506 represents an optional confirmation sent towards the user via his terminal UEl, which notifies the success of the identity federation operation. Alternatively, or additionally, a similar confirmation could be sent from IDP2 to UE2 (not shown in Fig.5) .
  • any of the described embodiments of the invention makes possible to create inter-COT/domain federation for a user between different IDPs, wherein at least one of them (e.g. IDPl in the illustrated figures) does not need to create, store, distribute and maintain passwords as credentials for their users for use in explicit authentications.
  • IDPl in the illustrated figures
  • the invention allows utilization of existing messaging resources in the domain of the mobile network operator, such as SMS or MMS, which does not require any specific modification in a simple mobile terminal.
  • a server in a telecommunications system that deals with signaling related to service provision can, regardless specific construction details, be considered as an apparatus comprising of one or more functional modules; each of them arranged to perform a specific (sub) function of the total functionality implemented by said server.
  • a server such as an IDP server
  • the construction of the functional modules to build up a realization of the corresponding physical machine (s) accomplishing said server is a matter of routine work for those skilled in the art.
  • a IDP server implemented as a computer-based apparatus comprises software and hardware, and can be implemented within a single physical machine, or be distributed along various cooperating physical machines.
  • the software comprise one or more computer programs having computer readable program code that, when executed by a computer-based IDP server makes it to behave according to a predefined manner, as determined by the specific program instructions in said programs, which is in accordance to the standardized functionality specified for it, and which can be modified as described earlier according to any of the embodiments of the inventions.
  • the simplified internal structure shown in Fig.7 for an IDP server IDPl or IDP2 comprises: a processing module 701, a communications module 702, a data storage module 703 and internal communication bus 704 which allow data communication and cooperation between them.
  • the processing module 701 requests the communications module 702 to send the message and provides it with the necessary data, and, when a signaling message is received by the communications module, it transfers the relevant content to the processing module for triggering the necessary processing.
  • the processing module 701 accesses the data storage module 703 to store/update/check/obtain the necessary data for the operation.
  • the processing module 701 can comprise one or more processors, only one processor 7010 is shown in Fig.2, which, for example, can be arranged to work in load-sharing or active-backup mode.
  • the operation in server IDPl or IDP2 is controlled by computer-readable program code comprising instructions that are executed by processor 7010. The execution of these instructions makes IDPl or IDP2 to perform according to their standardized functions, which are improved according to embodiments of the invention described hereinbefore.
  • communications module 702 illustrated in Fig.7 as comprising two communication devices 7021 and 7022.
  • a communication device can be suited to accomplish with one or more than one communication types (i.e. communications according to one or more communication protocols and/or signaling interfaces) .
  • functional units MT-OUT or MO-IN, depicted in figures 4 and 5 can be implemented partially or totally by communication devices 7021 and/or 7022.
  • Data storage module 703 stores the data needed for the operation of IDPl or of IDP2.
  • a data storage module in a computer-based server can comprise one or more data storage devices. In the example illustrated in Fig.7 it comprises storage devices 7031 and 7032. Memory chips and magnetic or optical discs are example of data storage devices. Depending on criteria such as data access speed for certain data, storage reliability, etc, the storage module of a IDP server can comprise one or more storage devices of the same or different kind.
  • Data storage module 703 can store the computer-readable program to be executed by processor 7010, as well as the information related to the users served from the IDP server, such as: credentials, shared identifiers with other SPs and IDPs, authentication status of these users, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention porte sur un procédé, des appareils et des programmes d'ordinateur pour lier des informations d'un utilisateur entre un premier et un second serveur fournissant des assertions d'authentification dudit utilisateur à d'autres serveurs de service. Le premier serveur et un premier terminal de l'utilisateur établissent, par l'intermédiaire d'un serveur de messagerie, une seconde communication (230). Dans la seconde communication, une référence obtenue (220) dans une première communication antérieure (210) entre un second terminal de l'utilisateur et le second serveur est utilisée. Si un consentement d'utilisateur (240) est reçu dans la seconde communication, les premier et second serveurs lient leurs informations relatives à l'utilisateur par stockage (250) d'un identifiant commun en relation avec des informations numériques dudit utilisateur conservées respectivement dans lesdits serveurs. Des comptes d'utilisateur dans des domaines de différents fournisseurs d'authentification d'identité peuvent être liés d'une autre façon, lorsque certaines hypothèses des techniques antérieures ne peuvent pas être accomplies, sans renoncer au consentement de l'utilisateur.
PCT/EP2007/060687 2007-10-09 2007-10-09 Procédé, appareils et programmes d'ordinateur pour lier des informations d'un utilisateur entre des serveurs fournissant des assertions d'authentification WO2009046758A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2007/060687 WO2009046758A1 (fr) 2007-10-09 2007-10-09 Procédé, appareils et programmes d'ordinateur pour lier des informations d'un utilisateur entre des serveurs fournissant des assertions d'authentification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2007/060687 WO2009046758A1 (fr) 2007-10-09 2007-10-09 Procédé, appareils et programmes d'ordinateur pour lier des informations d'un utilisateur entre des serveurs fournissant des assertions d'authentification

Publications (1)

Publication Number Publication Date
WO2009046758A1 true WO2009046758A1 (fr) 2009-04-16

Family

ID=39734204

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/060687 WO2009046758A1 (fr) 2007-10-09 2007-10-09 Procédé, appareils et programmes d'ordinateur pour lier des informations d'un utilisateur entre des serveurs fournissant des assertions d'authentification

Country Status (1)

Country Link
WO (1) WO2009046758A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7788700B1 (en) * 2002-05-15 2010-08-31 Gerard A. Gagliano Enterprise security system
JP2013125410A (ja) * 2011-12-14 2013-06-24 Fujitsu Ltd 認証処理プログラム、認証処理方法、及び認証処理装置
US8620927B2 (en) 2010-06-28 2013-12-31 International Business Machines Corporation Unguided curiosity in support of entity resolution techniques
JP2014507837A (ja) * 2011-01-04 2014-03-27 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ローカルメディアレンダリング

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1191763A2 (fr) * 2000-09-22 2002-03-27 Roke Manor Research Limited Système d'authentification d'accés pourun environnement sans fil
US20070136786A1 (en) * 2005-12-08 2007-06-14 Sun Microsystems, Inc. Enabling identity information exchange between circles of trust

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1191763A2 (fr) * 2000-09-22 2002-03-27 Roke Manor Research Limited Système d'authentification d'accés pourun environnement sans fil
US20070136786A1 (en) * 2005-12-08 2007-06-14 Sun Microsystems, Inc. Enabling identity information exchange between circles of trust

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HUGHES J ET AL: "Security Assertion Markup Language (SAML) V2.0 Technical Overview; Working Draft 08", OASIS INTERNET CITATION, 12 September 2005 (2005-09-12), pages 1 - 51, XP002430692, Retrieved from the Internet <URL:http://www.oasis-open.org/committees/download.php/14361/sstc-saml-tech-overview.2.0-draft-08.pdf> [retrieved on 20070424] *
THOMPSON P, CHAMPAGNE D, ET AL: "Liberty ID-FF Implementation Guidelines", LIBERTY ALLIANCE PROJECT, 20 May 2005 (2005-05-20), pages 1 - 34, XP002495879, Retrieved from the Internet <URL:http://www.projectliberty.org/liberty/content/download/1266/8160/file/liberty-idff-1.2-20050520.zip> [retrieved on 20080915] *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7788700B1 (en) * 2002-05-15 2010-08-31 Gerard A. Gagliano Enterprise security system
US20110040965A1 (en) * 2002-05-15 2011-02-17 Gerard A. Gagliano Enterprise security system
US8359465B2 (en) 2002-05-15 2013-01-22 Gerard A. Gagliano Enterprise security system
US8984601B2 (en) 2002-05-15 2015-03-17 Gerard A. Gagliano Enterprise security system
US8620927B2 (en) 2010-06-28 2013-12-31 International Business Machines Corporation Unguided curiosity in support of entity resolution techniques
JP2014507837A (ja) * 2011-01-04 2014-03-27 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ローカルメディアレンダリング
US8994782B2 (en) 2011-01-04 2015-03-31 Telefonaktiebolaget L M Ericsson (Publ) Local media rendering
US9560096B2 (en) 2011-01-04 2017-01-31 Telefonaktiebolaget Lm Ericsson (Publ) Local media rendering
JP2013125410A (ja) * 2011-12-14 2013-06-24 Fujitsu Ltd 認証処理プログラム、認証処理方法、及び認証処理装置

Similar Documents

Publication Publication Date Title
CN106105091B (zh) 身份识别和访问管理
JP7035163B2 (ja) ネットワークセキュリティ管理方法および装置
US8819800B2 (en) Protecting user information
EP3120591B1 (fr) Dispositif sur la base d&#39;un identifiant d&#39;utilisateur, système de gestion d&#39;identité et d&#39;activité
US7882346B2 (en) Method and apparatus for providing authentication, authorization and accounting to roaming nodes
KR100644616B1 (ko) 마크업 랭귀지 기반의 단일인증 방법 및 이를 위한 시스템
JP5582544B2 (ja) ネットワークプロバイダ経由でサービスプロバイダへのネットワークアクセスをユーザに提供するシステムおよびその動作方法
JP4782139B2 (ja) モバイルユーザーをトランスペアレントに認証してウェブサービスにアクセスする方法及びシステム
US10594695B2 (en) Authentication arrangement
EP2648392A1 (fr) Système de routage d&#39;interface de programmation d&#39;application et son procédé de fonctionnement
CN105981345B (zh) Wi-fi/分组核心网接入的合法侦听
WO2010094331A1 (fr) Authentification auprès d&#39;un fournisseur d&#39;identité
WO2013019261A1 (fr) Authentification unique (sso) multi-saut pour un serveur mandataire/itinérance de fournisseur d&#39;identité (idp)
US9210142B2 (en) Method for providing internet services to a telephone user
US9241264B2 (en) Network access authentication for user equipment communicating in multiple networks
WO2011098660A9 (fr) Procédé et appareil de redirection de trafic de données
CN103023856A (zh) 单点登录的方法、系统和信息处理方法、系统
CN103856454A (zh) Ip 多媒体子系统与互联网业务互通的方法及业务互通网关
WO2009046758A1 (fr) Procédé, appareils et programmes d&#39;ordinateur pour lier des informations d&#39;un utilisateur entre des serveurs fournissant des assertions d&#39;authentification
US8549089B2 (en) Method for sending messages to a mobile telephone
TWI246300B (en) Method and apparatus enabling reauthentication in a cellular communication system
CN116996316A (zh) 一种即联即用的服务认证系统及方法
EP2399408A1 (fr) Authentification auprès d&#39;un fournisseur d&#39;identité

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: 07821058

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07821058

Country of ref document: EP

Kind code of ref document: A1