METHOD, APPARATUSES AND COMPUTER PROGRAMS FOR LINKING

INFORMATION OF A USER BETWEEN SERVERS PROVIDING

AUTHENTICATION ASSERTIONS

FIELD OF THE INVENTION

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 .

BACKGROUND

Currently, a user can access to a great variety of services offered through state-of-the-art telecommunications systems. 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. In general terms, a service provider (SP) 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 .

Depending on different business models, 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. For example, 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. 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. Similarly, 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.

While some services can be provided by a SP on a -let's say- common general basis to any user (e.g. a general information service), some other services could be subject to a previous identification of the served user. This can be the case when, for example, 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.

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). However, under user's point of view, 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.

Recent developments have addressed to this problem and provided identity federation frameworks that allow, among other, what is commonly known as Single Sign On (SSO) . In short, SSO allows the users to securely access different services, which can be accessed through SPs that can be even dispersed across different networks or administrative domains, without being authenticated every time. The current principle behind SSO states that, for a given session, users shall be able to authenticate once, and then, shall be given access to a plurality of services that accept such level of authentication. This principle enables a user to establish a communication session and to access different services without explicitly authenticating for each particular different service he might request.

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. To accomplish with this purpose, for a given user, such a server (IDP 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. In this context, an authentication assertion comprises digital information that asserts to the receiver that the referred subject has been properly authenticated. The Security Assertion Markup Language (SAML) is commonly used to convey authentication assertions between IPDs and SPs. Hypertext Transfer Protocol (HTTP) and Simple Object Access Protocol (SOAP) are the usual protocol binding for exchanging SAML messages .

For example, the "Liberty Alliance Project" (LAP) (http://www.projectliberty.org/) is a forum for the standardization of identity federation frameworks. The tutorial "Liberty Specs Tutorial"

(http : //www. projectliberty. org/liberty/content/downIoad/423 /2832/file/tutorialv2. pdf) provides a general overview of the features in an identity federation framework. In particular, 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. In short, 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.

The set of SPs a user can federate his identity is usually called as "Circle Of Trust" (COT) in LAP terminology. The basic deployment of identity federation frameworks foresees COTs having a single IDP and a number of SPs. An eventual COT scenario is that of a telecommunications network operator playing the role of authentication provider IDP (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) , and a number of own or 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. In this kind of scenario, 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. Instead IDP proxying mechanism is provided by LAP. In short, the mechanism operates as follows .

First, 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.

The LAP document "Liberty ID-FF Implementation Guidelines" (http : //www. projectliberty. org/liberty/content/download/322 /2378/file/liberty-idff-guidelines-vl .2.pdf) provides, for example in chapter 6.2.4, some details related to the IPD proxying mechanism. As stated therein, the user ("principal" in some LAP terminology) will necessarily have had to federate accounts in both: IDPl and IDP2.

Although the establishment of a identity federation of a user between IDPs of different COTs is not disclosed by the aforementioned LAP document, it can be envisaged that a similar mechanism as for federating digital identity of a user between a SP and a IDP in a single COT (as referred above) can be used. Fig.l provides a simplified signaling flow illustrating such a case. In Fig.l, 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.

In flow 101 the user access to IDPl, which requests back in flow 102 user credentials for authentication. These credentials (e.g. user identifier and password) 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. In flow 105 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. IDPl), then 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. In flow 110 IDPl sends back a federation confirmation response to IDPl (e.g. a SAML message comprising an "AuthResponse" including the generated "Nameld" for said user) . After that, information stored in both IDPs related to said user is linked by storing a common identifier (alias, "Nameld") agreed during said communication, so that authentication assertions can be generated for him when authenticated, either: locally in one of said IDPs, or from the other IDP.

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. In this situation, 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. Also, in this scenario, 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.

However, 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. For example, 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, In the mobile domain, the mobile phone (e.g. with a Wireless Access Protocol, WAP, browser) is commonly the device used to access services, and 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. Namely, 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.

It should be therefore desirable to devise mechanisms for linking information of a user between different IDP servers that suits for most of the scenarios and type of users.

SUMMARY

In one aspect, the invention relates to a method for linking information of a user between a first and a second server as claimed in claim 1. In further aspects, 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.

BRIEF DESCRIPTION OF THE DRAWINGS

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.

Figure 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.

DETAILED DESCRIPTION Exemplary embodiments of the invention shall now be described with reference to figures 2 to 7.

Some steps of the method of the invention are illustrated in a generic way in Fig.2, which shall be later detailed in the description provided for the particular embodiments illustrated in figures 2 to 6. 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. Within the first communication 210 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. When 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. Accordingly, accounts of a user in domains of different authentication providers can be linked without limitations as the ones cited before with reference to Fig.l, thereby allowing the use of different kind of terminals, which need not have the same signaling capabilities, for accomplishing with that purpose.

Figures 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. SPs that belong to the COT of IDPl, which will not require him to re-run an authentication if he has already been authenticated by IDP2, and vice versa.

In the illustrated example 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. In flow 303 the user provides, for example, a Mobile Subscriber Integrated Services Digital Network MSISDN number associated to his mobile terminal UEl. Subsequently, 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.

Next, 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.

An 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. For this purpose, 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. For example, if 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. If, for example, 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.

For the sake of illustration, SMSs are assumed to be exchanged between IDPl and UEl. 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. By means of the suitable text in the message MTl, MT2, MT3 the IDPl ask the user for his consent for identity federation with another IDP, IDP2. Also, 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. If the user consents, he answers by means of a mobile originating short message MOl sent towards the service centre MSG SRV, which can include the reference identifier cited above. Then a message M02 is delivered from service centre MSG SRV to its destination and is received by MO-IN unit, which delivers it to functional unit IDP-m, which

shall take care of the consented identity federation. Optionally, if no correlating reference identifier is included in the flows 305, 306, the IDPl can associate the interaction with UEl by using an identifier of said terminal received in the messaging flow 306. Next, 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. For accomplishing with this, an identifier of IDPl received from IDP2 can be used for addressing purposes. In said communication, UEl includes the code received in UE2 from IDP2, so as to indicate user consent for federating user's identity in both IDPs.

As shown in Fig.6, an IDP enhanced to accomplish with this embodiment of the invention, needs only be suited with messaging receiving capabilities for MMS and/or SMS. Therefore, it is illustrated as comprising only a messaging terminating functional unit MT-IN adapted to exchange signaling with a SMS or MMS messaging server MSG SRV so as to receive SMS or MMS messages. Therefore, if 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. For example, 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.

If, for example, 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. At reception of the flow 504, 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. Accordingly, 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. This is a major advantage when the federation scenario comprising a

IDP of a mobile operator, which, as mentioned earlier, does not explicitly authenticate their users to provide authentication assertions to another SPs of its COT, but that commonly re-use previous authentication of the user terminal provided by the access network. Instead, 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.

The internal simplified structure of a server IDPl, IDP2 for providing authentication assertions of a user to a service server shall now be described with reference to Fig.7 considering a possible implementation as a computer- based apparatus .

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. Once the functionality of a server, such as an IDP server, has been defined (e.g. by a telecommunications standard, or some other document) , 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.

In particular, 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. Accordingly, the description given herein with reference to Fig.7 shall describe some functional components of a IDP, IDPl or IDP2, adapted to accomplish with said functionality, without falling into specific hardware and software construction details, which are well known by those skilled and, consequently, which are not needed to understand the invention.

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. In general, when a signaling message is to be sent, 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. In turn, 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.

Currently, most of the telecommunications nodes and servers are implemented by computer-based apparatuses. Accordingly, computer programs comprising computer-readable program codes are loaded in computer-based apparatuses of telecommunications systems causing them to behave according to a predefined manner, as determined by the respective program codes, which are in accordance to the specific functionality specified for the servers/nodes these apparatuses implement. Thus, those skilled in creating and/or modifying computer programs, would, without departing of the teachings of the present invention, readily apply them to create and/or modify computer programs suitable to be loaded in a computer-based IDP server, so as to make it to behave according to any of the described embodiments.

External communications are performed via communications module 702, illustrated in Fig.7 as comprising two communication devices 7021 and 7022. Depending on different implementation alternatives, 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) . For example, 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.

The invention has been described with respect to some exemplary embodiments in an illustrative and non- restrictive manner. Variations can be readily apparent to those of ordinary skill in the art. For this reason, the invention is to be interpreted and limited in view of the claims .