FI121646B - Method and system for managing user identity - Google Patents

Description

METHOD AND SYSTEM FOR MANAGING USER IDENTITY

FIELD OF THE INVENTION

The present invention relates to user identity management in a telecommunication system, and in particular to a modular authentication system used in connection with an Identity Federated Framework.

10

BACKGROUND OF THE INVENTION

User Identity Management has become a central feature of e-commerce and e-government applications. Today, the identities of the users 15 are fragmented across the Internet and the user has-multiple accounts, typically a username / password, for different services, resulting in an unpleasant service experience.

; The Liberty Alliance has defined ID-FF (Identity 20 Federation Framework) to enable account federation and single sign-on experience for the user.

The Liberty Alliance is a broad-based industry standard consortium that develops a federated identity management and online service communications protocol suite of 25. In this federated model, multiple parties, such as consumers, citizens, and administrations, can conduct web-based transactions when various devices and identities are linked by federation cm and protected by general strong authentication. In the federation process, the user decides whether he or she wants to access the cd for each service provider without having to re-authenticate. Enabling this right

CC

provided that the user must authenticate with the Identity

LO

σ> a service provider recognized by the Service Provider.

ft? 35 In the context of the Liberty Alliance, Single Sign-On (SNO) is a process whereby a user is able to 2 log in to a single account and request services from multiple service providers from the "Trust Trust". In the SSO process, the Identity Provider (IdP) plays a key role and authenticates 5 users, creates collateral for the user and arranges collateral information for the Providers. The Liberty Alliance has defined different authentication context classes to allow the Service Provider to request different authentication from IdP.

10 From the operator's point of view, this makes it particularly difficult to set up support for different authentication context classes. A telecom operator may provide several ways to connect to the Internet, for example, via a cellular network or 15 laptops / desktops, combined with various authentication methods such as SIM cards, username / passwords, disposable passwords, etc. Each authentication method requires different support in operator backend systems. Typically, every change to backend systems requires a great deal of updating and cross-checking between the countless systems dependent on that backend.

BRIEF DESCRIPTION OF THE INVENTION

It is an object of the present invention to provide a method and system for implementing the method which eliminate or at least alleviate the above problem. The objects of the invention are achieved by

(M

V 30 and the telecommunications system of the user

CD

i-control, known from what is stated in the c independent claims. Advantageous of the Invention

CL

applications are set forth in the dependent claims.

01 m The method o 35 of the present invention operates in a telecommunications system comprising

o

^ primary terminal, authentication system,

Identity Provider Server and Service Provider,

F

3 who is a member of the Trust Circle. The method includes the following steps: a) Granting access to the network to said primary terminal using a connection-specific system. The primary terminal may be a cellular telephone, computer, PDA or the like configured to connect to the Internet via either a wired or wireless connection.

b) Authenticating and authorizing said 10 primary terminals in the authentication system.

The authentication system is usually located at the operator's premises and is connected to the same network as the primary terminal.

c) The said primary terminal requests 15 access to the service provider. This step can be done either actively or passively. In a passive manner, the user has no dialogue with the user interface to request access, in an active way the user must select the service provider 20 to which he wants to connect.

d) rerouting the connection of the primary terminal to said Identity Provider Server.

e) The identity provider requests user identity from the authentication system.

f) The user identity is returned to the Identi provider and an identity security is established.

o g) Redirecting the request from step e) to a connection-specific authentication module 30 connected to the authentication system; i cd h) the authentication module determines the identity of the user x in response to the connection-specific information.

CC

In one embodiment of the invention, Identity-LO .... ...

σ> Provider Service, after inquiring about] 35 ° authentication system, identifies authentication-

o

° request from the service provider and request access authentication data from the connection-specific authentication module.

In one embodiment of the invention, the primary terminal is authenticated with a RADIUS system. Subscriber data associated with the primary 5 can be collected in the RADIUS database.

In one embodiment of the invention, user identity is returned to the Identity Provider server and an identity security is created by a 10 connection-specific authentication module that receives a request from the Identity Provider server and retrieves the identity of the primary terminal having a specific IP address by querying it from the RADIUS server.

The system of the invention comprises the following elements: a primary terminal, an authentication and authorization system comprising means for authenticating and authorizing said primary terminal and returning user identity to an identity provider server, an identity provider server comprising means for requesting a user identity, and service provider that is a member of the identity federated framework 25. The system further includes means for processing an access request of said primary terminal and means for connecting the primary terminal o. ...

w for redirecting to said server of Identity Provider ^ 30, a connection-specific system including means for providing a network connection to said primary terminal. According to the invention, the system includes a connection-specific authentication module m σ> coupled to an authentication system of means 35,

o

receive from the Identity Provider server 5, and means for determining the identity of the user in response to the connection-specific information.

In an embodiment of the invention, the identity provider server has means for recognizing an authentication request from the provider and means for requesting access authentication data from the connection-specific authentication module. The authentication system includes means for authenticating the primary terminal in the RADIUS system.

In an embodiment of the invention, the authorization system includes means for collecting access information associated with a primary terminal in a RADIUS database.

In a system application, the connection-specific authentication module 15 comprises means for receiving a request from the Identity Provider server and means for requesting identity from a primary terminal having a specific IP address requested from the RADIUS server database.

20 The ID-FF (Identity Federation Framework) has been defined by the Liberty Alliance to enable the account federation and single sign-on experience for the user. In the single sign-on process, IdP (Identity Provider) plays a key role and authenticates the user, creates collateral for the user and arranges security information for the Service Providers. Liberty has defined different authentication context classes to allow the Service Provider to request different authentication from IdP. The present invention discloses how these authentication context classes can be targeted to different authentication methods and how the x IdP server system can be modularly designed.

LO

g The present invention provides a modular mechanism for 35 min that implements a standard Liberty Alliance oo-based identity management by combining fragmented access authentication and Liberty ID-FF-

S

6 authentication, allowing Liberty interfaces to be connected to any operator's main synauthentication system. The present invention will present a modular architecture for extending the IdP function-5 functionality with a new authentication system without modifying the core IdP architecture. The invention encompasses both non-user interactive and user interactive methods for implementing an authentication module between a network access system and 10 IdPs. New authentication context classes can only be supported on the fly by adding a new authentication module to the system and configuring the IdP server.

15 BRIEF DESCRIPTION OF THE DRAWING

The invention will now be described in more detail with reference to the embodiments illustrated in the accompanying drawings, in which:

Figure 1 is a schematic view of a functional environment,

Figure 2 is a schematic view of an architecture according to the invention,

Figure 3 is a schematic example of non-interactive authentication, Figure 4 is a schematic example of an authentication that utilizes the disposable password method,

Fig. 5 is a signaling diagram of a single sign-on δ method according to the prior art, ci

Figure 6 is a signaling diagram of a method according to the present invention, and

co 'J

Figure 7 is a signaling diagram of the present

X

£ another embodiment of the invention.

io

CD

g - DETAILED DESCRIPTION

OF·

o

o 35 Figure 1 shows the operating environment and relevant actors. The primary terminal PT is connected to an IP network. The primary terminal PT may be, for example, a user terminal, associated with a user's identity or other entity that may have an identity, such as a car, any home appliance such as a washing machine, entertainment system, alarm system, etc.

The service provider SP is also connected to the IP network. Service Providers are organizations providing services to users, such as Internet portals, resellers, transportation providers, financial institutions, entertainment companies, non-commercial organizations, government agencies, etc. Identity Providers IdP are service providers that share their primary 15 terminal devices with service providers, thus creating a "Circle of Trust" between different entities. Confidence building is further explained in the Liberty Alliance documentation, such as the Liberty ID-20 FF Architecture Overview, draft-Liberty-idff-arch-overview-1.2-errata-vl.0.pdf, available at ww w. p r o j e c 11 i be r t y. o r g.

The Liberty Alliance does not clearly define how the service provider should process identities for the 25 primary terminals and how the primary terminals authenticate to the identity provider. These requirements are left to be determined by the nature of the service, the sensitivity of the information to be exchanged, the value of the associated money, the risk tolerance of the service provider, and the like.

The authentication context is defined as the information that the service provider may require in addition to the authentication security itself before making the legal

LO

the path to the authentication security. In Figure 1, these various authentication backend systems are described from AB1 to AB5, illustrating interface technologies such as GPRS, DSL, MSSP, or any other 8 system used by the user to connect to the network. When these interface technologies are combined with various authentication systems, such as a username password, a one-time password, SIM or smart-card based authentication, PKI authentication, the authentication context class must be configured for each of these combinations. Different configurations for different authentication contexts are handled by the authentication modules AM1 ... AM3. According to the Liberty Alliance 10, the number of permutations of different authentication context features guarantees an infinite number of unique authentication contexts. The conclusion is that the relying party in theory would be expected to be able to parse the extraordinary 15-authenticating tikontekstilauseita, and in particular, to analyze the phrase in order to assess the connected autentikointivakuuden 'quality'. This system is optimized by defining a number of different Authentication Context classes. Each class defines a sufficient subset of the full set of 20 authentication contexts. The identity provider may include in the complete authentication context statement it provides to the service provider that the authentication context also belongs to one of the authentication classes defined by Liberty. For Joil-25 Lek Service Providers, this security is a sufficient detail to demonstrate an appropriate level of confidence in the attached authentication assurance.

Fig. 2 is a schematic representation of the present C 1

V 30 of the architecture of the invention. ID-FF

The API includes authentication plugin modules that are associated with each authentication module, such as 0_ username / password, disposable password, GPRS-au-io g delegation delegation, ΕΑΡ-SIM, EAP-AKA or MSSP. The ID-35 FF API has the IdP functionality, which includes the creation of a security corresponding to each authentication context class handled by the IdP. The ID-FF API also includes information about the IdP configuration and federation tables.

Figure 3 shows an example of non-interactive user access authentication and Liberty ID-FF au-5 authentication. The numbering of the following text refers to the arrows depicting the data flow in Figure 3.

1. The user requests access to an IP network, in this example a PDP context request to a GPRS network.

2. The user is authenticated in the background RADIUS-10 system and the user is allocated an IP address to gain access to the Internet (Auto-process). Account information is collected in a RADIUS data base that contains the IP address and MSISDN.

3. The user connects to Liberty SP and requests 15 authentications. This is done by logging into the system using the relevant authentication method. In this example, authentication information is available from the GPRS system.

4. The user is redirected to IdP by AuthnRequest defined by Liberty 20 ID-FF. The passive flag is set to true to indicate to the IdP that the user dialog is not allowed in the authentication process. AuthContextClassRef is created to track the authentication process in different elements.

5. IdP identifies AuthRequest and based on the rules of the authentication plugin, it requests the main synauthentication information from the GPRS authentication module. o This decision can be made if, for example, the passive sex is set to 30 in AuthnRequest transmitted by TRUE SP.

i cd 6. The GPRS authentication module receives the x incoming request and re-identifies them with a specific IP address and resolves o? user identity by querying it on the RADIUS

LO

35 user database, o o 7. User identity (MSISDN) is restored

IdPs and collateral are created.

8. The user is redirected to the SP using SAMLart.

9. In some cases, an alternative method step is for the SP to request security from IdP in 5 SAMLart.

The inventive part of this chain of events is to define a separate module responsible for obtaining information from access level authentication on the Liberty layer. This module (in this example, the GPRS Authentication 10 module) combines IdP and background access authentication systems.

In Figure 4, the arrangement differs from the previous example in the authentication method. The following text numbering refers to arrows 15 in Figure 4 that represent the data stream.

1. The user requests access to the service provider SP, in this case the network access method is irrelevant.

2. The user is redirected to ldP by defining 20 Liberty ID-FFs with AuthRequest. User authentication is allowed in this authentication process. AuthContextClassRef is created to follow the authentication procedure on different elements.

3. IdP recognizes AuthnRequest and based on the rules of the 25 authentication plugin, it requests access authentication data from the disposable password authentication module. An example of disposable password authentication is the TUPAS authentication method used by the Finnish banking sector.

(M

V 30 4. Disposable Password Authentication Module to,> - directs authentication to a separate ATM | service.

^ 5. The Bank Authorization Service Authorization Alert information is returned to the 35 disposable password authentication module.

o

CVJ

11 6. IdP receives information from the disposable password authentication module

AuthContextClassRef: s.

7. The user identity is returned to IdP 5 and a security is created.

8. The user is redirected to the SP via SAMLart.

The difference between the invention and the prior art is further explained in Figures 5 and 6, where Fig. 5-10 shows a prior art disposable password method. Here, signaling is illustrated between three elements, the primary terminal, the service provider, and the identity provider.

In step 1, the primary terminal selects 15 IdP authentication. Your service provider will redirect you. session IdP login URL, step 1.1. The primary terminal makes an authentication request to the identity provider because there is no single sign-on session, step 2. The user au-20 is authenticated in step 2.1 and the identity security is created in step 2.2. From the identity provider, the HTTP session is redirected to the service provider via SAMLart, step 2.3.

In step 3, the primary terminal logs on to 25 service providers via SAMLart. The service provider performs a SOAP security query with SAMLart from the identity provider, step 3.1, and the security is returned in step 3.1.1. Now, the primary terminal is identified and the service provider displays a welcome message.

The method of the present invention is illustrated in Figure 6. The difference with prior art is highlighted by adding an inventive element, an authenticating module, to the signaling diagram. Step 1 corresponds to step 35 step 2 in the previous example, where the primary t '· § terminal selects the authentication request identity.

OJ

tarloajalie. In Step 1.1. identity provider and obtain 12 the requested AuthenticationContextClass and set the passive flag to a state not to indicate that authentication has been done in an interactive manner. The Identity Provider maps the relevant AuthenticationContextClass to the corresponding authentication module; step 1.2; and redirects to the HTTP session authentication module, step 1.3.

The primary terminal connects to the interaction pages presented by the Authentication module, step 2. 10 In the scenario of a one-time password provided by the banks, the desired bank authentication method can be selected here. In steps 2.1 and 2.2, the user is authenticated by a back-end authentication system, such as said disposable password system. The authentication-15 timing module artifact is created from the authentication module and sent to the identity provider with an HTTP redirect (302) message, step 2.3. For example, this artifact can be transported inside an AuthenticationContextClassRef message.

In step 3, the primary terminal requests authentication from the identity provider with the authentication module artifact. The identity provider requests an identity guarantee from the authentication module; Step 3.1; and creates a security in response to your inquiry. In step 25 3.3, the primary terminal is redirected to the service provider via an HTTP redirect (302) message using SAMLartra.

Fig. 7 differs from Fig. 6 in that the authentication tag is created in a passive manner, the user seeing less authentication views than in the previous example. The primary terminal requests the xx from the identity provider, step 1. In step cc 1.1, the identity provider obtains the requested LO ...

cd from the AuthenticationContextClass authentication module

LO

^ 35 and the passive flag is set to false. In step 1.2, AuthenticationContextClass is mapped to the Authentication Module. The identity provider requests authentication using the primary terminal IP address from the authentication module, step 1.3. The Authentication module authenticates the user by using the background authentication system, step 1.3.1. After this authentication, the identity provider is ready to create a security, step 1.4. The session is now transferred to the service provider via an HTTP redirect (302) message using SAMLart.

The above-mentioned tools are known per se, such as software components, and are therefore not described in further detail. The invention is not limited to the above embodiments, but may be modified in various ways without departing from the inventive idea defined in the claims.

15 o δ

CM

CM

C/O

X

cc

CL

LO

o

LO

o h- o o

CM

Claims (10)

A method of administering user identity in a telecommunication system comprising: a main terminal (PT); an authentication system (ABI, ..., AB5); an identity provider server (IdP); a service provider (SP) who is a member of a trust circle; Wherein said method comprises the following steps: a) providing said main terminal (PT) network access through a connection-connected system; B) authenticating and authorizing said main terminal (PT) in the authentication system (ABI, ..., AB5); c) the said main terminal (PT) requests access to the service provider (SP); D) redirecting the connection of the main business terminal (PT) to said identity provider server (IdP); e) the identity provider server (IdP) asks the authentication system (ABI, ..., AB5) for a user identity; f) the user identity is returned to the Identity Provider Server (IdP) and an identity confirmation is formed, characterized in that the method comprises the following steps: 5 "30 g) redirecting the request from step e) to a connection-connected authentication module which is £ associated with the authentication system (ABI, ..., AB5); ir) h) The authentication module investigates the user's 05 g identity in response to the connection-related information.: CVJ 1 19 A method according to claim 1, characterized by step e) with the following steps of the identity provider server (IdP): an authentication request from the service provider (SP) is acknowledged; and you are requesting food authentication data from the connection-connected authentication module. Method according to claim 1, characterized in that the main terminal (PT) is authenticated by the RADIUS system. 4. A method according to claim 1, characterized by gathering billing information associated with the main terminal (PT) in the RADIUS data base. Method according to any of claims 1-4, characterized by step f) with the following step: the connection-linked authentication module receives the request from the identity provider server (IdP); and one finds the identity of the main terminal (PT) having the specified IP address by querying the RADIUS server database. A telecommunications system for administering user identity, comprising: c3 a main terminal (PT); i £! An authenticating and authorizing system (ABI, ..., AB5) comprising means for authenticating and authorizing said principal terminal (PT) and for providing the user identity to LO g an identity provider server (IdP); An identity provider server (IdP) comprising means for querying the authentication system (ABI, ..., AB5) for a user identity and for forming an identity confirmation; a service provider (SP) that is a member of a trust circle and comprises: 5 means for processing an access request from said principal terminal (PT); and means for redirecting the connection of the main terminal (PT) to said identity provider server (IdP); A connection-connected system comprising means for granting network access to said main terminal (PT); characterized in that the system comprises: a connection-linked authentication module 15 associated with the authentication system (ABI, ..., AB5) having: means for receiving a request from the identity provider server (IdP); and means for investigating the identity of the user in response to the connection-related information. System according to claim 6, characterized in that the identity provider server (IdP) has: means for recognizing an authentication request from the service provider (SP); and means for requesting food authentication data ° from the connection-related authentication module. o Ovi System according to claim 6, characterized in that the authentication system (ABI, ..., AB5) comprises x means for authenticating the main terminal (PT) through the RADIUS system. LO CD LO ^ 35 System according to claim 6, characterized by 0 of the authorization system comprising means for gathering billing information associated with the main terminal (PT) in the RADIUS database. System according to any of claims 6-9, 5, characterized in that the connection-linked authentication module comprises means for receiving a request from the identity provider server (IdP) / and means for investigating the identity of the main terminal (PT) having the specified the IP address by querying the RADIUS server database for it. o o CM CM CD X ct Q. LO σ> in o N · o o CM