EP2183901A1 - Procédé et système de gestion d'une identité d'utilisateur - Google Patents

Procédé et système de gestion d'une identité d'utilisateur

Info

Publication number
EP2183901A1
EP2183901A1 EP08787725A EP08787725A EP2183901A1 EP 2183901 A1 EP2183901 A1 EP 2183901A1 EP 08787725 A EP08787725 A EP 08787725A EP 08787725 A EP08787725 A EP 08787725A EP 2183901 A1 EP2183901 A1 EP 2183901A1
Authority
EP
European Patent Office
Prior art keywords
authentication
identity
principal terminal
connection
user
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP08787725A
Other languages
German (de)
English (en)
Other versions
EP2183901A4 (fr
Inventor
Paavo Lambropoulos
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
TeliaSonera Finland Oyj
Original Assignee
TeliaSonera Finland Oyj
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 TeliaSonera Finland Oyj filed Critical TeliaSonera Finland Oyj
Publication of EP2183901A1 publication Critical patent/EP2183901A1/fr
Publication of EP2183901A4 publication Critical patent/EP2183901A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/068Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys

Definitions

  • the present invention relates to managing user identity in a telecommunication system, and more particularly to a modular authentication system to be used in connection with an Identity Federated
  • the Liberty Alliance is a broad-based industry standards consortium developing federated identity management and web services communication protocols.
  • This federated model several parties, for example consumers, citizens, businesses and governments can conduct online transactions while devices and identities of all kinds are linked by federation and protected by universal strong authentication.
  • the user decides if she/he wants to access each service provider without re-authentication.
  • the condition to enable this right is that the user must authenticate at an Identity Provider who is recognised by the Service Provider.
  • a single sign-on (SSO) is the process whereby a user is able to log into a single account and request services from several services providers within a "Circle of Trust".
  • IdP SSO process Identity Provider
  • IdP plays the main role and authenticates the user, creates the assertions for the user and provides the assertion data for Service Providers.
  • Liberty Alliance has specified different authentication context classes to make possible for the Service Provider to request different kind of authentication from IdP.
  • Telecom operators may offer several connection methods to the Internet, for example via mobile phone network or laptop/desktop computer combined with different authentication methods, like SIM cards, user- id/passwords, one-time-passwords, etc. Every authentication method needs different kind of support in operator back-end systems. Usually every modification needed in the operator back-end system requires a lot of updating and cross checking between numerous systems that are dependant on that back-end system.
  • An object of the present invention is to provide a method and a system for implementing the method so as to overcome the above problem or at least to alleviate it.
  • the objects of the invention are achieved by a method and a telecommunications system for managing user, which are characterized by what is stated in the independent claims.
  • the preferred embodiments of the invention are disclosed in the dependent claims.
  • the method according to a present invention operates in a telecommunication system comprising a principal terminal, an authentication system, an Identity Provider server and a service provider that is a member of Circle of Trust.
  • the method comprises the steps of: a) Granting a network access to said principal terminal by a connection-specific system.
  • the principal terminal can be a mobile phone, computer, PDA or alike that is configured to connect to Internet by either a wireless or a wired connection .
  • the authentication system resides usually within the operator premises and is connected to the same network as the principal terminal .
  • e) Identity Provider server querying a user identity from the authentication system.
  • the Identity Provider server After querying the user identity from the authentication system, recognizes authentication request from the service provider and requests access authentication data from the connection-specific authentication module.
  • the principal terminal is authenticated by a RADIUS system.
  • the accounting data related to the principal terminal may be collected to the RADIUS database.
  • the user identity is returned to the Identity Provider server and an identity assertion is created by connection-specific authentication module receiving request from the Identity Provider server and finding out the identity of the principal terminal having the specified IP address by querying it from RADIUS server database .
  • the system comprises following elements: a principal terminal, an authentication and authorizing system comprising means for authenticating and authorizing said principal terminal and returning the user identity to an Identity Provider server, an Identity Provider server comprising means for querying the user identity from the authentication system and creating an identity assertion, a service provider that is a member of identity federated framework.
  • the system further comprises means for handling an access request from said principal terminal and means for redirecting the principal terminal connection to said Identity Provider server, a connection-specific system comprising means for granting a network access to said principal terminal.
  • the system comprises a connection-specific authentication module connected to the authentication system that has means for receiving a query from the Identity Provider server and means for resolving the identity of the user as a response to the connection-specific information .
  • the Identity Provider server has means for recognizing authentication request from the service provider and means for requesting access authentication data from the connection-specific authentication module.
  • the authentication system comprises means for authenticating the principal terminal by RADIUS system.
  • the authorization system has means for collecting accounting data related to the principal terminal to the RADIUS database.
  • connection-specific authentication module comprises means for receiving request from the Identity Provider server and means for querying the identity of the principal terminal having the specified IP address by querying it from RADIUS server database.
  • Liberty Alliance has specified ID-FF (Identity Federation Framework) to enable account federation and Single Sign-on experience for the user.
  • IdP Identity Provider
  • IdP Identity Provider
  • Liberty has specified different authentication context classes to make possible to SP request different kind of authentication from IdP.
  • the present invention describes how these authentication context classes can be mapped to different authentication methods and how the IdP server system can be designed modularly.
  • This invention introduces a modular mechanism to implement standard Liberty Alliance based identity management by coupling together the fragmented access authentication and Liberty ID-FF authentication making possible to connect Liberty interfaces to any operator's access authentication system.
  • This invention will introduce the modular architecture to extend the IdP functionality with new authentication scheme without changes to core IdP architecture.
  • the invention covers both non user interactive and user interactive methods to implement the authentication module between network access system and IdP.
  • New authentication context classes can be supported on the fly just by adding the new authentication module into the system and configuring the IdP server.
  • Figure 1 is a schematic view of the operating environment
  • Figure 2 is a schematic view of the architecture according to the present invention.
  • Figure 3 is a schematic example of the non- interactive authentication
  • Figure 4 is a schematic example of the authentication utilizing the one-time-password method
  • Figure 5 is a signalling diagram featuring the single sign on method according to the prior art
  • Figure 6 is a signalling diagram featuring the method according to the present invention.
  • FIG. 7 is a signalling diagram featuring another embodiment of the present invention.
  • Principal terminal PT is connected to an IP network.
  • Principal terminal PT can be for example a user terminal, connected to the user identity or another entity that could have an identity such as a car, any home appliance such as a washing machine, entertainment system, alerting system, etc.
  • Service provider SP is also connected to the
  • IP network IP network.
  • Service providers are organizations offering services to users, such as Internet portals, retailers, transportation providers, financial institutions, entertainment companies, not-for-profit organizations, governmental agencies, etc.
  • Identity providers IdP are service providers that are distributing the true identity of the principal terminal PT to other service providers, thus creating a Circle of Trust between different entities. The establishment of the Circle of Trust is further explained by the Liberty Alliance documentation, such as Liberty ID-FF Architecture Overview, draft-liberty- idff-arch-overview-1.2-errata-vl.0.pdf, available from www . proj ect licorty . Drg .
  • the Liberty Alliance does not explicitly specify how a service provider should process the identities to Principals and how those Principals authenticate themselves to the identity provider. These requirements are left to be determined by the nature of the service, the sensitivity of any information exchanged, the associated financial value, the service provider's risk tolerance, etc.
  • Authentication context is defined as the information, additional to the authentication assertion itself, that the service provider may require before it makes an entitlements decision with respect to an authentication assertion.
  • these different authentication backend systems are pictured as ABl to AB5, representing access technologies such as GPRS, DSL, MSSP, or any other system that is used by the user to access the network.
  • access technologies such as userid-password, one time passwords, SIM or smartcard based authentication, PKI authentication
  • the authentication context class must be configured to each of these combinations.
  • Different configurations for different authentication contexts are handled by authentication modules AM1...AM3. According to the Liberty Alliance, the number of permutations of the different authentication context characteristics ensures that there are a theoretically infinite number of unique authentication contexts.
  • any particular relying party would be expected to be able to parse arbitrary authentication context statements and, more importantly, to analyze the statement in order to assess the 'quality' of the associated authentication assertion.
  • This system is optimized by defining a number of different Authentication Context Classes. Each class will define a proper subset of the full set of authentication contexts.
  • An identity provider may include with the complete authentication context statement it provides to a service provider an assertion that the authentication context also belongs to one of the Liberty defined authentication classes. For some service providers, this assertion will be sufficient detail for it to be able to assign an appropriate level of confidence to the associated authentication assertion.
  • ID-FF API comprises authentication plug-in modules that are connected to each authentication modules, such as userid/password, one time password, GPRS authorization delegation, EAP-SIM, EAP-AKA or MSSP.
  • ID-FF API has the IdP functionality comprising the corresponding assertion creation to each authentication context class handled by the IdP.
  • ID-FF API comprises also information of the IdP configuration and federation tables .
  • Figure 3 is an example of the non-interactive user access authentication and Liberty ID-FF authentication.
  • the numbering in the following text is related to the arrows representing information flow in Figure 3.
  • the user requests access to an IP network, in this example a PDP context request by the GPRS network. 2.
  • the user will be authenticated by backend
  • RADIUS system and IP address will be allocated for the user to gain the access to the Internet (Authorization process) . Accounting data will be collected to RADIUS database consisting IP Address and MSISDN. 3.
  • the user (PT) accesses Liberty SP and requests authentication. This is done by logging in to the system with the help of relevant authentication method. In this example the authentication information can be obtained from the GPRS system. 4.
  • the user (PT) is redirected to IdP with
  • AuthnRequest specified by Liberty ID-FF. Passive flag is set to true to indicate IdP that user dialog is not allowed in authentication process.
  • An AuthContextClassRef is created to keep track of the authentication procedure during different elements.
  • IdP recognizes AuthnRequest and based on the authentication plug-in rules it will request access authentication data from GPRS authentication module. This decision can be made for example if passive mode is set TRUE in AuthnRequest sent by SP.
  • GPRS authentication module receives incoming request and finds out the identity of the user having the specified IP address and finds out the user identity by querying it from the RADIUS server database .
  • a user identity (MSISDN) is returned to IdP and assertion is created.
  • an optional process step is that SP queries assertion from IdP by SAMLart.
  • the inventive part of this sequence is to define the separate module responsible for getting the data from access level authentication to Liberty layer. This module (in this example GPRS authentication module) will couple IdP and backend access authentication systems together.
  • FIG 4 the arrangement differs from the previous example by the authentication method.
  • the numbering in the following text is related to the arrows representing information flow in Figure 4. 1.
  • the user (PT) requests access to service provider SP, in this example the network access method is not relevant.
  • the user (PT) is redirected to IdP with AuthnRequest specified by Liberty ID-FF.
  • IdP IdP
  • AuthnRequest specified by Liberty ID-FF.
  • An AuthContextClassRef is created to keep track of the authentication procedure through different elements.
  • IdP recognizes AuthnRequest and based on the authentication plug-in rules it will request access authentication data from the one-time-password authentication module.
  • An example of the one-time- password authentication is the TUPAS authentication method used by Finnish banking sector.
  • One-time-password authentication module directs the authentication to a separate banking authorization service. 5. Authorization information from the banking authorization service is returned to the one-time- password authentication module.
  • IdP obtains the information from the one- time-password authentication module using
  • figure 5 displays the single sign on method according to the prior art.
  • the signalling is presented between three elements, the principal terminal (PT), the service provider (SP) and the identity provider (IdP) .
  • step 1 the principal terminal selects the IdP authentication.
  • the service provider (SP) redirects the session to IdP login URL address, step 1.1.
  • the Principal terminal makes the authentication request to identity provider (IdP) as the single sign on session does not exist, step 2.
  • the user is authenticated in step 2.1 and the identity assertion is created in step 2.2.
  • the HTTP session is redirected to the service provider (SP) with SAMLart, step 2.3.
  • step 3 the Principal terminal logs in to the service provider (SP) with SAMLart.
  • the service provider (SP) does the SOAP assertion query by SAMLart from the identity provider (IdP), step 3.1, and the assertion is returned in step 3.1.1.
  • the principal terminal has been identified and the service provider (SP) presents the welcome page.
  • the method according to the present invention is presented in figure 6. The difference between the prior art is highlighted by adding the inventive element, authentication module, to the signalling diagram.
  • Step 1 relates to step 2 in the previous example, in which the principal terminal selects the authentication request to the identity provider (IdP) .
  • the identity provider (IdP) obtains the requested AuthenticationContextClass and sets the passive flag to no indicating that the authentication is done in an interactive manner.
  • (IdP) maps the relevant AuthenticationContextClass to corresponding authentication module; step 1.2; and redirects the HTTP session to the authentication module, step 1.3.
  • the desired banking authentication method may be chosen here.
  • the user is authenticated by the backend authentication system, for example said one-time-password system. From the authentication module the authentication module artefact is created and sent to identity provider
  • AuthenticationContextClassRef message In step 3 the principal terminal requests authentication from the identity provider (IdP) with authentication module artefact. Identity provider (IdP) queries identity assertion from the authentication module; step 3.1; and creates assertion as a response to the query. In step 3.3 the principal terminal is redirected to the service provider with HTTP redirect (302) message with SAMLart .
  • Figure 7 differs from Figure 6 in that the authentication is done in a passive manner, the user sees less authentication screens than in the previous example.
  • Principal terminal requests authorization from the identity provider (IdP), step 1.
  • the identity provider (IdP) obtains requested AuthenticationContextClass from the authentication module and the passive flag is set to false.
  • the AuthenticationContextClass is mapped to the authentication module.
  • Identity provider (IdP) requests authentication using principal terminals IP address from the authentication module, step 1.3.
  • the authentication module authenticates user using the backend authentication system, step 1.3.1. After this authentication the identity provider (IdP) is ready to create assertion, step 1.4. Now the session is transferred to service provider with HTTP redirect (302) message with SAMLart .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention a pour objet un procédé et un système de gestion d'une identité d'utilisateur dans un système de télécommunication. Un mécanisme modulaire destiné à mettre en place une gestion d'identité basée sur une alliance Liberty standard, en associant l'authentification d'accès fragmenté à l'authentification ID-FF Liberty, permet de connecter des interfaces Liberty au système d'authentification d'accès de tout opérateur.
EP08787725A 2007-08-08 2008-08-07 Procédé et système de gestion d'une identité d'utilisateur Withdrawn EP2183901A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20070595A FI121646B (fi) 2007-08-08 2007-08-08 Menetelmä ja järjestelmä käyttäjäidentiteetin hallintaan
PCT/FI2008/050452 WO2009019325A1 (fr) 2007-08-08 2008-08-07 Procédé et système de gestion d'une identité d'utilisateur

Publications (2)

Publication Number Publication Date
EP2183901A1 true EP2183901A1 (fr) 2010-05-12
EP2183901A4 EP2183901A4 (fr) 2010-11-03

Family

ID=38468665

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08787725A Withdrawn EP2183901A4 (fr) 2007-08-08 2008-08-07 Procédé et système de gestion d'une identité d'utilisateur

Country Status (3)

Country Link
EP (1) EP2183901A4 (fr)
FI (1) FI121646B (fr)
WO (1) WO2009019325A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2950775B1 (fr) * 2009-09-30 2011-10-21 Alcatel Lucent Dispositif et procede de gestion automatisee d'identites et de profils d'usagers d'equipements de communication
WO2011094723A1 (fr) * 2010-01-29 2011-08-04 Cbs Interactive, Inc. Authentification par lecteur multimédia

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1610528A2 (fr) * 2004-06-24 2005-12-28 Vodafone Group PLC Système et procédé d'assertion d'identités dans un réseau de télécommunications
WO2006045402A1 (fr) * 2004-10-26 2006-05-04 Telecom Italia S.P.A. Procede et systeme permettant d'authentifier de maniere transparente un utilisateur mobile pour acceder a des services web
WO2007068715A1 (fr) * 2005-12-16 2007-06-21 International Business Machines Corporation Procede et systeme permettant d'elargir des procedes d'authentification

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100989487B1 (ko) * 2002-05-24 2010-10-22 텔레폰악티에볼라겟엘엠에릭슨(펍) 서비스 제공자의 서비스에 대한 사용자를 인증하는 방법
US7207058B2 (en) * 2002-12-31 2007-04-17 American Express Travel Related Services Company, Inc. Method and system for transmitting authentication context information
CA2917442C (fr) * 2005-07-25 2017-07-11 Cardinalcommerce Corporation Methode et systeme de report d'un paiement par messagerie texte
US8418234B2 (en) * 2005-12-15 2013-04-09 International Business Machines Corporation Authentication of a principal in a federation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1610528A2 (fr) * 2004-06-24 2005-12-28 Vodafone Group PLC Système et procédé d'assertion d'identités dans un réseau de télécommunications
WO2006045402A1 (fr) * 2004-10-26 2006-05-04 Telecom Italia S.P.A. Procede et systeme permettant d'authentifier de maniere transparente un utilisateur mobile pour acceder a des services web
WO2007068715A1 (fr) * 2005-12-16 2007-06-21 International Business Machines Corporation Procede et systeme permettant d'elargir des procedes d'authentification

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DO VAN THANH ET AL: "NETp1-09: Enhancing Internet Service Security Using GSM SIM Authentication" 1 November 2006 (2006-11-01), GLOBAL TELECOMMUNICATIONS CONFERENCE, 2006. GLOBECOM '06. IEEE, IEEE, PI, PAGE(S) 1 - 5 , XP031075237 ISBN: 978-1-4244-0356-1 * paragraphs [0III], [00IV] * *
See also references of WO2009019325A1 *

Also Published As

Publication number Publication date
EP2183901A4 (fr) 2010-11-03
FI20070595A0 (fi) 2007-08-08
WO2009019325A1 (fr) 2009-02-12
FI121646B (fi) 2011-02-15
FI20070595A (fi) 2009-02-09

Similar Documents

Publication Publication Date Title
US10382434B2 (en) Actively federated mobile authentication
US8495720B2 (en) Method and system for providing multifactor authentication
US20200106766A1 (en) Method and system for security assertion markup language (saml) service provider-initiated single sign-on
CN104301418B (zh) 一种基于saml的跨域单点登录系统及登录方法
CN101331731B (zh) 由身份提供商对联盟内的客户进行定制认证的方法、装置和程序产品
CN106063308B (zh) 基于用户标识符的装置、身份和活动管理系统
CN104539615B (zh) 基于cas的级联认证方法
US20060218629A1 (en) System and method of tracking single sign-on sessions
KR101635244B1 (ko) 실시간 통신을 위한 사용자-기반 인증
CN104158824B (zh) 网络实名认证方法及系统
CN102647407B (zh) 信息处理系统及信息处理系统的控制方法
US20060218630A1 (en) Opt-in linking to a single sign-on account
US20110287739A1 (en) Managing automatic log in to internet target resources
US20040064687A1 (en) Providing identity-related information and preventing man-in-the-middle attacks
Berbecaru et al. Providing login and Wi-Fi access services with the eIDAS network: A practical approach
CN106878283A (zh) 一种认证方法及装置
CN103023856A (zh) 单点登录的方法、系统和信息处理方法、系统
CN112039873A (zh) 一种单点登录访问业务系统的方法
CN101567785B (zh) 网络服务中的票据认证方法、系统及实体
CN102420808A (zh) 一种在电信网上营业厅实现单点登录的方法
EP2183901A1 (fr) Procédé et système de gestion d'une identité d'utilisateur
CN101969426B (zh) 分布式用户认证系统及其方法
CN110278178B (zh) 一种登录方法、设备及可读存储介质
CN114006751B (zh) 一种使用临时认证码的校园系统单点登录方法
US10623396B2 (en) System and method for controlling system

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100308

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

A4 Supplementary search report drawn up and despatched

Effective date: 20101001

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20110301