WO2005050422A1 - Appareil permettant de fournir un service dans un cadriciel de federation d'identites - Google Patents

Appareil permettant de fournir un service dans un cadriciel de federation d'identites Download PDF

Info

Publication number
WO2005050422A1
WO2005050422A1 PCT/SE2004/001559 SE2004001559W WO2005050422A1 WO 2005050422 A1 WO2005050422 A1 WO 2005050422A1 SE 2004001559 W SE2004001559 W SE 2004001559W WO 2005050422 A1 WO2005050422 A1 WO 2005050422A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
service
identity
contact information
request
Prior art date
Application number
PCT/SE2004/001559
Other languages
English (en)
Inventor
Carolina Canales Valenzuela
Maria Esther Bas Sanchez
John Michael Walker
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)
Publication of WO2005050422A1 publication Critical patent/WO2005050422A1/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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations

Definitions

  • the present invention relates to the provision of services in an identity federation framework and, more precisely to the apparatuses involved in said provision.
  • SPs service providers
  • Many SPs allow users the possibility to have accounts with them. Indeed, depending on the service offered, it is often required to have a service account at a given SP.
  • the access to a given SP may require users to authenticate themselves towards that SP. In other words, users must be able to prove who they are. This commonly achieved by providing an "identity" to each user; wherein said identity can comprise credentials for authentication and identification purposes (e.g. an identifier, such as a username, to identify said user and a password) .
  • the identity of a user in a given SP can further comprise some additional attributes which can be, for example, needed to shape or characterize the content of a given service to said user (e.g. a record of user preferences and settings), and/or personal or profile data related to said user (e.g. particular address, e-mail identifier, employer name, title, etc) which the SP can request to the user when his account is created.
  • additional attributes can be, for example, needed to shape or characterize the content of a given service to said user (e.g. a record of user preferences and settings), and/or personal or profile data related to said user (e.g. particular address, e-mail identifier, employer name, title, etc) which the SP can request to the user when his account is created.
  • a given user may have service accounts at a plurality of SPs, wherein, as stated above, each SP has an identity for said user which comprises information related to said user which can be confidential and/or which could not be used or disclosed without the user's consent.
  • information related to an identity of a user in a SP that is intended to be confidential are, for example, the credentials used to authenticate said user in said SP (e.g. his password or the combination of his username and password) .
  • SSO Simple Sign-On
  • IdP Identity Provider
  • LAP is an is an industry forum founded in 2001 to establish an open standard for federated network identities; wherein the term network identity refers to the global set of attributes that are contained in an user's various accounts with different SPs, namely, the global set of attributes contained in the individual "identities" said user has across a plurality of SPs.
  • LAP released a set of specifications to allow the, so called, "Identity Federation Framework” ID-FF in a, so called, "Circle of Trust” CoT; wherein a CoT comprises an IdP and a plurality of SPs which can share, for a given user, a set of linked (federated) identities of said user through said IdP.
  • a given user may or may not have a service account on each SP of a CoT; so, a given SP can offer a service to a user who does not have a previous service account with it provided that, for example, said SP delegates the authentication of said user to an IdP and the IdP asserts said authentication to this SP.
  • the term "principal” is used to refer to an entity that can acquire a federated identity, wherein a "principal” can be: a human user, a group of human users, a corporation, a legal entity, etc. Since all those types of "principals" are actually "users" of the identity federation, the term “user” shall be used in this application to refer indistinctly to a user of the identity federation, regardless his/its type.
  • a user first access to a given SP , e.g. via a web browser, and request a given service said SP provides. Then, the user's browser is redirected from the SP to the corresponding IdP. Once in the IdP, and if he had not previously be authenticated, or if a previous authentication for this user is not yet valid (e.g. it has elapsed), the user is authenticated using his normal credentials at said IdP (e.g. by means of user identity and password) . In either case: if the user has successfully authenticated now, or if the user already had a previous valid authentication, his browser is redirected back to the SP.
  • Said redirection comprises a reference to said authentication (called “artifact” in LAP terminology) that can be used by the SP to further obtain some data (called “assertion” in LAP terminology) from the IdP related to said authentication so as to allow said user to access the service he has requested; although, alternatively, the IdP can include directly the “assertion” in the redirection.
  • a given user can have one or more service accounts in various SPs of a CoT, can be identified by a different identifier on each of said SPs.
  • the account federation process for an account of a user in an SP comprises an interaction between the SP and the IdP, in which an alias to reference said user is agreed.
  • said alias is not the identifier that is assigned to said user in said SP, but a kind of identifier usually known as "pseudonym".
  • a given user can be identified in the SP "SPl” by an identifier such as "John_Doe@SPl” , and be identified with "JonnyD@IdPa” in the IdP "IdPa”, whilst a pseudonym such as "mr3Tj#455a” can be used between SPl and the IdPa to identify to (refer to) this user.
  • an IdP stores all the pseudonyms which can be utilized to refer to said user by the plurality of SPs in a CoT where said user has a service subscription that has been federated; therefore, the identity of a user in a SP is unknown for another SPs where said user can have a service account.
  • an identity federation framework (as the one disclosed by LAP) also envisages the, so called, "identity services", which, in short, are services that consider the consumption of attributes of federated identities of users across SPs. Accordingly, a given SP can offer a given service to a user which might need the consumption of an attribute of the (network) identity of said user (e.g. his credit card number, data about his calendar, etc) that can be stored, for example, in another SP.
  • identity services e.g. his credit card number, data about his calendar, etc
  • Said “consumption” can comprise, not only the retrieval and/or updating of said attributes, but also the performance of some action on the benefit of an identity (e.g.: an attribute of an identity of a user in a SP comprises his mobile phone number, being the action to send a Short Message to this number from this SP) .
  • ID-WSF provides, together with an standardized description of the identity services and the method to access them, the so called “Discovery Service” DS which allows a given SP (e.g. "SPl") to dynamically discover a user's registered identity services.
  • the entity providing the DS (that can be an IdP or a specific SP) stores, per user, information about the SPs hosting identity services for this user, as well as the references that are usable in each of said SPs to point out to said identity services (i.e.: in a particular SP this reference is usable to find out the attribute (s) of an identity of said user that can be shared for other services) .
  • identity attributes of a user can be stored, not only in SPs (as described here by way of example as identity services providers) , but in another kind of entities which acts as mere identity data providers .
  • the information stored for a given user in the DS shall be referred hereinafter as the "resource offering" RO for said user.
  • resource offering entries there can be a plurality of resource offering entries for a given user in the DS, one per identity service of said user, wherein each entry can contain information about the SP hosting the corresponding attribute (s) , as well as the aforementioned reference usable to find out said attribute (s) in said SP.
  • the IdP In addition to the plurality of pseudonyms federated for a user through a plurality of SPs, to accomplish with ID-WSF the IdP also stores, in relationship with said federated pseudonyms, an information (hereinafter referred as "contact information") usable to address in the DS all the RO of said user; being the "contact information" of a user delivered from the IdP to an SP when a SSO process is run in said SP for said user (e.g.: delivered within the "assertion" for said user) . Also, to accomplish with ID-WSF, the DS is arranged to receive discovery look-up operations from an SP which ask for information to find the entity (e.g.
  • a given user can have an account with a SP (e.g.: SPl) which is a bank that holds data about his credit card account.
  • SP e.g.: SPl
  • This user also has a calendar service with another SP (e.g.: SP2) where he stores his calendar appointments, meetings, etc.
  • another SP e.g.: SP3
  • the DS contact information for user-x is obtained by SP3 from the IdP as a part of the SSO authentication procedure which takes place for this user-x between SP3 and the IdP. Then, when user-x request the flight booking service in SP3, said contact information is used to query from SP3 to the DS to obtain the RO that corresponds to the "credit card” service and to the "calendar service" of user-x.
  • SP3 can also contact with SP2 and e.g. obtains user availability information and/or sets an appointment on his calendar and/or marks the flying time as "unavailable" .
  • An identity framework as the one defined by ID-FF and ID-WSF regards mechanisms for protecting user privacy that, as cited earlier, include the use of pseudonyms when two parties (e.g. two SPs, a SP and a IdP, etc) interact regarding a user; such that the user's actual identifiers (either: pseudonyms or user identifiers) at either party is not known to the other party.
  • a SP (such as "SP3" in the example above) that consumes attributes of a given user stored in another SP (such as "SPl” in the example above) does not get to the user identifier of this user in the IdP, nor any user identifier or pseudonym of this user in any other SP or IdP.
  • SP3 only gets a reference usable in the DS to point out the corresponding RO of the user in the DS, and a reference usable to point out the corresponding attribute (s) in SPl and/or in SP2.
  • the identity services model works well when a user is doing things on his own behalf.
  • this known framework regards only a situation wherein a given user accesses a SP that provides a service which needs to consume (e.g. retrieve, update, etc) an attribute of the identity of this user which is stored e.g. in another SP.
  • the offering of services which can involve, not only to the user who requests the service, but another user (or users) , and thus, which can involve the consumption of attributes of said another user(s).
  • the known privacy mechanisms in this federation scenario would preclude this kind of services, since, otherwise, a given SP could relate some data of a given user (e.g. his calendar data, or his visa number) with an identifier of this user in another SP or on his IdP, and, for example, use this relationship later to make unauthorized profiling of this user, or use it for any other unauthorized purpose.
  • a detailed control in the provision of the resource offering pertaining to a given user and concerned for a service which is going to be served to another user is achieved by an apparatus as claimed in claim 14 in cooperation with a Service Provider as claimed in claim 1.
  • the invention relates to an apparatus for providing a service from a Service Provider in an identity federation framework.
  • the apparatus has: means to receive a service request from a first user requesting a service, means to obtain a first resource offering in relationship with an identity service of said first user by using first contact information associated to said first user obtained as a result of his authentication by an Identity Provider, and means to provide said service to said first user.
  • the apparatus for providing a service from a Service Provider further comprises: means to request a second contact information in relationship with a private identifier of a second user, means to obtain a second resource offering in relationship with said second contact information, and means to request a service action for an attribute in relationship with said second resource offering.
  • the means to request said second contact information in relationship with said private identifier can vary according to various embodiments.
  • said means to request said second contact information comprise means to redirect said second user to an Identity Provider to enter said private identifier in said Identity Provider.
  • said means to request said second contact information comprise means to receive said private identifier encrypted in a service request from said first user, and means to send an acquaintance request to an Identity Provider comprising said received encrypted private identifier.
  • the second contact information obtained in either case (in a new redirection from the Identity Provider, or in an acquaintance response) can be utilized to send a discovery look-up to a Discovery Service server entity to obtain the corresponding second resource offering.
  • the invention in another aspect, relates to an Identity Provider apparatus in an identity federation framework having: means to store a plurality of pseudonyms of a first user federated through a plurality of Service Providers, means to store contact information in relationship with said plurality of federated pseudonyms and usable to obtain a resource offering for an identity service of said first user, and means to authenticate said first user when accessing a Service Provider and to provide said contact information to said Service Provider as a result of said authentication.
  • a Service Provider In order to allow the provision of a service to a second (referencing) user which involves the consumption of identity attributes of said first
  • an Identity Provider apparatus further comprises: means to store a private identifier of said first user in relationship with the contact information of said first user, means to receive a contact information request requesting the contact information in relationship with said private identifier of said first user in order to provide a service to a second user in a Service Provider, and means to provide said contact information at reception of said request.
  • the means to receive the contact information request and the means to provide said contact information at reception of said request can vary according to various embodiments.
  • the Identity Provider apparatus comprise: means to receive a redirection of said second user from the Service Provider which provides a service to said second user, means for receiving said private identifier from said redirected second user, and means to redirect said second user back to said redirecting Service Provider; wherein said redirection comprises the requested contact information corresponding to the referenced first user.
  • the Identity Provider apparatus comprise: means to receive an acquaintance request containing said private identifier from a Service Provider which provides a service to said second user, and means to send an acquaintance response back to said Service Provider which comprises said contact information.
  • the Identity Provider apparatus can further comprise means to decrypt a received encrypted private identifier .
  • an Identity Provider apparatus further comprises means to send an acquaintance request to another Identity Provider apparatus containing a private identifier received, either: in a redirection of a second user, or in an acquaintance request, if no contact information is stored in this Identity Provider apparatus in relationship said private identifier.
  • a private identifier of a given user can be stored in an Identity Provider apparatus according to various embodiments.
  • a private identifier of a given user can be provisioned by an operation and maintenance operation as one more user's related data in the Identity Provider apparatus.
  • an Identity Provider apparatus can further comprise means to receive said private identifier from an identity service registration from a Service Provider providing an identity service to said user.
  • an Identity Provider apparatus can further comprise means to receive a private identifier for a user entered in said Identity Provider apparatus from said user.
  • an Identity Provider apparatus can further store the private identifier of a first user in relationship with one or more identifiers of: one or more allowed Service Providers, one or more allowed second users, and one or more identifiers of services which can be provided to said allowed second users which are allowed to obtain the corresponding contact information stored in relationship with said private identifier.
  • the Identity Provider apparatus can be further arranged to check whether or not to provide said contact information by checking one or more conditions concerning: the Service Provider which is going to serve a service to a second user, the identity of said second user, and the concrete service that is going to be served to said second user.
  • the invention relates to an apparatus for providing a Discovery Service in an identity federation network having: means to store a resource offering in relationship with an identity service of a first user, means to receive a discovery look-up request from a Service Provider to provide a service to said first user, and means to provide said resource offering at reception of said discovery look-up request.
  • said resource offering is further stored in relationship with various identifiers selected from: the identifiers of the Service Providers allowed to request said resource offering for providing a service to a second user, and the identifier of the allowed second users.
  • the apparatus for providing a Discovery Service can be further arranged to check whether a Service Provider sending said discovery look-up request is an allowed Service Provider, and/or whether said second user is an allowed second user; to determine whether or not said resource offering can be provided.
  • an identity federation framework can be offered identity services which need not to be limited to those exclusively related to the user who makes the service request, but to another referenced user or users, while, at the same time, maintaining the necessary privacy concerning the various and distinct identifiers of the referenced users across various Service Providers.
  • Figure 1 shows a schematic view of two Service Providers, an Identity Provider and a Discovery Service server entity in a identity federation framework.
  • Figure 2 shows a similar view as shown in Fig.l, but showing a situation wherein the two users are federated in different Identity Providers.
  • Figure 3 shows a simplified signaling flow for the setting according to one embodiment of the invention of a private identifier of a user in an Identity Provider.
  • Figure 4 shows a simplified signaling flow for the provision of a service to a referencing user which needs to consume an identity service of a referenced user, wherein, as in Fig.l, only one Identity Provider is involved.
  • Figure 5 shows various acquaintance embodiments to obtain the contact information for a given referenced user from an Identity Provider which does not contain said contact information.
  • Figure 6 shows a first embodiment of an equivalent flow as the one shown in Fig.4, wherein more than one Identity Provider are involved.
  • Figure 7 shows a second embodiment for the flow shown in Fig.6.
  • Figure 8 shows, by way of a simplified signaling flow, an embodiment to allow a referenced user to federate in the Service Provider of an allowed referencing user through an intermediate Service Provider.
  • Figure 1 shows a schematic view of two SPs, one IdP and one DS in a identity federation framework.
  • Fig.l also shows generic data structures handled by the IdP and by the DS for two users.
  • a given service provider can have a plurality of apparatuses for providing services; similarly, within a Circle of Trust CoT, there can be a plurality of apparatuses acting as Identity Providers for a plurality of users as well as a plurality of apparatuses providing a Discovery Service.
  • the SPs IdPs and DSs depicted in the figures illustrating this invention it can be assumed each of them to represent the particular apparatus providing respectively the corresponding function.
  • a "human user” appears to be depicted as a "user” in some figures referenced in this detailed description.
  • said "user” intends to refer to an entity (e.g. such as a "principal” in LAP terminology) which, as stated earlier, is not necessarily a human user in cooperation with a user terminal, although this can be considered as an example case.
  • a user User 2
  • IdServx identity service
  • IdP stores for User 2 a pseudonym (Alias2) which both, the IdP and the SP2 , shall use to refer hereinafter to this user.
  • This pseudonym is stored in relationship to User 2's data in the IdP together with other pseudonyms which can be related to this user in another SPs (SPm: Aliasm) .
  • SPm Aliasm
  • the particular service that SP2 offers to User 2 can be, for example, the master storage of his calendar data as well as their corresponding access and updating.
  • the DS stores one resource offering RO entry (IdServx/SP2/RefSP2 ) which contains information about the SP hosting this identity service (SP2 in this case) , as well as a reference usable in said SP to point out the identity attribute (s) of said identity service which can be consumed by other SPs.
  • This entry is stored in the RO of this user (103) in the DS in addition to any other RO entry (IdServz/SPn/RefSPn) eventually stored in relationship with another identity service of this user.
  • the IdP stores the corresponding DS contact information for this user (DSUser2) which points out (102) the corresponding RO of this user in the DS.
  • Another user has accessed to another SP (SPl) e.g. wishing to access a service SPl provides.
  • SPl may or may not have previously a service account in SPl and, for example, SPl can provide a given service to User 1 if said an authentication of said user can be asserted from the IdP (e.g. : User 1 has been previously authenticated in another SP and this authentication is considered still valid) .
  • an authentication of said user can be asserted from the IdP (e.g. : User 1 has been previously authenticated in another SP and this authentication is considered still valid) .
  • SSO process a result of the assertion of the authentication of User 2 from the IdP to SP2
  • IdP stores for User 1 a pseudonym (Aliasl) which both, the IdP and the SP2, shall use to refer hereinafter to this user.
  • the particular service offered by SPl to User 1 can be, for example, the booking of a flight and the updating of another user's calendar (e.g.: User 2's calendar) for marking the flying time of this flight as busy.
  • Fig.2 considers the same case as the one explained with reference to Fig.l, wherein both users have federated through different IdPs (IdPA and IdPB) .
  • IdPA and IdPB IdPs
  • This scenario shall be later used to detail some acquaintance embodiments wherein more than one IdP is involved.
  • User 1 acting as requesting/referencing user, can request a service which needs the consumption of attributes of an identity service that e.g. another SP (e.g. SP2 ) hosts for another user (referenced user; e.g. User 1).
  • another SP e.g. SP2
  • User 1 does not need to know the SP hosting said service (SP2), nor the pseudonym used between said SP and the IdP (Alias2) for the referenced user, nor other pseudonym federated for the referenced user through other SP.
  • a given user accesses an SP that provides a service which, for its accomplishment, needs to consume an attribute of the identity of another user (referenced user)
  • the SP can provide said service if the IdP can asserts the authentication of this requesting user.
  • a private identifier for a user that can be referenced by another referencing/requesting user is stored in relation with an identity service of said referenced user.
  • a private identifier (PrivateID2) is stored in relationship with the data stored for User 2 on his IdP.
  • the actual format of the private identifier of the referenced user is irrelevant to the invention.
  • Either structured and standardised identities e.g. domain names, e.164 numbers, Uniform Resource Identifiers URIs, etc
  • non-structured and/or non-standardised name identifiers e.g. any alphanumeric string
  • the provision of the private identifier for a user in an IdP can be accomplished by different methods. For example, it can be set by usual data provisioning processes (e.g. current operation and maintenance processes that allow to set or modify data in a given apparatus) .
  • Another alternative solution can be to assign said private identifier to a user dynamically; for example, when the user federates an identity at first time or at first log-in of this user in the IdP. In this latest case, the IdP can e.g. prompt the user for entering a private identifier or assigns him one automatically.
  • a first step (301) User 2 access SP2 and consents it to register the identity service it provides (IdServx).
  • SP2 sends to the DS a registration request for this user and this service, wherein the registration request contains a private identifier in relationship with said user and, optionally, with said service.
  • the registration request can further contain policy rules that state, for example, what users can reference this user by utilizing this private identifier, from what SPs, and for what particular referencing service.
  • the DS sends the received private identifier to the IdP to be stored in relationship with the data of User 2.
  • the registration request can be further acknowledged back in further steps (304, 305).
  • policies for controlling the access to the RO and/or to the contact information said private identifier relates.
  • said rules can be implemented in a IdP to control whether the corresponding contact information can be provided depending on the origin of the request (i.e.: SP that is serving a given service to a given referencing user, a given referencing user, the particular service being served, etc.).
  • an IdP can store one or more identifiers of one or more SPs which are allowed to serve a given service which consumes an attribute which can be obtained by first using this contact information.
  • an IdP can store identifiers of one or more referencing users who can be served with a service which consumes an attribute which can be obtained by first using this contact information, as well as identifiers of said services.
  • the IdP can check an identifier of the origin of the request (e.g.: requesting user and/or SP) as well as the identifier of the service to be provided to said origin; wherein some of those identifiers (or all) can be obtained from the IdP on its interaction with the requesting entity (requesting user and/or SP) .
  • Similar policy rules to control the access to a RO for a given referenced user and a given service can be held in a DS apparatus.
  • the DS when the DS receives a discovery look-up operation from a SP, it can check whether the corresponding RO data can be provided back by checking the identifier of the requesting SP, the identifier of the particular requested service and, if available, an identifier of the requesting/referencing user.
  • Fig.4 considers an scenario wherein one IdP is the IdP of both: the user who request the service (User 1) , and the user who is referenced by said service (User 2) .
  • step 401 SPl detects that for giving the required service to Userl related to another user, SPl needs some data or service from the other user and asks Userl to introduce the private identifier of said user.
  • Userl introduce the private identifier of User2 and the SPl sends in step 402 an acquaintance request to the IdP to obtain the corresponding contact information.
  • the private identifier provided by User 1 to SPl can be encrypted so as to hide its content to SPl, while allowing its decryption by the IdP (e.g.: encrypted using a public key of the IdP or a secret shared key between User 2 and the IdP) . Accordingly, the IdP can be provided with well-known means to decipher the received private identifier so as to find the corresponding contact information stored in relationship with it, and to answer back with said contact information in step 403.
  • SPl can in step 402-1 redirect to User to enter the private identifier into the IdP; then the IdP can redirect back to User 1 to SPl in step 403-1, wherein said redirection comprises the corresponding contact information.
  • SPl sends in step 404 a discovery look-up operation to the DS which comprises the received contact information and can also comprise the wanted RO for the needed identity service of User 2.
  • the DS responds in step 405 to SPl with the necessary information to contact to SP2 and to point out there the necessary attribute (s) of said identity service.
  • the SPl ask to SP2 to perform the required service action.
  • Said action which can consume one or more of said attributes can comprise, for example, the retrieval or updating of some attributes (e.g. retrieval or updating of some calendar data of User 2), as well as the performance of some further service actions using them (e.g.
  • SP2 can return in step 407 a response to SPl, wherein said response can convey, depending on the requested service actions data about some concerned attribute (s) or, merely, a service acknowledgement .
  • Fig.5 shows various acquaintance embodiments to obtain the contact information for a given referenced user from an Identity Provider which does not contain said contact information.
  • User 1 Before User 1 actually sends the referenced user's identifier to SPl, User 1 may wish to encrypt or cipher the referenced user's identifier.
  • the encryption is carried out in such a way that only the requesting user and his IdP (or a similar centralised service like a DS) are involved on his knowledge; thus as a shared encryption key, public key infrastructure, or other can be utilized. This ensures that the referenced user's identifier (i.e.: his private identifier) is never understood by the requesting entity (e.g. an SP) for privacy reasons.
  • the actual encryption dialogue and mechanism between the requesting user and the identity provider (or discovery service) can occur before the initiating contacts the requesting entity; it can be achieved via any of the current state-of-the-art procedures.
  • SPl as requesting entity, has received the referenced user's private identifier from User 1 in a request (for instance, to perform a certain operation on referenced user's data such as update their calendar or contact book services)
  • SPl triggers the first step of the acquaintance profile mechanism towards the IdP with which the requesting entity has an agreement (IdPA) .
  • the object is to determine if the IdP is acquainted with the private identifier that represents the referenced user and if so to additionally return an appropriate data for the referenced user and service at a given SP.
  • the referenced user's identifier is encrypted or ciphered, this can be indicated in the message with a flag sent by the requesting user (User 1) to the requesting entity (SPl) and included in the acquaintance request along with a name identifier of the requesting user at the requesting entity. This would be enough information for the IdP to resolve the value to an unencrypted private identifier of the referenced user. If the original IdP (IdPA) that received the acquaintance request is not acquainted with the received private identifier, then it triggers the second step of the acquaintance process. The second step of the acquaintance profile requires the original IdP to send the acquaintance request towards other IdPs.
  • IdPA original IdP
  • the mechanism can be carried out by either of the following ways: sending the acquaintance request to all identity providers, either: in a sequential manner, or in a broadcast manner, or send the acquaintance request to a centralised Acquaintance Server that is able to determine the correct IdP that stores the DS contact information for the received private identifier.
  • Provisioning of identifiers of referenced user's in their IdP may occur in the manner described in Liberty ID-FF or via other means (e.g. user via SP requests identifiers to be created and provisioned in the IdP as explained earlier with reference to Fig.3).
  • each IdP can notify the Acquaintance Server whenever a new private identifier for a user is created, along with the IdP responsible for that identifier.
  • the Acquaintance Server can thus only match a private identifier (such as an alphanumeric string) with an IdP but may not infer anything more about what the identifier represents. Although any notification mechanism will do (e.g.
  • IdPA the IdP that sends the acquaintance request
  • IdPB the IdP that responds affirmatively as IdPB.
  • Signaling flows 1 to 3 in Fig.6 are equivalents as the same described with reference to Fig.5.
  • IdPB the correct identity provider
  • IdPB determines the referenced user's discovery service (from here on DS-B) by inspecting the received private identifier of the referenced user and returns a value to the requesting entity SPl via IdPA in flows 4 and 5, that represents both the referenced user as well as his contact information in discovery service DS-B
  • IdPB may need to include an authorisation token (issued by either IdPB or DS-B itself) back that authorises the requesting entity SPl to use a discovery service in dP-B's circle of trust (i.e. a discovery service with which the requesting entity has a priori no relationship) .
  • the requesting entity SPl will then contact DS-B in flows 6 and 7 in a manner described by LAP to later on establish a relation with the referenced user's service provider or attribute provider (SP2) in IdP-B's CoT (as described previously with reference to steps 404 and 405 with reference to Fig.4).
  • SP2 referenced user's service provider or attribute provider
  • the requesting entity SPl would contact SP2 in flow 8 and include an obfuscated referenced user identifier received from DS-B which is usable to address the corresponding attribute (s) of the referenced user in SP2.
  • the performance of the pertinent service action in SP2 can require User 2 ' s consent.
  • the requesting entity SPl can store the returned obfuscated identifier of the referenced user to be used whenever it contacts SP2 on behalf of the requesting user User 1.
  • Flows 8 and 9 in Fig.6 are then equivalent to flows 406 and 407 detailed earlier with reference to Fig.4.
  • IdPB can contact DS-B and later to SP2 on behalf of requesting entity SPl.
  • IdPB can query DS-B regarding the service provider (or attribute) provider (SP2) for a given service or set of operations to be carried out on the referenced user (originally requested by the requesting user) , contacts said SP2 on behalf of the requesting entity and asks if the latter may execute a service or set of operations concerning the referenced user that involves SP2 that has been requested by the requesting user (this, as in the previous described case, might require consent from referenced user) .
  • SP2 service provider
  • IdPB can generate a pseudonym (if not already generated) that represents the referenced user and shares this pseudonym with SP2. Only IdPB and SP2 can correlate this pseudonym to who the referenced user is. IdPB finally returns an affirmative response (that is, these operations requested by the requesting user to be carried out on the referenced user are allowed) , the generated pseudonym and the address of SP2 back to the requesting entity, via IdP-A, in the acquaintance answer.
  • the requesting entity SPl can then store the returned pseudonym of the referenced user User 2 to be used when contacting SP2 to carry out the operations demanded by the requesting user User 1 (and in this case alone, that is, a different requesting user value would return a different pseudonym value for the same referenced user at the same SP-B for the same set of operations) .
  • a centralised Acquaintance Server that matches a given private identifier with an IdP, then it would suffice for a receiving IdP (the IdP that ported the user) to request that an identifier (or set of them) be updated to match the receiving IdP instead of the donor IdP. This operation could require explicit authorisation from the donor IdP. Otherwise a donor IdP could directly interact with a receiving IdP to carry out the identifier portability process. This mechanism is just as valid as the previous mechanism although a third party, such as a centralised Acquaintance Server (even if only used for administrative purposes) , can facilitate the portability process between IdPs.
  • a third party such as a centralised Acquaintance Server (even if only used for administrative purposes) , can facilitate the portability process between IdPs.
  • the actual porting of identifiers could be carried out via an existing message (such as Register Name Identifier) or a new message for this purpose.
  • an existing message such as Register Name Identifier
  • a new message for this purpose.
  • the acquaintance profile relieves any requesting IdP to store any information about an unknown referenced user, thus it doesn't restrict user choices when selecting a new IdP.
  • FIG.7 An acquaintance flow representing an alternative embodiment of the one detailed with reference to Fig.6 is shown in Fig.7.
  • User 1 requests in SPl a service which needs to consume User 2's attributes
  • User 1 is redirected in flow 1 to IdPA from SPl.
  • IdPA Once in contact with IdPA, User 1 introduces a User 2's private identifier in step 3.
  • Flows 3 and 4 of this figure are equivalent to flows 3 and 4 previously detailed with reference to Fig.6.
  • the corresponding contact information for the DS-B is available, User 2 is redirected with this information back to SPl.
  • Subsequent flows 6 to 9 are equivalent to flows having the same numeral and previously detailed with reference to Fig.6.
  • the signaling flow shown in Fig.8 exemplifies an embodiment to allow a referenced user User 2 to federate in the SP of an allowed referencing user User 1 (e.g. SPl) through an intermediate Service Provider.
  • User 2 could federate directly into SPl, so as to allow SPl to provide an identifier to User 2 usable to identify said user in case of User 1 invokes a service which involves the consumption of attributes of an identity service hosted in e.g. SP2 , it could be desirable in some cases that User 2 does not contact directly to SPl.
  • the idea behind this embodiment is to reduce the required interaction by User 2 (referenced user) with, for example, an undesired and/or non-trusted SP (e.g.
  • SPl simply for the purpose of communicating or interacting with User 1 (initiating user) in the context of an identity federation framework scenario providing identity services.
  • This embodiment uses a SP as a dummy service provider (Dummy-SPl) that is in charge of technically enabling interaction between User 1 (initiating user) and User 2 (referenced user) in this context.
  • Dummy-SPl dummy service provider
  • Fig.8 depict the more general case in which both users, User 1 and User 2 are subscribed to different CoTs including different IdPs (IdP2 for User 2, and IdPl for User 1 and also for User 2 when federating through SP2) and DSs and have (or create) service accounts at different service providers (SPl and SP2) for the purpose of executing or receiving a common service or set of operations that involves both users.
  • IdP2 for User 2
  • IdPl for User 1 and also for User 2 when federating through SP2
  • SPl and SP2 service providers
  • the dummy SP is in someway analogous to an interconnection service as it provides the necessary means for User 1, via SPl, to interact with SP2 when referencing User 2.
  • the dummy SP can have a widely accepted and known URL (e.g.
  • Flows 1 and 2 in Fig.8 are standard federation flows of a user (User 2) through a SP (Dummy SPl) in an IdP (IdPl) .
  • IdPl IdP
  • both, IdPl and Dummy- SPl share a pseudonym to refer to User 2 (User2xyz) .
  • IdPl federates User 2 with IdP2 , and also, as a result of this further federation both: IdPl and IdP2, share a pseudonym to refer to User 2 (User2abc) .
  • Dummy-SPl register an identifier of User 2 in SPl (Pepita) .
  • this identifier is utilized by the requesting user User 1 as a private identifier to refer to User 2 as described in any of the previous examples wherein the requesting user User 1 is not redirected from a SP to an IdP; however, although not shown in Fig.8, other flows wherein User 1 is redirected to an IdP, and redirected back to SPl can equally take place, as previously detailed with reference to figures 4 or 7.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un appareil (SP1, IdP) permettant de fournir un service à un utilisateur de référençage (utilisateur 1). Cet appareil fait appel à un attribut d'un service d'identité d'un utilisateur référencé (utilisateur 2). Un appareil SP comprend un moyen permettant de demander des secondes informations de contact associées à un identifiant privé d'un utilisateur référencé, un moyen pour obtenir une seconde offre de ressources associée aux secondes informations de contact, et un moyen pour demander une action de service de la part de l'utilisateur de référençage, pour un attribut associé à ladite offre de ressources. L'invention concerne un appareil IdP comprenant un moyen pour stocker des informations de contact associées à une pluralité de pseudonymes fédérés pour un utilisateur référencé, un moyen pour stocker un identifiant privé du premier utilisateur associé aux informations de contact, un moyen pour recevoir une demande desdites informations de contact, comprenant ledit identifiant privé, pour fournir un service au second utilisateur d'un fournisseur de services, et un moyen pour fournir lesdites informations de contact, à la réception de la demande.
PCT/SE2004/001559 2003-11-18 2004-10-26 Appareil permettant de fournir un service dans un cadriciel de federation d'identites WO2005050422A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE0303057-4 2003-11-18
SE0303057A SE0303057D0 (sv) 2003-11-18 2003-11-18 Apparatus for providing a service in an identity federation framework

Publications (1)

Publication Number Publication Date
WO2005050422A1 true WO2005050422A1 (fr) 2005-06-02

Family

ID=29729081

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2004/001559 WO2005050422A1 (fr) 2003-11-18 2004-10-26 Appareil permettant de fournir un service dans un cadriciel de federation d'identites

Country Status (2)

Country Link
SE (1) SE0303057D0 (fr)
WO (1) WO2005050422A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006136936A1 (fr) * 2005-06-23 2006-12-28 Telefonaktiebolaget Lm Ericsson (Publ) Procede permettant d'ameliorer un mecanisme de referencement principal dans des scenarios a base d'identite
WO2012130782A1 (fr) * 2011-03-25 2012-10-04 Gemalto Sa Service de délégation d'utilisateur à utilisateur dans un environnement de gestion d'identité fédéré
US8887250B2 (en) 2009-12-18 2014-11-11 Microsoft Corporation Techniques for accessing desktop applications using federated identity
US9391978B2 (en) 2010-05-25 2016-07-12 Novell, Inc. Multiple access authentication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003049000A1 (fr) * 2001-12-04 2003-06-12 Sun Microsystems, Inc. Identite pour reseau reparti
WO2003073242A1 (fr) * 2002-02-28 2003-09-04 Telefonaktiebolaget L M Ericsson (Publ) Procede et appareil permettant de traiter des identites utilisateur sous des services d'entree en communication unique
WO2003091861A2 (fr) * 2002-04-26 2003-11-06 International Business Machines Corporation Systeme de gestion efficace de l'identite au moyen d'un navigateur, fournissant un controle personnel et l'anonymat

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003049000A1 (fr) * 2001-12-04 2003-06-12 Sun Microsystems, Inc. Identite pour reseau reparti
WO2003073242A1 (fr) * 2002-02-28 2003-09-04 Telefonaktiebolaget L M Ericsson (Publ) Procede et appareil permettant de traiter des identites utilisateur sous des services d'entree en communication unique
WO2003091861A2 (fr) * 2002-04-26 2003-11-06 International Business Machines Corporation Systeme de gestion efficace de l'identite au moyen d'un navigateur, fournissant un controle personnel et l'anonymat

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006136936A1 (fr) * 2005-06-23 2006-12-28 Telefonaktiebolaget Lm Ericsson (Publ) Procede permettant d'ameliorer un mecanisme de referencement principal dans des scenarios a base d'identite
US8095660B2 (en) * 2005-06-23 2012-01-10 Telefonaktiebolaget L M Ericsson (Publ) Method to enhance principal referencing in identity-based scenarios
US8887250B2 (en) 2009-12-18 2014-11-11 Microsoft Corporation Techniques for accessing desktop applications using federated identity
US9391978B2 (en) 2010-05-25 2016-07-12 Novell, Inc. Multiple access authentication
WO2012130782A1 (fr) * 2011-03-25 2012-10-04 Gemalto Sa Service de délégation d'utilisateur à utilisateur dans un environnement de gestion d'identité fédéré
US9401918B2 (en) 2011-03-25 2016-07-26 Gemalto Sa User to user delegation service in a federated identity management environment

Also Published As

Publication number Publication date
SE0303057D0 (sv) 2003-11-18

Similar Documents

Publication Publication Date Title
AU2003212723B2 (en) Single sign-on secure service access
JP4579546B2 (ja) 単一サインオンサービスにおけるユーザ識別子の取り扱い方法及び装置
US7860882B2 (en) Method and system for distributed retrieval of data objects using tagged artifacts within federated protocol operations
US7860883B2 (en) Method and system for distributed retrieval of data objects within multi-protocol profiles in federated environments
US6895511B1 (en) Method and apparatus providing for internet protocol address authentication
KR101265305B1 (ko) 부정적인 인터넷 계정 액세스 방지
US8838986B2 (en) Invocation of third party's service
KR101137269B1 (ko) 리소스의 위임을 수행하는 방법 및 시스템
US20080021866A1 (en) Method and system for implementing a floating identity provider model across data centers
US20070073888A1 (en) System and method to control transactions on communication channels based on universal identifiers
US20040064687A1 (en) Providing identity-related information and preventing man-in-the-middle attacks
US20070143829A1 (en) Authentication of a principal in a federation
US20080021997A1 (en) Method and system for identity provider migration using federated single-sign-on operation
EP2235918B1 (fr) Amélioration de sécurité du protocole enum
RU2387089C2 (ru) Способ предоставления ресурсов с ограниченным доступом
WO2009129753A1 (fr) Procédé et appareil pour améliorer la sécurité de l'authentification d'identité de réseau
CN115996381B (zh) 一种无线专网的网络安全管控方法、系统、装置及介质
Alsaleh et al. Enhancing consumer privacy in the liberty alliance identity federation and web services frameworks
EP1039724A2 (fr) Procédé et dispositif permettant l'authentification d'addresses internet
WO2005050422A1 (fr) Appareil permettant de fournir un service dans un cadriciel de federation d'identites
KR20050066052A (ko) 인증정책에 기반한 선택적 인증 시스템 이에 적합한사용자 인증 방법
Chen A scenario for identity management in Daidalos
EP1735984B1 (fr) Procede et appareil de traitement du partage d'attributs d'utilisateurs entre prestataires de services
JP2024010384A (ja) シングルサインオン認証システムおよびシングルサインオン認証装置
Wesselius et al. Authentication

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase