1. Prior Art
The systems of identity management are defined by different standardization organizations such as Liberty Alliance (which proposes the ID-FF or Identity Federation Framework) or OASIS (which defines SAML or Security Assertions Markup Language).
The architectures of these systems are based on the concepts of service providers (SP), identity providers (IdP) and the client:                The client corresponds to any type of entity whatsoever (for example an individual user, a group of users, an organizational entity, a machine, a software application, etc.) that can be identified and authenticated.        The services provider (SP) proposes one or more services that are accessible to the client when it is authenticated. This service may be, for example, an Internet on-line sale site providing products and/or services which cannot be ordered or paid for with the authentication of the client.        The identity provider (IdP) is an entity to which the service providers (SP) may delegate the authentication of a client.        
These systems therefore offer clients SSO or single sign-on functions which enable successive access to different service providers without necessitating a systematic authentication of the client at each access to a new service. Classically, within these authentication architectures, the running of an interaction between a service provider and an identity provider is as follows:    1. The client requests access to a service at the level of the SP (for example access to his user account).    2. The SP then redirects the client to the IdP so that the SP obtains an assertion of authentication from the IdP giving an assurance that the client has been identified.    3. The client is requested to authenticate himself or itself (if he has not already done so during the access to another service) at the IdP level.    4. In the event of success, the IdP redirects the client to the SP. At the same time, it gives the SP an assertion of authentication that contains the information needed to create an authentication session for the client at the level of the SP. The client can then access the requested service.
This operation therefore assures the service provider that the client is correctly identified and authenticated while, at the same time, averting the need for the client to authenticate himself several times. Indeed, when several different service providers make use of a same identity provider, then the client does not need to authenticate himself or itself at each access to these different services.
2. Drawbacks of the Prior Art
A first drawback of this prior art technique is that, during the requests for authentication between the IdP and SP and during the processing operations internal to the IdP, the present-day identity management systems do not enable a distinction to be made between the different types of clients: for example individual users, groups of users (collective users), organizational entities, machines. These different types of clients can be led to coexist in a same IdP.
Another drawback of this prior art technique is that a given system is designed to process only one type of particular client. For example, an IdP would be made responsible for managing physical persons and another IdP for managing the organizational entities.
A corollary of the above drawback is that when a generic system is designed on the basis of an IdP managing different types of identities such as physical persons and organizational entities, then this IdP makes no distinction whatsoever between the different possible types of coexisting clients, and will therefore request an individual user to authenticate himself several times as a function of the identity required during the access to a service.
For example, in the case of a telecommunications operator, the general concept of a client covers:                the individual user on the one hand, which is an individual identity for the identity management system,        his home on the other hand, which is a group of individual identities and a collective identity for the identity management system.        
In this example, the collective identity may be associated with an access, for example a telephone land line and it may be authenticated implicitly (without interaction with the user) by his address on a telecommunications network, contrary to individual authentication which requires interaction (between an identifier and a password for example).
A client therefore has two imbricated identities: an individual identity and a collective identity.
Now, the present-day identity management systems (IdP) cannot make the individual entity and the collective entity coexist and therefore work with the more generic concept of the individual user. A collective SP can in fact manage rights of access to its service only on a basis of individual identities.
Another drawback of this technique therefore is the complexification of the operations for updating information within this SP since, instead of being simply authorized to a collective identity, access is authorized to all the individual identities that form it.
Yet another drawback of this prior art technique is linked to the fact that problems of security then arise, the rights of administrator of the collective identity being then delegated to all the individual entities that form it.
Another drawback resulting from this prior art technique is that it leads to behavior calling for over-authentication whereas even this is not necessary as described in the following example: a user accessing his collective voice messaging service (his family's messaging service, for example the answering machine) is constrained by the IdP to authenticate himself explicitly and individually whereas the SP could have been satisfied with a collective authentication (authentication by the network address of the telephone set).
A last drawback of this prior art technique is that the benefits provided by the single sign-on (SSO) principle are lost: this leads, for example, to a systematic authentication of the user with different profiles depending on the information requested by the service provider.
USPTO Backgrounds
USPTO Backgrounds