Solutions for Authentication


OpenID is basically a free and worldwide federated identity provider, and as such a widely spread SSO solution among social networks and commercial providers. It is accepted and used by several large organizations (e.g. Google, Facebook, Yahoo!, Microsoft, Novell, Sun), who act as identity providers in this setting. Users can use their existing account from one organization to sign into and access the services of other providers, without the need for creating a new account or password.

It is possible to control which information associated with your OpenID account is shared with the service you are trying to access. This can be done either directly upon requesting access, or through managing your OpenID through a dedicated provider like MyOpenID, VeriSign Labs or other.

“OpenID is rapidly gaining adoption on the web, with over one billion OpenID enabled user accounts and over 50,000 websites accepting OpenID for logins. “ Source: [openid1]

Because of its popularity and ease-of-use, OpenID currently also gains acceptance in the academic world. Some academic organizations and federations, such as Feide, now act as an OpenIdP and offer OpenID accounts. Also, some research infrastructures, such as INESS accept login with OpenID. The research infrastructure project EHRI, because of its diverse nature of contributors, relies heavily on OpenID as IdP, as is illustrated in chapter 3.

References and further reading:


X.509 is a standard for a public key infrastructure (PKI). As such it specifies formats for certificates and how to process them, e.g. for revocation or validation. The X.509 system relies on certification authorities that issue certificates binding a public key to a particular distinguished name.  In most Internet browsers today, a set of predetermined root certificates are pre-installed so that many SSL certificates that the user is presented with can be validated directly.

X.509 certificates provide another way to authenticate users in web-based communication. However, this method has shortcomings, the most significant ones being complexity, lacking responsibility of certificate authorities and several published security vulnerabilities.

References and further reading:


Kerberos is a protocol for mutual authentication, designed primarily for client-server networks. Its main characteristic is the use of a so-called “ticket system” by which users and servers can each verify the respective other’s identity.

Kerberos is widely used throughout the LAN and wide-area networking world and perhaps most notably by MS since Windows 2000. One of its benefits clearly lies in its security, as Kerberos protocol messages are not vulnerable to eavesdropping and replay attacks.

The Kerberos authentication process requires the availability of a central server to issue and verify the so-called Ticket Granting Ticket (TGT). This is used for retaining one initial authentication, and using it to authenticate the user to other servers later on.

Figure 3.3: Kerberos Authentication process

The main drawback of Kerberos is its vulnerability due to the centralized Key Distribution Center (KDC) structure, which can be a single point of failure if not mitigated by using multiple Kerberos servers. More limitations are imposed by the strict time requirements, which make it necessary to synchronize clocks of all servers. For federated services, things are further complicated by the fact that each service provider needs its own set of Kerberos keys.

References and further reading:


CAS stands for the Central Authentication Service, which is an SSO protocol for the web. It also stands for the JASIG project which maintains the CAS protocol, and for a software package that implements it. It can use various authentication methods, such as verification with a Kerberos KDC or an installed X.509 certificate.

In contrast to FIM oriented SSO, a central server (instead of diverse IdPs) is responsible for performing the authentication. A user or other client requesting access to a resource or application is directed by a Service Provider to the CAS, which checks the client’s authenticity, either by validating an entered username and password against a database (e.g. Kerberos or LDAP) or by evaluating a Kerberos Service ticket, or by some other authentication means.

Upon successful authentication, the client is provided with a CAS security ticket which is then used by the Service Provider together with its own service identifier to request ticket validation from the CAS using a secure connection. As with Kerberos, the main argument against using a CAS in complex AAI structures is its single point of failure.

To avoid confusion, it should be noted that the acronym CAS is also being used within the Globus Toolkit (in the meanwhile unsupported versions up to 4.2) for the so-called Community Authentication Service, which allows a Virtual Organization (VO) to express a policy for distributed resources. In the Globus context, a CAS server issues assertions to the VO users to control fine-grained access rights.

References and further reading:

EAP / 802.1X

The Extensible Authentication Protocol (EAP) is a message format specification, and forms the basis of a number of different authentication methods, such as LEAP, EAP-TLS (mutual authentication via X.509-certificates) or EAP-TTLS (secure tunnel with username/password authentication). It is encapsulated by different transmission protocols such as the IEEE standard 802.1X, PEAP or RADIUS. The latter is used e.g. by eduroam (see also chapter 3) and ensures secure communication depending on the employed EAP method type.

References and further reading:


Contact: hosted by NSD - Norwegian Centre for Research Data