WO2007074284A2

WO2007074284A2 - Method for forming a user profile in an information system and a system for managing digital identities

Info

Publication number: WO2007074284A2
Application number: PCT/FR2006/051379
Authority: WO
Inventors: Yahia Merchaoui
Original assignee: France Telecom
Priority date: 2005-12-22
Filing date: 2006-12-19
Publication date: 2007-07-05
Also published as: WO2007074284A3

Abstract

The invention relates to a method for forming a user profile in an information system and to a system for managing digital identities. The inventive method consists in assigning attributes (31) to each role (32) defined in the information system, wherein at least one role is assigned to a user, and in obtaining a profile by assembling (34) the attributes associated to the user's role. The attributes (31) assigned to the roles can have default values. The profile attributes receive the default values when they are devoid of a specific value. The invention is particularly suitable for the identity and access control management used in information systems.

Description

Method for creating a user profile in an information system and digital identity management system

The present invention relates to a method of creating a user profile in an information system. It also relates to a digital identity management system. It applies in particular for the management of identity and access control in information systems.

The need for reliable identification of entities using information systems increases considerably due to the ever-increasing number of electronic transactions, covering for example both the security requirements for access to a business service and the security requirements. remote transactions, such as online payment for example. Identity management and access to information systems is therefore a central issue in the development of electronic transactions on networks, both in terms of performance and costs. A digital identity is typically composed of attributes describing an entity in a digital space and allowing it to interact with applications on a network according to its particular needs. The entity can be for example a user, a group of users, an organization, a program or a machine. An entity must be able to be identified and authenticated. The management of an identity is thus a set of business processes and technologies allowing on the one hand the management of the life cycle of a digital identity and on the other hand the fulfillment of relations between this identity and the applications and the services concerned. Identity management is closely related to the information contained in the attributes of the user profile. The user profile is persistent information that is saved in user repositories, directories of the LDAP type or databases for example. A user profile is a set of attributes that characterizes an account and whose values are associated with the user of the account and materialize the user's digital identity. An account is an identifier materializing the digital representation of the user for some or all of the applications of an information system. It is possible to group all the attributes forming the user profile into two subgroups. A first subgroup has common attributes, such as name, first name, or birth date, for example. These common attributes can be used in all applications. A second subgroup contains attributes that only make sense for certain applications and therefore are only used for users who are allowed to access them.

Known techniques directly relate the attributes of the user profile to the account in a more or less rigid manner. These techniques have disadvantages. In particular, if you want multiple applications in an information system, for example, to use the same user repository centrally with the same identity manager, you have to model a comprehensive user profile from the beginning. containing all of the attributes necessary for all applications. This implies that all users have the same user profile, that is, the same attributes. A user therefore has all the attributes in his user profile even if some only relate to applications that this user does not necessarily have the right to access. It is therefore necessary to reserve space for all these attributes, even if these attributes are not specified. This results in a waste of repository storage space. Known solutions attempt to circumvent this disadvantage by storing the identity attributes of a single application in databases located on the application side. These solutions themselves have other disadvantages such as the fragmentation of the digital identity on several repositories and the difficulty of sharing attributes which only concerns a few applications nevertheless requiring the implementation of attribute sharing protocols.

Another disadvantage of the known techniques concerns their rigidity with respect to the different evolutions. In particular, the identity manager must evolve to follow the needs of all the applications that use it or to follow the needs of the same application, including the attributes of the identity that the application needs. It is also necessary to follow the role that a user occupies in the organization of applications and that allows him to access different applications over time. To meet these requirements, known techniques modify the structure of the repository database with heavy procedures for importing identities between the different formats of the user profile, which almost always implies a break in service.

All these drawbacks result in technical problems in the hardware supporting the information system, particularly with regard to the storage space and / or storage, memory access times or the difficulty of maintenance for example.

The invention aims to overcome the aforementioned drawbacks. For this purpose, the subject of the invention is a method of creating at least one user profile in an information system, the profile comprising a set of attributes characterizing the digital identity of at least one user. Attributes being associated with roles defined in the information system, and at least one of said roles being assigned to said user, the profile is obtained by assembling and storing the attributes associated with the roles assigned to said user. This allows a flexibility of evolution of a user profile. The invention makes it possible to add attributes of the user profile without interruptions in the availability of the database where the profiles are stored. Advantageously, the attributes associated with the roles have default values. The attributes of the user profile then take these default values when they do not have a specified value.

This allows you to add user profiles quickly and prefabricated. The user profile can be completed by a profile of access to at least one resource. At least one role is associated with permission to access the resource. Users authorized to access said resource of the information system are then identified by the roles assigned to them.

The invention also relates to a system for managing the digital identity of at least one user in an information system. This system comprises at least:

- a digital identity management module;

a module describing at least one user profile, the identity management being performed as a function of data of said profile, comprising a set of attributes characterizing the digital identity of said user, said module comprising at least: an entity describing the attributes associated with roles defined in said information system;

an entity listing the roles assigned to the user.

A user profile is then obtained by assembling the attributes associated with the roles assigned to the user.

The digital identity management module can further control access to at least one resource. In this case, the module describing the user profiles also includes:

an entity describing the resources defined for the system; a table listing the set of permissions defined for the roles on said resource; the users authorized to access an information system resource being identified by the roles assigned to them.

The main advantages of the invention are that it makes it possible to obtain flexibility in the evolution of a user profile, that it allows the suppression of redundant or superfluous storage of attributes, that it allows a gain in memory space and in memory access time, it allows to change the number of attributes of a profile without changing the structure of the system, particularly involving maintenance savings.

Other characteristics and advantages of the invention will become apparent with the aid of the following description made with reference to appended drawings which represent:

- Figure 1, the main blocks of an identity management system and access controls;

FIGS. 2a and 2b, repository representations for storing user data, according to the prior art;

FIG. 3, a model illustrating the creation of a user profile according to the invention, in particular for the management of identities; FIGS. 4a and 4b, models illustrating the creation of authorization profiles for the management of an access control;

FIG. 5, a model grouping the models of FIGS. 3 and 4b for identity management and access control according to the invention;

FIG. 6, the system of FIG. 1 showing the user reference systems used; FIGS. 7a and 7b, exemplary models of an account repository and a user repository;

FIG. 8, an example of a repository model for access management; FIG. 9, an exemplary model for the user profile according to the prior art;

FIG. 10, an exemplary model for the creation of a user profile according to the invention;

FIG. 11, an example of a reference system according to that of FIG. 6, produced according to the invention;

FIG. 12, an exemplary application of identity management and access control according to the invention.

Figure 1 presents in a simplified diagram the main blocks of an identity management system and access control. This system has functional blocks that come into play when using a protected resource 1 in an information system. The figure also shows the links that govern the interactions between these blocks. The identity management system and access control includes an authentication module 20 and rights management, called access control module thereafter. The system also includes a user repository module 30, storing user data. In the example of FIG. 1, a user 2 wants to access the resource 1 via an authentication client station 3. The latter interacts with the access control module 20 according to a known authentication protocol. The control module 20 performs the authentication of the user 2 and authorizes or not its access to the resource 1 according to the data relating to this user which are stored in the user repository 30. An administration module 4 allows a user administrator 5 to update the repository. In particular, it registers new users with their attributes or modifies the attributes of other users throughout the system's operating life.

By way of example, FIG. 2a illustrates a view of a table 29 for storing the user accounts, in particular in a repository 30 of the type of that of the figure 1. This table describes how the system's memory space is used. Other representations are of course possible to describe this memory space. Table 29 has one line per user account. The data in the user account is divided into columns. A first column indicates the identifier 21 of the account, it is an internal identifier to the system coded for example in alphanumeric format. The following columns indicate attributes such as the external identifier subsequently called login, the password, the first name, the name and the date of birth of the user. Applications store this data in the memory space. They are also transmitted between different applications, especially for authentication or control purposes. For ease of description, Figure 2b illustrates all of these data in the form of an object model. FIG. 2b thus shows a software view of the object conveying the identity corresponding to the user account line of FIG. 2a. In addition to its identifier 21 in the alpha-numeric format, the account includes attributes 22 specific to the authentication of the user such as the login and the password, then the attributes of the user profile 23. The user profile comprises typically two types of attributes, common attributes 24 and attributes specific to certain applications. The common attributes, usable in all applications, are, for example, the user's last name, first name and date of birth. The other attributes only make sense for certain applications and are therefore only used for users who can access them. Specific attributes are for example a type of credit card and a credit card number. As indicated above, a solution of the prior art is to model from the beginning a user profile containing the set of all the attributes necessary for all applications. In the example of Figure 2a, the account of a user not using a credit card would nevertheless have the corresponding attributes, the latter occupying a useless memory space without any particular value attributed.

Beyond this simple example, it appears that the management of the identity is linked to the information contained in the attributes of the user profile 23. The model of FIG. 2b established according to the prior art focuses on an entity that characterizes the user. a rigid way the attributes of the user profile, as That column of the table 29. However, a large number of attributes of the user profile only make sense for certain applications and therefore only make sense in the profile of the users authorized to access them. In addition, the number of user profile attributes required by applications evolves over time. Finally the model of the user profile must follow the needs of the applications and to accompany their functional evolutions over time. Storage as illustrated in Figure 2 does not meet these requirements.

FIG. 3 illustrates a method for creating a user profile according to the invention, in particular for identity management, by an object representation of UML (Unified Modeling Language) type. In this model the account and attributes of the user profile are no longer directly associated with a rigid link. This model makes the attributes of a user's profile dependent on that user's roles in an information system. In other words, the attributes of the user profile can correspond to the applications accessed by a user through the different roles that he occupies in relation to his organization, these roles giving him access or not to this or that application. Roles are sets of rights assigned to entities. They are typically used in such a way that they model a function or business that an entity, such as a user, would occupy in the organization managed by the information system. This model for creating a user profile implies that it consists of parts of profiles 31 each due to a particular role 32 assigned to the account 33 of the user. All the accounts 33 of the information system can each be assigned one or more roles among all the available roles 32, ie all the accounts 33 can be related to all the roles 32. however, a profile portion 31 is only related to one role. These properties are summarized by the cardinalities of the different objects 31, 32, 33 in the sense of the UML modeling language. Cardinality describes how many different objects can be linked by an association 34, 35 to an object. Thus the cardinality of the accounts and the roles in relation is of the type 0 ... n. The cardinality of a part of profile to a role is equal to 1. Advantageously, a default value is for example assigned to each attribute associated with a role. Thus, when assigning a role to an account, the system is able to present the default values for each of the attributes used even before the user profile is initialized. Similarly, a default role can be assigned to a user, the attributes associated with this role being for example those that are common to all applications. The model of Figure 3 for identity management can be advantageously associated with an access management model.

Figures 4a and 4b show model representations for access management. These are security models that make the access rights to resources 41 dependent on the roles 32 assigned to the accounts 33. More generally, these models facilitate the administrative management of access management problems in an information system by organizational model of users the model of access to resources. That is, the users authorized to access an application are identified by the roles assigned to them. Access is determined by permissions 42, a permission being a privilege of access to a resource. FIG. 4a shows a model where a permission 42 can only be defined by the definition of the association between the resource 41 and the role 32.

Figure 4b shows a model or permission 42 is defined only by the resource 41 that it characterizes by association 43. The cardinalities of roles and permissions in their association 44 are of type 0, ... n. It is the same for the cardinalities of the accounts and the roles in their association.

Other models allowing access by access lists directly to the resources are possible. The models of FIGS. 4a and 4b nevertheless provide ease and flexibility of management.

Figure 5 illustrates an integrated data model combining the models of Figures 3 and 4a or 4b. More specifically, this model integrates a model 51 for identity management such as that of FIG. 3 and a model 52 for access management of the type for example that of FIG. 4b. A user profile portion 31 is thus associated with a role 32, which is associated with resources 41. The associations between the role and the resources are each characterized by a permission 42. The model of Figure 5 thus allows the management of the identity and management of access control. This integration takes place by matching, in a centralized manner, the accounts 33 and the roles 32 in the sense of the identity management model 51 or in the sense of the access control management model 52. This means an account and the associated role has the same meaning for identity management and access management. The model of Figure 5 can be implemented in a user repository.

Figure 6 shows the system of Figure 1 for the management of identities and access controls. The repository 30 is detailed there, it forms a system for storing user repositories including for example four storage systems:

- an account repository 1 1, where are listed the accounts of users;

an authentication repository 12 where the data relating to the secrets for authenticating the users of an account are stored;

an access management and authorization repository 13, where data relating to the access rights to the resources for given accounts are stored;

a repository of the user profiles 14, where the data of the user profiles characterizing the identity of the users are stored.

The set of repositories thus composes the user repository 30, which can be designed with databases or with directories, of the LDAP type, for example. These repositories are described later by data models that describe the functional links, the storage modes and the access modes in the memory spaces.

Figures 7a and 7b show examples of data models, respectively for the account repository and for the authentication repository. These models have the structure of a table. Figure 7a shows entities involved for the account repository. The account repository is for example composed of an entity 70, which is declined into a table, listing the identifiers 21 internal to the system for each account as well as a state of activity 71 and a description. This description is a free field that can indicate in particular the order of entry in the account's database. The value of an identifier 21 must uniquely identify the registration of the table forming what is known as a primary key PK. A primary key is a field or set of fields that uniquely identifies a record in a table, in this case an account. Figure 7b shows entities involved for the authentication repository. The authentication repository is for example composed of an entity 80 giving the login 72 for each account and other data 73, including the associated authentication secret consisting for example of a password. The login 72 occupies a PK primary key. The other data is identified by a foreign key FK1 that points to primary keys in the other tables. This foreign key FK1 is a correlation key which contributes, for example, to identifying a line by linking it to a column of another table. It is the link between the authentication repository table and tables of other repositories. In the example of FIG. 7b, the field addressed by the foreign key FK1 points to the address of the identifier 21 of the user account. In general, a foreign key addresses a field or a set of fields in a table representing a relationship between it and the primary key of another table.

It should be noted that if the system is intended to allow only one login per account, it is natural to merge the two entities 70, 80 in the same table to the implementation as is the case in the example of the table of Figure 2a. This table includes the accounts repository and the authentication repository.

Figure 8 shows a data model of the Access Management repository. It presents the entities implementing the model of FIG. 4b in particular relation with this reference frame. These entities are for example the following tables:

a table 81 describing the roles defined for the system, where the description of each registered role is associated with the identifier of the role, this entity forms the repository of the roles; a table 82 describing the resources defined for the system, where the description of each registered resource is associated with the identifier of the resource;

a table 83 listing the set of permissions defined for each role on each resource;

a table 84 listing all the roles 86 associated with each account 85 of the entity of the account repository.

The table 83 thus comprises resource-role pairs each associated with a permission realizing the associations 43, 44 of the model of FIG. 4b. The resource and role identifiers are addressed by foreign keys FK1, FK2 which point to the primary keys of the tables 81, 82 describing roles and resources.

In the entity 84 the account identifiers and the role identifiers are identified by foreign keys FK1, FK2 which point one in the accounts repository and the other in the system roles repository 81. The couples records account identifiers and role identifiers describe the set of associations 45 of the model 4b for example. Each record is marked with an index.

Figure 9 recalls a user profile model according to the prior art. This model is implemented by a table 91 which can be associated with the other tables of the other repositories 1 1, 12, 13. The account identifier in the table 91 points the repository of the user accounts to make the link between this account and attributes. It has been indicated previously that the attributes 92 of the user profile are rigidly related to the user account. Thus, for a user identified in this table 91, if one wants to centralize the storage of the attributes of the profile, one must model a profile where all the attributes that concern all the applications that use the system manager subsist. In addition, if we want to change the number of attributes of the user profile that an application would use, we must change the data model of the user profile, which implies an interruption of service.

FIG. 10 shows the entities involved for the repository of the user profiles created by the method according to the invention. It illustrates, in particular, an example of the implementation of the model illustrated in FIG. components of the user profile repository are, for example, the following tables:

a table 81 describing the roles defined for the system, for example of the type of that of FIG. 8 used for the repository of access management;

a table 101 describing the attributes of the profiles defined for each role, the attributes having a default value;

a table 84 listing all the roles associated with each account of the account repository, of the type of that of FIG. 8; a table 102 listing the set of attributes specified, in the defined or initialized direction, for a given user.

This last table 102 indicates for each user account the set of attributes specified with their value for this account. These attribute values can be specified when the system is initialized or running. They are defined. The attributes that have no meaning for this account, with regard to the applications envisaged, or whose value can not be defined, are not indicated in this table 102. In terms of its structure, this is reflected in particular for each account, by an association of the identifiers of the account 21 with the values of its specified attributes. Table 101 describing the attributes indicates the list of attributes associated with each role. These associations are modeled in Figure 3 by the relationship between attributes and roles. In this table 101, the attributes of the lists have a default value 103. The choice of a default value can be arbitrary but preferably it is chosen to optimize the storage of the data. It can thus be chosen according to a statistical relevance. To illustrate such a choice, we can consider as an example of an attribute a mailing address of a company which has a main establishment and some subsidiary offices. By default, all "address" attributes would have the address of the primary institution, giving employees that default address in table 101.

In the table 84, listing the set of roles associated with each account of the account repository, the account identifiers and the identifiers of the roles are identified by foreign keys FK1, FK2 which point for example one the repository accounts and the other table 81 describing the roles of the system. ID couples recordings Accounts and Role IDs describe all role-account associations of the information system, that is, all roles occupied by all users. They are modeled in Figure 3 by the relationship 34 between accounts and roles. Each record is marked with an index. For a given user, the recomposition of his user profile can then be carried out according to the following steps:

- recover the identifier of his account by the tables of accounts and authentication, from the login for example;

recovering the profile attributes specified for the account identifier using the corresponding association table 102;

recover all the roles accumulated by the user, that is to say all the roles associated with the identifier using the corresponding association table 84;

for each role, collect all attributes associated with their default values using table 101 describing the attributes associated with the roles;

- For each attribute collected in this previous step, the attribute takes the value specified in the table 102 of the second step if this value exists in this table, otherwise the attribute takes the default value indicated in the table 101 describing the attributes associated with roles.

The set of attribute values thus defined forms the profile of the user. This profile is obtained from the attribute values specified for this user and common default values that depend on the user's roles. For each user, it is no longer necessary to store all the attributes. In particular, we can consider as an example a case where certain attributes of the user profile carry the same value over a non-negligible portion of the population of registered users. By the modeling flexibility that it implies, the invention makes it possible to set only one default value for all these users and for a given role, at the level of the table 101 associating the attributes with the role. In a model according to the prior art, the profiles of all users should store the value of these attributes, resulting in a waste of storage space. Table 81 describing the roles defined for the system, actually forming the role repository, does not intervene directly in the process of recomposition as described above. In fact, reference is made to this table 81 for the definition of roles at initialization and then during system operation to take into account, for example, new users or users who change roles or to add new roles. required for the evolutions of the applications of the information system.

FIG. 11 presents a repository structure that integrates the tables of FIGS. 8 and 10 implementing the model of FIG. 5. These tables are supplemented by the account repository 70 and the authentication repository 80 to form a set of repositories as shown in Figure 6 and used in an identity management system and access control. In this embodiment, access management repositories and user profiles are nested. The repository of the user profiles is composed of the set 1 10 of the tables of FIG. 10. The repository of the access management is composed of the set 11 of the tables of FIG. 8. The table 81 forming the repository of the Roles and the account role association table 84 are common to both sets 110, 11. The tables 80, 84, 102 that include the account identifiers point to the account repository 70.

Figure 6 shows an identity management and access control system. It is nevertheless possible to produce a system according to the invention which comprises only a system for managing the digital identity of the users. In this case the access control module 20 for example simply performs the identity management function. Similarly, the module 30 of the repositories may not include the profile portion corresponding to the access control to applications or resources. Identity management is performed based on the data available in the repository. The invention advantageously allows to obtain a flexibility of evolution of a user profile. It allows the suppression of redundant or superfluous storage of attributes and thus a gain in memory space and memory access time. It also makes it possible to change the number of attributes of a profile without changing the structure of the system, which implies maintenance savings. Figure 12 illustrates an example of application of the invention. Jérôme Dupont is the administrator manager of the Intranet of a given organization. The managers of this organization have the privilege of having a reserved parking space. When Jérôme Dupont accesses the Internet portal of his company, he uses an account 33 whose login is "jdupont". This account is associated with three roles 32 that are:

- a standard role "Default", which is role by default;

- a role "Admin Portal. What is the role of Intranet system administrators? - a "Manager" role, which is the role of manager in this organization. By the role "Default":

the user profile 31 contains the attributes common to all the collaborators of the organization, for example the surname, the first name, the date of birth ..., the "Default" role being associated with these common attributes;

- The profile defined by the access repository gains permissions to access the Intranet of the organization, under the control of a permission 42 giving access to the resource 41: the Intranet application.

By the role "Admin. »:

- the user profile is not enriched with any attribute, the role "Admin Portal. "Not related to any attribute;

the access profile gains the permissions enabling access to the administration application 41 to manage in particular the accounts of the other collaborators. By the role "Manager":

- The user profile 31 is added an attribute whose name is "ParkingNumber" and whose value is, for example, 32; the access profile gains the permissions to access the electronic document management application which contains, for example, sensitive data.

Claims

1. A method of creating at least one user profile in an information system, the profile comprising a set of attributes characterizing the digital identity of at least one user (2), characterized in that, attributes being associated with roles (32) defined in the information system, and at least one of said roles being assigned to said user, the profile is obtained by assembling (34) and storing the attributes associated with the roles assigned to said user (2).

2. Method according to claim 1, characterized in that the attributes associated with the roles (32) having default values, the attributes of said profile take these default values when they have no specified value.

3. Method according to any one of the preceding claims, characterized in that a default role is assigned to said user (2), the attributes common to all users being associated with this role by default.

4. Method according to any one of the preceding claims, characterized in that the digital identity of the user (2) being associated with an account (33), the method comprises for said account (33):

a step of recovering the attributes having a value specified for the account (33);

a step of recovering the roles (32) associated with this account (33);

a step of collecting the attributes associated with these roles (32) with their default values; the user profile is obtained by taking for each attribute its default value if it is not specified, the specified value being kept in the other cases.

5. Method according to any one of the preceding claims, characterized in that it completes the user profile by an access profile to at least one resource (1), at least one role (32) being associated with a permission ( 42) allowing access to said resource (1), the users authorized to access said resource (1) of the information system being identified by the roles assigned to them.

6. System for managing the digital identity of at least one user (2) in an information system, characterized in that it comprises at least:

a digital identity management module (20);

a module (30) describing at least one user profile, the identity management being carried out as a function of data of said profile, said profile comprising a set of attributes characterizing the digital identity of said user (2), said module (30); ) comprising at least: an entity (101) describing attributes associated with roles (32) defined in said information system; an entity (84) listing the roles (32) assigned to the user (2);

a user profile being obtained by assembling (34) attributes associated with the roles assigned to the user (2).

7. System according to claim 6, characterized in that the module (30) describing said user profile comprises an entity (102) listing the set of attributes specified for the users, the attributes associated with the roles having default values, and the attributes of said obtained profile take these default values when they do not have a specified value.

8. System according to any one of claims 6 or 7, characterized in that the digital identity management module (20) further performs access control to at least one resource (1), the module (30) ) describing user profiles that include:

an entity (82) describing the resources defined for the system;

a table (83) listing the set of permissions defined for the roles on said resource (1); the users authorized to access a resource (1) of the information system being identified by the roles assigned to them.

A computer program comprising program code instructions for executing the method according to claims 1 - 5 when said program is run on a computer.

A computer readable recording medium on which a computer program is recorded including program code instructions for executing the method according to claims 1 - 5.