Classifications

• • 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/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
• • 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/41—User authentication where a single sign-on provides access to a plurality of computers
• • 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
• • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
• • 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/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
• • 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/50—Network services
  • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/069—Authentication using certificates or pre-shared keys
• • 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
  • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer

Definitions

• the present invention generally relates to Single Sign-On services that can be offered for a plurality of users. More particularly, the invention pertains to means, system and methods for offering Single Sign-On web-based services for a plurality of users that are subscribers of Mobile Networ Operator networks.
• SSO Single Sign-On
• a terminal-centric approach the user authenticates once to the terminal that in turn automatically tracks a service-oriented network access and transparently presents, that is, without further user involvement, the appropriate credentials to the service-oriented network that requests such credentials.
• AP Authentication Provider
• a network operator may issue credentials such as digital certificates, short-time certificates, or temporary tickets or tokens that may be stored in the terminal or in an accessible read/write card. These are further used by the user upon authentication or authorization procedures.
• an Authentication Provider may belong to the same administrative domain as the Service Provider offering the service, or may be delegated to an external trusted party or to a distributed federation.
• a primary object of the present invention is the support of Single Sign-On (SSO) services for subscribers of a Federation of Mobile Network Operators (MNO) , subscribers who are users of different Service Providers (SP) .
• Said SSO services are supported in such a manner that users, Federation of Mobile Network Operators, and Service Providers holding agreements with at least one member of such Federation, all get additional advantages and value added services from a given architectural and business reference model in accordance with this invention.
• the users have the advantage of the SSO service for accessing any service at any Service Provider (SP) within the reference model agreement.
• the Mobile Network Operators (MNO) may obtain revenues by offering SSO services, in particular authentication and authorization, to third parties as well as keeping subscribers loyalty by adding value to their respective mobile subscriptions.
• MNO Mobile Network Operator
• the Service Providers may experience an increase of potential users, namely mobile subscribers, with a simpler and much safer authentication and authorization mechanisms minimizing the support for different such mechanisms depending on the different nature of users.
• Authentication Provider and Service Provider belong to different administrative domains.
• these distributed advantages favor an increase of a so-called mobile commerce (m- commerce), which can be regarded as a further object of the present invention.
• U.S. Patent Application Publication US 2002/0010776 Al to Lerner describes methods and systems for providing a Single Sign-On (SSO) distributed application services integration for authentication and authorization services.
• SSO Single Sign-On
• the relevant teaching in this application starts when a first indication from a user, who is pointing a browser of a first application, is received at a central server coupled to the user terminal. Then, a cookie file corresponding to the user is also received at the central server from the browser of the first application. The central server, then, updates the cookie file received from the browser.
• a cookie file is a data segment of variable length and typically including hundreds of bytes. These cookies are written, read and modified by an application interface library resident in each affiliated web server, whether local to the central server or residing in a remote partner's site. More specifically, the updating of a received cookie file includes the comparison of the cookie file with some predetermined parameters and the eventual modification of the cookie file based on this comparison.
• the central server When a second indication from the user is received at the central server indicating that the user is pointing the server to a second application, the central server provides this updated cookie file to the second application.
• This application describes how a user is authenticated at a first web server that allows the user to select a second web server offering a desirable service.
• the first web server constructs an encrypted authentication token, and transmits it to the second web server.
• the second web server authenticates the received token and allows the user to have a session at this second web server.
• Both first and second web server share, in accordance with this application, a sub-domain. That is, the scenario in this application is an instance where the Authentication Provider, namely the first web server, and the Service Provider, namely the second web server, both belong to the same administrative domain.
• the teaching in this application cannot be applied to scenarios where Authentication Provider and Service Provider belong to different administrative domains. That is, the first web server in this application, the Authentication Provider, is the first contact for the user accessing the second web server where the service is offered.
• an important object of the present invention is the provision of a system, means and methods for building up a Federation of Mobile Network Operators (MNO) acting as an authentication authority towards associated Service Providers (SP) offering Single Sign-On (SSO) services to the subscribers of any MNO in the Federation.
• MNO Mobile Network Operator
• SP Service Providers
• SSO Single Sign-On
• the Federation acting as an authentication authority thus accomplishes security and privacy related requirements at a same or higher level than those currently used by Mobile Network Operators.
• It is a further object of the present invention to establish an architectural and business reference model in regard to actors, roles, relationships and basic use cases in conformity with the system, means and methods of the above objects.
• the telecommunication system comprising a first mobile network that belongs to a first mobile network operator, at least one second mobile network that belongs to a second mobile network operator, and at least one of a plurality of Service Providers for providing services to subscribers of said mobile network operators once the subscribers have been authenticated for the at least one Service Provider by an authentication authority.
• the first mobile network operator and the at least one second mobile network operator both conform or belong to a cellular Federation of mobile network operators that acts as the authentication authority.
• the system comprises an Authentication Provider belonging to the first mobile network as the only member of the Federation entitled to authenticate the user toward the at least one Service Provider; and an Authentication Broker belonging to a second mobile network and arranged to act as the entry point to the Federation from those Service Providers having an agreement with the second mobile network operator for such purpose.
• an agreement of this type is referred to as an "entry point" agreement .
• the telecommunication system comprises means for redirecting a user accessing a Service Provider, the user having a subscription with a first mobile network operator, toward an Authentication Broker of a second mobile network operator having such agreement with the Service Provider, and means for redirecting the user accessing the Authentication Broker toward an Authentication Provider of the user's Home first mobile network operator.
• the telecommunication system comprises means for performing a user's Home resolution at the Authentication Broker for allowing the Service Provider to request validation of an authentication assertion for that user from the Authentication Provider belonging to the first mobile network.
• the telecommunication system allows the Authentication Provider of the first mobile network operator to be directly accessed, without involving an
• the telecommunication system further comprises means for redirecting a user accessing a Service Provider toward an Authentication Provider of the user's Home first mobile network, without involving an Authentication Broker, the Service Provider having such agreement with the Home first mobile network operator.
• such Service Provider may request validation of an authentication assertion for that user from said Authentication Provider without involving an Authentication Broker.
• the above system comprises means for issuing a Single Sign-On authentication request from a user accessing a Service Provider toward an Authentication Provider in the cellular Federation responsible for authenticating the user for that Service Provider, the user being a subscriber of the cellular Federation, and means for presenting a received authentication artifact to the Service Provider.
• a method is also proposed by the present invention for providing Single Sign-On services to a user accessing selected Service Providers, the user having subscription with a first mobile network operator, and each selected Service Provider being associated with a second mobile network operator. This method comprises the steps of:
• a user is identified between an Authentication Provider and a Service Provider with a shared identity, independently of the authentication identity used between the user and the Authentication Provider in the cellular Federation, and independently of the user identity used between the user and the Service Provider.
• an Authentication Broker comprising first interfacing means for communicating with a user having subscription with a first mobile network operator, and second interfacing means for communicating with a Service Provider associated with a second mobile network operator.
• first and second interfacing means can be regarded as forming a broker channel for enabling the Authentication Broker to redirect the user to the user's Home network, and to resolve the user's Home network for the Service Provider, respectively.
• Such Authentication Broker may comprise a Web Front End that includes the above first and second interfacing means with user and Service Provider, respectively.
• the Authentication Broker further comprises storage for all the Authentication Providers in the cellular Federation on a per mobile network operator basis, each mobile network operator included in the cellular Federation, and means for retrieving from storage user's Home related addressing data.
• the Authentication Broker Web Front End further comprises means for offering Public Key Infrastructure services to those Service Providers associated with the mobile network operator owning the Authentication Broker in order to accomplish the security and privacy requirements of the cellular Federation, thus accomplishing another object of the present invention.
• Authentication Provider comprising a front channel and a back channel .
• the front channel of this Authentication Provider includes a Web Front End that comprises first interfacing means for enabling an authentication session between a user and said Authentication Provider.
• This front channel further comprises a Session Manager and storage for handling session status for the user, and a Front End Authentication server for carrying out a specific authentication mechanism for the user.
• the back channel of this Authentication Provider includes a Protocol Binding that comprises second interfacing means for exchanging information related to user authentication assertion between said Authentication Provider and a Service Provider that the user is accessing.
• This back channel further comprises a Security Assertion Mark-up Language engine for generating an authentication assertion for a user, and storage for authentication assertions.
• inter- working means between front channel and back channel for generating and storing an authentication assertion for a user.
• each mobile network operator contributes with its own network and the services provided by its associated Service Providers, each network comprising an Authentication Provider for authenticating subscribers of such network and an Authentication Broker for redirecting the associated Service Providers to an Authentication Provider responsible for authenticating a given user in the Federation.
• each Service Provider in this business method is arranged for offering services to subscribers of any mobile network operator included in the Federation.
• the Service Provider may access the Federation through a well known Authentication Broker of a mobile network operator having such agreement with the Service Provider and thus having an authentication trust relationship with the Federation.
• FIG. 1 schematically represents the architectural and business reference model of a Cellular Federation for Single Sign-On services.
• FIG. 2 shows a simplified sequence diagram representing the process followed to authenticate a user and to authorize access 'to a service offered by a Service Provider in a basic scenario where the Service Provider has a business agreement with the Mobile Network Operator holding a subscription for such user.
• FIG. 3 shows another simplified sequence diagram representing the process followed to authenticate a user and to authorize access to a service offered by a Service Provider in a more generic scenario.
• the Service Provider has a business agreement with a Mobile Network Operator other than the one holding the subscription for such user, both mobile network operators being included in a Cellular Federation.
• FIG. 4 generally presents an exemplary internal architecture and main interfaces involving a user, a
• FIG. 5A shows a first sequence (I) of actions when a user accesses an Authentication Provider (AP) through a so-called Front Channel for initiating a new authentication process or for triggering an assertion process if a valid authentication had been previously performed.
• AP Authentication Provider
• FIG. 5B shows a second sequence (II) of actions carried out to authenticate a user not previously authenticated through a so-called Front Channel at an AP, and with help from an Authentication Back End (hereinafter referred to as "Auth. B/E”) .
• FIG. 5C shows a third sequence (III) of actions carried out to accomplish an assertion process when a user is found to be previously authenticated, therefore having an active session.
• FIG. 6 presents a schematic composition that, by including references in Fig. 5A to 5C, shows the sequence of actions carried out between a user, a Service Provider and an Authentication Provider for authenticating such user who had accessed the Service Provider without having been previously authenticated.
• FIG. 7A presents a schematic composition that, by including references in Fig. 5A and 5B, shows the sequence of actions carried out between a user and an Authentication Provider during an isolated authentication of such user.
• FIG. 7B presents a schematic composition that, by including references in Fig. 5A and 5C, shows the sequence of actions carried out between a user, a Service Provider and an Authentication Provider for the user, who had been already authenticated, accessing to the Service Provider.
• FIG. 8 illustrates a more detailed embodiment of some steps appearing in Fig. 3 in accordance with a preferred architectural model.
• FIG. 9 illustrates a more detailed embodiment of some other steps also appearing in Fig. 3 in accordance with a preferred architectural model.
• FIG. 10 shows an exemplary relationship between SSO_auth_ID, SSO_MAIN_ID and SHARED_ID identities managed at an Authentication Provider.
• MNO Mobile Network Operator
• SP Service Providers
• a cellular Federation for Single sign-On (FSSO) services presents the architectural and business reference model described above in terms of actors, roles, relationships and some exemplary use cases in respect of a first Federation (FSSO-1) .
• Actors in the reference model in Fig. 1 are Users (User@MNO-A, User@MN0-C) , Service Providers (SP-1, SP-2) and subscribers Home Site, the latter being Mobile Network Operators (MNO-A, MNO-B, MNO-C) holding the subscriber subscriptions.
• a User is a mobile subscriber provided with a Subscriber Identity Module or with a WAP Identity Module (SIM/WIM) and with a web/wap browser;
• SIM/WIM WAP Identity Module
• a Service Provider is the target where a service requested by a User resides;
• a Home Site is a Mobile Network Operator holding the subscription of the User.
• a User is in this context a Client requesting a service from an SP;
• a Destination Site is a site capable of delivering a given service to a Client, in general an SP though an MNO may also play this role for some services;
• Authentication Broker (1, 2) is a member of the Federation
• FSSO-1, SP-2 intended for acting as the entrance point to the Federation for associated SP' s
• an Authentication Provider (4, 5, 6) is a member of the Federation (FSSO-1) intended for owning user data and the only one able to authenticate and provide user information to the Destination Site.
• an SP SP-1, SP-2 always accesses (S-100, S-200) the Federation through its associated AB (1, 2).
• SP' s are not considered members of the Federation, being thus referred to as associated entities.
• each particular MNO does not only contribute to the Federation with its own cellular network but also with a number of associated SP's (SP-1, SP-2) with which it has signed particular agreements.
• SP-1, SP-2 may always access (S-100, S-200) to the Federation via the Authentication Broker (1, 2) of a particular MNO (MNO-A, MNO-B) with which each SP (SP-1, SP-2) has signed such agreement.
• MNO-A, MNO-B Authentication Broker
• SP-1, SP-2 Authentication Broker
• a network operator can leverage the services of respective SP' s in markets where they have strong positions, which would be the case for a cellular multinational federation where service providers tend to sign Service Level Agreements (SLA) with local operators.
• SLA Service Level Agreement
• an Authentication Broker (1, 2) is responsible for resolving the user's Home Site. That is, the AB is in charge of providing an associated SP with enough information to enable the exchange of user data between the MNO holding the subscription of a user and the SP. Once the user's Home Site has been resolved, the AB is able to redirect the user to the user's Home Site.
• an AB may offer Public Key Infrastructure (PKI) services to its associated SP's in order to accomplish security and privacy requirements characteristic of the Mobile Network Operators.
• PKI Public Key Infrastructure
• SP SP-1 (SP-2)
• S-100 single trust relationship
• MNO-A Mobile Network Operator
• MNO-B Mobile Network Operator
• SP-2 may have a trust relationship with different federations like, for example, a cellular federation (FSSO-2)
• an SP (SP-1) associated with a particular MNO (MNO-A) does not need go through an AB (1) of such MNO for accessing the AP (4) in the MNO holding the subscription for the user (User@MNO-A) who has requested a service in such SP (SP-1) .
• This is especially advantageous for a trust relationship (R-110) between a MNO (MNO-A) and an associated SP (SP-1), and, in particular, it optimizes network access and performance.
• an AB does not normally know the users of each Home Site of the Federation, since this requires each AB being able to populate all users of the Federation, what requires the provision of additional means for users capacity and availability control. Nevertheless, by reading throughout the currently preferred embodiments described in accordance with the invention, it will be appreciated that a unique or reduced number of AB (1, 2) provided with these additional means for users capacity and availability control, as well as with database facilities for a huge amount of subscribers, may be suitable for a certain type of cellular Federation. For example, such Cellular Federation might be a Federation comprising a plurality of national MNO's belonging to a global corporation with facilities spread across the world.
• a first use case may be a user (User@MNO-A) accessing a certain Service Provider (SP-1) , such as for instance a Bookstore Service Provider, wherein the Service Provider (SP-1) is associated with the cellular SSO Federation (FSSO-1) through a particular mobile network operator such as MNO-A.
• SP-1 Service Provider
• FSSO-1 cellular SSO Federation
• MNO-A mobile network operator
• Fig. 2 the process followed to authenticate such user and to authorize such service starts when a subscriber of an MNO-A (User@MNO-A) requests access (C-21) to a Bookstore Service Provider (SP- 1) .
• the SP-1 redirects (C-22) the request to the MNO-A Home site.
• the MNO-A Home Site of the user's request for accessing the SP service (C-23) .
• the user presents his own MNO-A identity, for example with a cookie.
• MNO-A acting as an Authentication Broker internally determines that MNO-A is also the Authentication Provider for that user, or else AB and AP at the MNO-A are both involved as in a more general use case, as described hereafter .
• the authentication procedure is performed. If the user was already authenticated, he presents a cookie to MNO-A for allowing MNO-A to check the status of a given user's session. The authentication is not specific for each SP unless the SP requests a specific authentication mechanism to be performed. MNO-A creates (C-24) an authentication assertion for that user specifically addressed to the SP. Then, an artifact referring to the user's authentication assertion likely including other authentication information is sent back (C-25) to the user. Artifacts are of one time usage and only valid for the specific SP they are addressed to. The user on its own presents (C-26) this artifact to the SP-1.
• the SP then verifies that the source of the artifact is valid and requests (C-27) the referred user's authentication assertion to the Home site (MNO-A) .
• the MNO-A sends back (C-28) the complete user's assertion with the required user data including at least authentication information.
• the SP- 1 thus analyses the user' s assertion and trusts the authentication performed by the user's Home Site (MNO-A).
• the SP-1 informs (C-29) the user about the service access acceptance.
• a second use case may be a user (User@MNO-A) accessing a certain Service Provider (SP-2), such as for instance a Travel Agency Service Provider.
• SP-2 Service Provider
• Said Service Provider (SP-2) is thus associated with the cellular SSO Federation (FSSO-1) through a particular cellular operator such as MNO-B, whereas the user is a subscriber of another cellular operator (MNO-A) also member of the Federation.
• FSSO-1 cellular SSO Federation
• MNO-A another cellular operator
• the process followed to authenticate such user and to authorize such service starts when a subscriber of an MNO-A (User@MN0-A) requests access (C-21) to a Service Provider like a Travel Agency Service Provider (SP- 2) for example.
• This SP-2 has a business agreement with MNO-B to offer SSO services to its users and to the users of the other members of the cellular Federation (MNO-A, MNO-C).
• MNO-A MNO-A
• MNO-C MNO-C
• MNO-B MNO-B plays the role of Authentication Broker in this use case and receives (C-33) a user's redirection from the SP-2.
• the SP does not know all home sites of the Federation and therefore no information about the user' s Home Site is passed in the redirection message.
• the MNO-B requests (C-34) the user's Home Site name. It has been considered in this reference model that the user identity is only known at his Home Site. An alternative is the sharing of user identities within the cellular Federation, however, this leads to the need of huge central directories with corresponding management tasks.
• Authentication Broker redirects (C-36) the user to his
• the SP-2 requests (C-37) this information from the AB (2).
• the AB (2) sends back (C-38) the user's Home resolution response so that the SP-2 can contact (C-27) the user' s Home Site (MNO-A) to get the referred user' s assertion.
• MNO-A sends back (C-28) the complete user's assertion with the required user data including at least authentication information.
• the SP-2 analyses the user's assertion and trusts the authentication performed by the user's Home Site.
• the SP-2 allows (C-29) the user to access the service.
• Such architecture is described with reference to the external interfaces between Federation members, Service Providers and Users. These interfaces include an interface between a User, or rather a User Equipment (UE) , and the Authentication Broker (hereinafter UE-AB i/f) ; another interface between the User or UE and the Authentication Provider (hereinafter UE-AP i/f) ; another interface between the Service Provider and the Authentication Provider (hereinafter SP-AP i/f) ; and another interface between the Service Provider and the Authentication Broker (hereinafter SP-AB i/f) .
• UE-AB i/f User Equipment
• SP-AP i/f Service Provider
• SP-AB i/f another interface between the Service Provider and the Authentication Broker
• These interfaces provide channels for communicating between the different entities involved, internal and external to the Federation.
• These channels depicted in Fig. 4, provide the bases for a suitable architecture.
• the UE-AB i/f allows the AB to redirect the user to the AP responsible for his authentication.
• This interface supports such redirection, for example, by the user providing the AP name to the AB and the AB translating it to an entrance point in the AP site.
• This communication interface is part of the so-called “Broker Channel (AB) " (1, 2) in the Home Site.
• the UE-AP i/f supports an authentication session between both actors, the User and the Authentication Provider (4, 5, 6). Once authenticated, the User is redirected to the SP with a sort of token or credentials. This communication interface is referred to as the "Front Channel (AP) " (4') in the Home Site.
• the SP-AP i/f is mainly used to exchange user information like authentication, attributes, authorization, and assertions. This communication is transparent to the user, and hereinafter referred to as the "Back Channel
• the SP-AB i/f supports the establishment of the back channel wherein, for example, the AB translates the source ID contained in the artifact to an entrance point in the user's AP or PKI support. This interface is also part of the so-called “Broker Channel (AB) " (1, 2) in the Home Site.
• Fig. 4 also shows functional components that an MNO may support in order to become an AP and an AB in an F-SSO solution.
• the architecture can be regarded as comprising a Front Channel, a Back Channel and a Broker Channel view.
• an Authentication Provider (4, 5, 6) may be regarded as comprising a Front Channel (4') and a Back Channel (4").
• the Front Channel is intended for controlling the authentication of a user and for managing a master session between the user and the AP.
• a significant amount of the control logic needed to deploy the F-SSO service is located in the entities of the front channel.
• the Back Channel is intended for handling a direct communication between the SP and the AP for exchanging user information.
• the Broker Channel is responsible for supporting the address resolution needs of the SP and the user.
• the AP authenticates a user, the AP creates a session and leaves an encrypted cookie in the user' s browser for subsequent authentication queries.
• the AP needs to keep track of the Service sessions established between users and each SP. For this reason, in accordance with an aspect of the present invention and as shown in Fig. 4, the AP comprises an SSO Session Manager (41) that, being preferably located at the Front Channel, inter-works with the Back Channel and is interconnected with an AP Web Front End (42) located at the Front Channel as well. Moreover, the AP includes a Session Database (43) for storing and maintaining such information, the Session Database preferably being located at the Front Channel and interconnected with the SSO Session Manager (41) .
• SSO_auth_ID single sign-on authentication identity
• MSISDN/IMSI which pertains to access to and from a mobile phone - User ⁇ domain or user ⁇ realm, e.g. user@mno.com
• the Authentication Provider may administer a plurality of the SSO__auth_ID' s for each user, but needs to define a so-called "Main Single Sign-On Identity” (hereinafter referred to as SSO_MAIN_ID) for each user that correlates the plurality of SSO_auth_ID' s .
• SSO_MAIN_ID is intended for operator purposes, more specifically for the AP, and its format is left up to the operator, that is, it may or may not match an SSO_auth_ID pertaining to the user.
• SP_user_ID service provider user identity
• SP_user_ID Service provider user identity
• the SSO_MAIN_ID of a user as a correlating key to at least one SSO_auth_ID that uniquely authenticates a user at the user's home operator, namely at an AP, and describe the SP_user_ID that identifies the user at a given Service Provider.
• the SSO_MAIN_ID, the SSO_auth_ID, and the SP_user_ID do not match each other, and a user does not wish to furnish either identity to other actors.
• the user may be known to the SP and to the AP with an identity that is shared between both, the so-called SHARED_ID.
• This SHARED_ID may either be permanent or temporary depending on the specific scenario considered. This identity can be considered an opaque handling used by the SP and the AP for referring to the same user.
• an Authentication Provider correlates the SSO_auth_ID, SSO_MAIN_ID and SHARED_ID whereas a Service provider correlates SP_user_ID and SHARED_ID.
• An exemplary relationship between these identities is shown in Fig. 10 in a non-restrictive manner. The way these identities are administered by the different actors, as well as how these identities are linked to each other, is not described further for purposes of the present invention.
• the mechanism in Fig. 6 starts when a user accesses (C-21) an SP, and is redirected (C-22) to his Home Site. Then, the first sequence (I) in Fig. 5A shows the user issuing an SSO Authentication http request (C-23' ) from his own web server.
• the user identification could be done by means of an encrypted cookie (C-23") , if there is one stored in the user's web agent from a previous SSO session that took place in the past.
• the encryption of the cookie is recommended to avoid revealing the user identity, SSO_MAIN_ID, in case someone else obtains such cookie, either by physically accessing the computer used for the SSO session or by means of scripts intended to steal cookies from web browsers.
• the encryption algorithm and key management is completely left up to the AP.
• the user web browser does not need understand the cookie content. In order to secure this process and to prevent stealing cookies in the network path to the web server, the connection might always be done over an https .
• the user identity to be stored in that cookie should be the one selected as SSO MAIN ID. It would be convenient to use an identity other than the MSISDN or the IMSI for privacy reasons.
• the user web browser is directed to the Web Front End (42) (hereinafter Web F/E) located at the AP Front Channel.
• Web F/E Web Front End
• a plug-in is automatically downloaded with the software that implements the client side of the authentication web service, such as a Simple Object Access Protocol (SOAP) client.
• SOAP Simple Object Access Protocol
• the Web F/E interfaces (C-500) the SSO Session Manager (41) to determine if there is an active session associated with the relevant IMSI, or with other user identity used for a similar purpose. In the present case, there will not be any session active at this point, since the user was not previously authenticated.
• the identity to be presented (C-505) to the Web F/E is the IMSI, stored in the SIM.
• the IMSI should preferably be sent in the SOAP request assuming that the dialog is carried over a secure connection, namely https, without risking security requirements.
• the SSO Session Manager is contacted (C-506) again and, detecting that the user does not have an active session established, it acts as a RADIUS client and requests access (C-507, C-508) to an Authentication, Authorization and Accounting (AAA) server (44) .
• AAA Authentication, Authorization and Accounting
• the IMSI is used as applicable identity and is encapsulated in an Attribute Value Pair (AVP) of an Extensible Authentication Protocol (EAP) and in the User-Name AVP.
• AVP Attribute Value Pair
• the AAA server (44) may request (C-509,
• B/E Auth Back End Authentication Server
• This "B/E Auth. Server” is preferably reached via
• Session Manager thus acting as a RADIUS client can modify such NAI realm.
• the "B/E Auth. Server” may require further credentials (C-510 to C-517), this process involving more EAP roundtrips .
• the AAA server (44) Once the AAA server (44) has successfully authenticated the user, it sends an Access Accept message back (C-518) to the SSO Session Manager.
• the SSO Session Manager (41) must create now an entry for that user in the session database, including the SSO_auth_ID and the SSO_MAIN_ID. If the SSO Session Manager does not know the SSO_MAIN_ID yet, it queries (C-519) an Identity Manager (70) by providing the SSO_auth_ID as the look-up key for that user.
• CDS Common Directory Service
• C-522 SSO_MAIN_ID' s
• C-520, C-521 the SSO Session Manager (41) creates an entry, namely a session, for that user in the Session Database (43) by including the particular SSO_auth_ID used during such user authentication and the SSO_MAIN_ID.
• additional logic in the Web F/E not shown in Fig. 5B must maintain the session state between subsequent http requests, for example by sending a cookie to the user web browser.
• the SSO Session Manager (41) after having a valid session for a given user, fetches (C-550, C-551) from the Identity Manager (70) the identity of that user for the corresponding Service Provider (SP) , namely a SHARED_ID.
• SP Service Provider
• this SHARED_ID and the corresponding SP, for which such identity is used are stored in the Session Database (43) associated with the master session entry for that user.
• the SSO Session Manager (41) invokes (C-552) a service in a Security Assertion Mark-up Language (SAML) engine (45) , in order to generate an authentication assertion for the given SHARED_ID and for the given Service Provider.
• the assertion includes other relevant data, such as the date and time when the authentication process took place, and the associated security strength of the concrete authentication mechanism.
• the assertion is stored (C-553) in the Assertion Database (46), likely indexed by an assertion reference. Thus, the assertion is given an "assertion reference" to uniquely identify it later on.
• the assertion reference is encoded in an authentication Artifact at the SAML engine, which is returned (C-554) to the SSO Session Manager for further submission via the AP Web F/E (C-555) to the user (C-25) .
• Such artifact is preferably returned to the user encoded as a part of the URL, namely a parameter.
• the user web browser is redirected back to the original URL that was sent to the SP.
• this information came as a parameter in the URL received at the first redirection from the SP to the AP. Therefore, the original URL that came from the SP, the target resource, should have been stored at the AP Web F/E.
• the user presents the artifact (C-26) to the originally contacted SP.
• the SP takes the artifact, and after decoding, extracts the assertion reference and the identity of the ⁇ AP that issued the assertion.
• the SP uses this information to establish a SAML dialog (C-27) with the AP Back Channel (4") , and requests the original assertion, by presenting the artifact in the SAML assertion request message.
• the SAML engine (45) in the AP Back Channel receives the request for an assertion (C-27), it fetches the assertion (C-556, C-557) from the Assertion Database (46), digitally signs it, and sends it back to the SP (C-28) .
• the SP checks the validity of the assertion, preferably by making use of its own Public Key Infrastructure (PKI) or, in a more generic case further explained, by making use of the PKI of a trusted authentication broker.
• PKI Public Key Infrastructure
• the SP can proceed to parse the assertion content and enforce his local policies according to the authentication facts included in the assertion. Finally, the user is informed (C-29) of the service access acceptance.
• Fig. 7A and 7B By including the three sequenced sets of actions (Sequence I, II, and III) respectively depicted in Fig. 5A to Fig. 5C, embodiments in Fig. 7A and 7B also describe details of the use case in Fig. 2, under the architectural model in Fig. 4, wherein the user accessing an SP has already been authenticated by his Home network. More specifically, Fig. 7A presents an isolated authentication of a user before an Authentication Provider at his Home network, whereas Fig. 7B presents the actions carried out when the user accesses an SP, and once redirected to his Home network the user is found to be already authenticated and having a valid session still alive.
• Fig. 7A directly starts with the first sequence (I) shown in Fig. 5A wherein the user issues an SSO Authentication http request (C-23') from his own web server followed, if available, by a user identification with an encrypted cookie (C-23") sent towards the Web F/E at the AP Front Channel as in the corresponding sequence shown in respect of the use case in Fig. 6. Afterwards, the Web F/E interfaces (C-500) the SSO Session Manager (41) to check if there is an active session associated with that user. The sequence flow follows with the second sequence (II) shown in Fig. 5B wherein the authentication procedure, as likely selected by the user, is carried out.
• the SSO Session Manager (41) has created a session for the user in the Session Database (43) , in fact by including the particular SSO_auth_ID used and the SSO_MAIN_ID, the SSO Session Manager informs the AP Web F/E wherein additional logic not shown in Fig. 5B maintains the session state for subsequent http requests. Eventually, as shown in Fig. 7A the AP Web F/E acknowledges (C-70) a successful Sign-On towards the user web browser.
• This user already authenticated may request (C-21) a service access to an SP.
• This SP under the assumptions stated above for the use case in Fig. 2 wherein an Authentication Broker is not needed, redirects (C-22) the user to his Home Site.
• the user accesses once more the given AP Web F/E (42) from which an indication is issued toward the SSO Session Manager (41) to check whether or not a valid session is still alive.
• the SSO Session Manager (41) likely in co-operation with a Session Database (43) finds out that a session already exists for that user.
• the SSO Session Manager (41) fetches (C-550, C-551) a SHARED_ID to be used for that SP, orders (C-552, C-553, C-554) the generation and storage of an assertion for said SHARED_ID and its inclusion in an authentication artifact.
• the artifact is returned via the Web F/E (C-555) to the user (C-25) and presented (C-26) as in the use case before to the SP.
• the SP checks the original assertion (C-27, C-556, C-557, C-28) with the AP Back Channel (4"), and eventually offers (C-29) service access acceptance to the user.
• a second use case occurs when a user (User@MN0-A) accesses a certain Service Provider (SP-2) that is associated with a cellular SSO Federation (FSSO-1) through a particular cellular operator such as MNO-B, whereas the user is a subscriber of another cellular operator (MNO-A) which is also a member of the Federation.
• SP-2 Service Provider
• MNO-A subscriber of another cellular operator
• an Authentication Broker is needed in accordance with an aspect of the present invention for receiving the redirection from the SP (SP-2), resolving the user's Home Site, and redirecting to the MNO where the user belongs.
• Fig. 8 shows the actions to be carried out between the user and the AB before redirecting said user to an appropriate Authentication Provider (AP) at the user's Home Site. More specifically, Fig. 8 shows these actions with reference to the architectural model illustrated in Fig. 4 whereas Fig. 3 does not take into account all particular devices that an AB might comprise. Thus, when a user issues an Authentication request for the SP-2 (C-33) toward the Authentication Broker (AB) as in Fig. 3, there is actually a http redirection received in an AB Web F/E (21) at a Broker Channel (2) as Fig. 8 shows.
• a user's Home Site name is requested from the AB Web F/E (C-34, C-35) .
• This request may be done, for instance, by presenting a web page to the user with all the AP' s in the Federation, wherein the user only has to click on the logo of his Home operator.
• a URI for the user's Home Site is obtained (C-84, C-85) from an Authentication Provider (AP) Database (22) .
• AP Authentication Provider
• the AB Web F/E (21) redirects (C-36) the user's http to the appropriate AP at his Home Site.
• the AB may leave a cookie in the web browser of the user in order to avoid further user's Home related queries in successive iterations.
• the flow sequence goes on with an SSO Authentication request (C-23, C-23' , C- 23”) toward the AP Web F/E (42) as described above in respect of use cases illustrated in Fig. 6 or Fig. 7A and
• Fig. 9 shows the actions to be carried out between a Service Provider and an AB for a user' s Home resolution in order to find where the assertion should be validated. More specifically, Fig. 9 shows these actions with reference to the architectural model illustrated in Fig. 4, whereas Fig. 3 does not take into account all particular devices that an AB might comprise.
• the AB Web F/E (21) requests (C-91, C-92) from an AP Database (22) a URI of the AP at the Home Site that is sent back (C-38) to the SP.
• the SP by using preferably DNS techniques, resolves the Home URI and eventually validates (C-27, C-28) the authentication assertion, which was previously obtained
• (47) component is arranged for untying an XML instance from a transport protocol, like httms for example, and passing it over the SAML engine.
• the SP is thus entitled to make any type of query as defined in SAML standards.
• the SP does not need to implement all the PKI complexity, and neither do it for locally installing certificates from all Authentication Providers in the Federation, but just the certificate of its trusted entity in said Federation, namely the certificate of the AP hosting this Authentication Broker.

Priority Applications (7)

Applications Claiming Priority (6)

Publications (1)

Family

ID=27761357

Family Applications (1)

Country Status (9)

Cited By (14)

Families Citing this family (63)

Citations (4)

• 2003
  • 2003-02-28 JP JP2003572323A patent/JP4303130B2/ja not_active Expired - Fee Related
  • 2003-02-28 AU AU2003217103A patent/AU2003217103A1/en not_active Abandoned
  • 2003-02-28 CN CN03804871A patent/CN100592827C/zh not_active Expired - Fee Related
  • 2003-02-28 GB GB0415391A patent/GB2401509B/en not_active Expired - Fee Related
  • 2003-02-28 CA CA2473793A patent/CA2473793C/en not_active Expired - Lifetime
  • 2003-02-28 ES ES200450047A patent/ES2281228B2/es not_active Expired - Fee Related
  • 2003-02-28 WO PCT/SE2003/000342 patent/WO2003073783A1/en active IP Right Grant
  • 2003-02-28 DE DE10392283T patent/DE10392283T5/de not_active Withdrawn
• 2004
  • 2004-08-26 SE SE0402099A patent/SE527706C2/sv unknown

Patent Citations (4)

Also Published As

Similar Documents

Legal Events