EP2183901A1 - A method and system for managing user identity - Google Patents

A method and system for managing user identity

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)
French (fr)
Other versions
EP2183901A4 (en
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/en
Publication of EP2183901A4 publication Critical patent/EP2183901A4/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • 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

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

A method and a system for managing user identity in a telecommunication system.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.

Description

A METHOD AND SYSTEM FOR MANAGING USER IDENTITY
FIELD OF THE INVENTION
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
Framework .
BACKGROUND OF THE INVENTION
Management of the user identities has become an essential function in e-business and e-government applications. Today user identities on the Internet have fragmented across various places and user has multiple accounts, typically username/password, to different services on the net causing non-friendly service usage experience. Liberty Alliance has specified ID-FF (Identity Federation Framework) to enable account federation and single sign-on experience for the user.
The Liberty Alliance is a broad-based industry standards consortium developing federated identity management and web services communication protocols. In 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. In the federation process 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. In the context of Liberty Alliance, 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". In the 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.
From the operator point of view this makes the process of adding support to different authentication context classes very difficult. 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.
BRIEF DESCRIPTION OF THE INVENTION
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 . b) Authenticating and authorizing said principal terminal in the authentication system. The authentication system resides usually within the operator premises and is connected to the same network as the principal terminal . c) Said principal terminal requesting an access to the service provider. This step can take place either actively or passively. In a passive way the user has no dialogue with the user interface for the access request in any way, in an active way the user must choose the service provider he/she wants to connect . d) Redirecting the principal terminal connection to said Identity Provider server. e) Identity Provider server querying a user identity from the authentication system. f) The user identity is returned to the Identity Provider server and an identity assertion is created. g) redirecting the query from step e) to a connection-specific authentication module that is connected to the authentication system; h) the authentication module resolves the identity of the user as a response to the connection- specific information. In an embodiment according to the invention, 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.
In a further embodiment of the invention the principal terminal is authenticated by a RADIUS system. The accounting data related to the principal terminal may be collected to the RADIUS database.
In a further embodiment of the invention, 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 according to the present invention 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. According to the invention 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 .
In an embodiment of the system 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.
In an embodiment of the system the authorization system has means for collecting accounting data related to the principal terminal to the RADIUS database.
In an embodiment of the system the 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. In the Single Sign-on process IdP (Identity Provider) plays the main role and authenticates the user, creates the assertions for the user and provides the assertion data for Service Providers. 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.
BRIEF DESRIPTION OF THE DRAWING
In the following, the invention will be described in greater detail with reference to the embodiments illustrated in the attached drawings, in which
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, and
Figure 7 is a signalling diagram featuring another embodiment of the present invention. DETAILED DESCRIPTION
In Figure 1 is pictured the operating environment and relevant actors. 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. 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. In Figure 1 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. As these access technologies are coupled to different authentication systems, 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. The implication is that in theory 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.
Figure 2 is a schematic view of the architecture according to the present invention. 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.
1. The user (PT) 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.
5. 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.
6. 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 .
7. A user identity (MSISDN) is returned to IdP and assertion is created.
8. The user will be redirected back to SP with SAMLart.
9. In some cases 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.
In figure 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.
2. The user (PT) is redirected to IdP with AuthnRequest specified by Liberty ID-FF. In this authentication process the user dialog is allowed. An AuthContextClassRef is created to keep track of the authentication procedure through different elements.
3. 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.
4. 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.
6. IdP obtains the information from the one- time-password authentication module using
AuthContextClassRef .
7. A user identity is returned to IdP and the assertion is created.
8. The user (PT) will be redirected back to SP with SAMLart.
The difference between the invention and the prior art is further explained in figures 5 and 6, where figure 5 displays the single sign on method according to the prior art. Here the signalling is presented between three elements, the principal terminal (PT), the service provider (SP) and the identity provider (IdP) .
In 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. From the identity provider (IdP) the HTTP session is redirected to the service provider (SP) with SAMLart, step 2.3.
In 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. Now 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) . In step 1.1 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. Identity Provider
(IdP) maps the relevant AuthenticationContextClass to corresponding authentication module; step 1.2; and redirects the HTTP session to the authentication module, step 1.3.
Principal terminal accesses interaction pages presented by the authentication module, step 2. In the scenario of one-time-password offered by banks, the desired banking authentication method may be chosen here. In steps 2.1 and 2.2 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
(IdP) with HTTP redirect (302) message, step 2.3. This artefact can be carried for example inside the
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. In step 1.1 the identity provider (IdP) obtains requested AuthenticationContextClass from the authentication module and the passive flag is set to false. In step 1.2 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 .
The means mentioned above are means known per se, such as program components, and they are therefore not described in greater detail herein. The invention is not limited to the above embodiments but can be varied in various ways without deviating from the scope of the inventive idea defined in the claims.

Claims

1. A method for managing user identity in a telecommunication system comprising: a principal terminal (PT) ; an authentication system; an Identity Provider server (IdP); a service provider (SP) that is a member of circle of trust; wherein said method comprises the steps of: a) granting a network access to said principal terminal by a connection-specific system; b) authenticating and authorizing said principal terminal in the authentication system; c) said principal terminal requesting an access to the service provider; d) redirecting the principal terminal connection to said Identity Provider server; e) Identity Provider server querying a user identity from the authentication system; f) the user identity is returned to the Identity Provider server and an identity assertion is created, characterized in that the method further comprises the steps of: g) redirecting the query from step e) to a connection-specific authentication module that is connected to the authentication system; h) the authentication module resolves the identity of the user as a response to the connection- specific information.
2. A method as claimed in claim 1, characterized by step e) having further steps of Identity Provider server: recognizing authentication request from the service provider; and requesting access authentication data from the connection-specific authentication module.
3. A method as claimed in claim 1, characterized by authenticating the principal terminal by RADIUS system.
4. A method as claimed in claim 1, characterized by collecting accounting data related to the principal terminal to the RADIUS database.
5. A method as claimed in any of the claims 1 - 4, characterized by step f) having further steps of: 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.
6. A telecommunication system for managing user identity comprising: 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 a user identity from the authentication system and creating an identity assertion; a service provider that is a member of circle of trust and 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 ; characterized in that 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.
7. A system as claimed in claim 6, characterized in that 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 .
8. A system as claimed in claim 6, characterized in that the authentication system comprises means for authenticating the principal terminal by RADIUS system.
9. A system as claimed in claim 6, characterized in that the authorization system has means for collecting accounting data related to the principal terminal to the RADIUS database.
10. A system as claimed in any of the claims 6 - 9, characterized in that the 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.
EP08787725A 2007-08-08 2008-08-07 A method and system for managing user identity Withdrawn EP2183901A4 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20070595A FI121646B (en) 2007-08-08 2007-08-08 Method and system for managing user identity
PCT/FI2008/050452 WO2009019325A1 (en) 2007-08-08 2008-08-07 A method and system for managing user identity

Publications (2)

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

Family

ID=38468665

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08787725A Withdrawn EP2183901A4 (en) 2007-08-08 2008-08-07 A method and system for managing user identity

Country Status (3)

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

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2950775B1 (en) * 2009-09-30 2011-10-21 Alcatel Lucent DEVICE AND METHOD FOR AUTOMATED MANAGEMENT OF IDENTITY AND USER PROFILES OF COMMUNICATION EQUIPMENT
US20110191796A1 (en) * 2010-01-29 2011-08-04 Cbs Interactive, Inc. Media Player-Based Authentication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1610528A2 (en) * 2004-06-24 2005-12-28 Vodafone Group PLC System and method of asserting identities in a telecommunications network
WO2006045402A1 (en) * 2004-10-26 2006-05-04 Telecom Italia S.P.A. Method and system for transparently authenticating a mobile user to access web services
WO2007068715A1 (en) * 2005-12-16 2007-06-21 International Business Machines Corporation Method and system for extending authentication methods

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60314871T2 (en) * 2002-05-24 2008-03-13 Telefonaktiebolaget Lm Ericsson (Publ) METHOD FOR AUTHENTICATING A USER IN ACCESS TO A SERVICE PROVIDER'S SERVICE
US7207058B2 (en) * 2002-12-31 2007-04-17 American Express Travel Related Services Company, Inc. Method and system for transmitting authentication context information
CA2917442C (en) * 2005-07-25 2017-07-11 Cardinalcommerce Corporation Method and system for extending payment system via text messaging
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 (en) * 2004-06-24 2005-12-28 Vodafone Group PLC System and method of asserting identities in a telecommunications network
WO2006045402A1 (en) * 2004-10-26 2006-05-04 Telecom Italia S.P.A. Method and system for transparently authenticating a mobile user to access web services
WO2007068715A1 (en) * 2005-12-16 2007-06-21 International Business Machines Corporation Method and system for extending authentication methods

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
FI20070595A (en) 2009-02-09
FI20070595A0 (en) 2007-08-08
EP2183901A4 (en) 2010-11-03
FI121646B (en) 2011-02-15
WO2009019325A1 (en) 2009-02-12

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 (en) A kind of cross-domain single login system and login method based on SAML
CN101331731B (en) Method, apparatus and program products for custom authentication of a principal in a federation by an identity provider
CN106063308B (en) Device, identity and event management system based on user identifier
CN104539615B (en) Cascade connection authentication method based on CAS
US20060218629A1 (en) System and method of tracking single sign-on sessions
KR101635244B1 (en) User-based authentication for realtime communications
CN104158824B (en) Genuine cyber identification authentication method and system
CN102647407B (en) Information processing system, method for controlling information processing system
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 (en) A kind of authentication method and device
CN103023856A (en) Single sign-on method, single sign-on system, information processing method and information processing system
CN112039873A (en) Method for accessing business system by single sign-on
CN101567785B (en) Method, system and entity for authenticating notes in network service
CN102420808A (en) Method for realizing single signon on telecom on-line business hall
WO2012107058A1 (en) Method and system for supporting user authentication to a service
EP2183901A1 (en) A method and system for managing user identity
CN101969426B (en) Distributed user authentication system and method
CN110278178B (en) Login method, equipment and readable storage medium
CN114006751B (en) Campus system single sign-on method using temporary authentication code

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