The process of user identification is called Authentication (AuthN) and in general it is based on one or more of the following approaches:
• Something the user knows — a proper pair of username and password;
• Something the user has — a tool which a user owns (physical, like an USB key or a card, or virtual, like a private key);
• Something the user is — a user has unique characteristics (a fingerprint, the retinal image, etc.);
• Something the user can do — a particular accent, knowledge of a specific language, etc.
While all these methods are actually used for user authentication to a single system, the situation in a distributed environment is more complex due to the fact that the distributed environment is composed from a (large) set of individual components, resources and services. In such a system it is almost impossible to require that a user somehow register oneself to each service before using it. Such an approach would create a very complex situation both for users and service providers. Each user should keep all credentials and should remember which credential belongs to which service. Moreover, each service provider would need to keep user information for each potential user, providing also the appropriate registration and authentication mechanisms.
However, the registration process itself is not sufficient to actually provide the identity of a user. The registration process could identify a returning user — only a person that registered earlier and has been given some unique credentials (a way how he or she could prove being the same person) but the actual physical identity of such a person is still not known. To do so a person must somehow prove its physical identity. This is usually done through some kind of introduction — either by a person who is already known or through some trusted intermediary (e.g., a password issued by a governmental office).
Grids, as the first large scale distributed computing and data infrastructures, addressed this problem by means of Public Key Infrastructures (PKIs). This approach in fact delegated the primary identity proof to an external party — the Certification Authority — that issues a Certificate — proof that a particular public key actually belongs to a particular entity and that such an entity has some confirmed attributes (e.g., name, e-mail address and affiliation). While rather widely deployed, the whole concept has sufficient drawbacks (e.g., need of conversion between different formats, rather weak connection between an entity and its affiliation, rather complicated secure use of the private key) to become a severe barrier for truly wide adoption by different scientific communities. On the other hand PKI is well suited for distributed backend services, where provides high level security with minimal demands on the maintenance.
IIf you want to know more about the Certification Authorities existing in the various countries, click in the interactive map at the top. Counties highlighted in yellow are those where Certification Authorities have been created thanks to CHAIN-REDS activities.
If, instead, you are interested in creating a Certification Authority in your country, training materials about how install and configure a Certification Authority server can be found in this page. If you would like to have additional information, please send an email to email@example.com.