Skip to content

The Road to the new CERN Authentication

CERN Authentication White Paper

Emmanuel Ormancey, Hannah Short, Tim Smith, Paolo Tedesco - IT-CDA


As our environment has become increasingly complex, with a wider range of services and infrastructures, the demands on authentication and authorisation services have expanded. The current set of tools is unable to fulfil several core workflows expected by employees and researchers. For example, allowing physicists to access all CERN resources using their home institute credential, or enabling retirees to access pension data using their personal external authentication system. This whitepaper introduces the foreseen path towards a new Authentication system for CERN, to be implemented within the context of the MAlt and Authorization Service Projects.


Until recently, CERN had been considered eligible for academic pricing of Microsoft products. Now, along with many other research institutes, CERN has been disqualified from this educational programme since we do not grant degrees and we now face a 20 fold increase in license costs. Thus an appropriate alternative should be found for all high cost Microsoft components, such as Active Directory (for Kerberos and LDAP) and ADFS (for SSO).

Replacing these core components is an opportunity to rebuild the CERN authentication and authorization infrastructure using the latest technologies and concepts, to respond to the evolving requirements of the community.

Current Landscape: CERN


For the last 20 years, authentication at CERN has been based on Kerberos. Initially this was based on two different providers, Heimdal and Active Directory (Microsoft), but a convergence towards Active Directory in 2008 allowed a unification of services and improved user experience.


The Kerberos protocol was designed in the 80's, where the computing environments were very different from today's.

While Kerberos is well suited to console based core services such as AFS File System and Linux based systems, it is limited to Linux Terminal systems and legacy Microsoft Windows systems running the modified Kerberos protocol provided by Active Directory.

In addition, using Kerberos for authentication requires that a user authenticate locally on a terminal or a desktop with local (to the institute) Kerberos credentials, with no possibility of extentions or add-ons.

Federation isn't possible in Kerberos and so to access core services every associated user of CERN from around the world has to have a CERN account.

Finally, Multifactor integration is challenging as the protocol does not support such an extension.

Alternatives, workarounds

The growing emergence of Web based services triggered the apperance of alternate authentication systems such as SAML2 (used by CERN SSO), OAuth2 and OpenID, which are based on more flexible and portable token systems.

The Batch system, job schedulers and data analysis services often require delayed access to Kerberos based systems such as AFS, and therefore require either authentication delegation or cached credentials to access the resources without user interaction. Golden ticket servers were built to deliver such services, to emulate a simple delegation system. Implementing fine-grained constrained delegation was demonstrated to be too complex to be implemented.

Identity Federation is implemented on the SAML2 (SSO) layer, rather than the core Kerberos, meaning we dont really have Single Sign-On everywhere as different access mechanisms get different capabilities.

The need for Multifactor, not supported in Kerberos, led to building infrastructures using 'bastion hosts', locally protected by non-central Multifactor implementations, that provide access to the other services behind.

Current Landscape: WLCG


To create a worldwide computing infrastructure (WLCG), the HEP community organized itself around circles of trust (EUGridPMA, IGTF), which allowed HEP members to use their local institute credentials to access remote resources. Since the users in these scenarios do not have a local account, the Kerberos protocol could not be used and the community built alternate authentication systems to deliver their services based on on x509 certificates, certificate proxies and VOMS (VO Management Service) attributes.


Although certificates have proved a reliable authentication and authorisation mechanism, they pose a significant learning curve for early-career researchers and many communities are moving towards alternatives; notably SAML federations for Authentication and OAuth2.0 for token based authorisation following the proxy model identified by AARC. One noteable SAML federation gaining traciton is the international federation EduGAIN, but the incompatibility with kerberos remains.

Alternatives: Ongoing Community Initiatives

There are multiple proof of concept projects ongoing. The Indigo Data Cloud's Authentication and Authorisation Infrastructure, IAM, is able to integrate multiple authentication sources (SAML federations, OIDC providers such as ORCID) and generate credentials for downstream services (OIDC, OAuth2). SciTokens has defined a preliminary token format for capability based OAuth2 tokens and shown that HEP job submission is possible. To enable SciTokens, significant effort has been invested in enabling token authorisation throughout the middleware stack, down to storage software such as xrootd. This work can be leveraged by the wider community, including HEP going forwards.

CERN is currently participating in the AARC Project, which is developing best practices for Authentication and Authorisation Infrastructures. Amongst these guidelines are architectural patterns - followed closely by the CERN Authentication plan for Keycloak and the Authorization Service, as well as WLCG.

MAlt for Authentication Services

The Opportunity

In the context of the Authorization Service project, along with the MAlt project, a global redesign of the CERN Authentication infrastructure is in progress, based on new tools and systems.

While the project could aim simply to replace the existing Microsoft based services by similar OpenSource based products, the opportunity should not be missed to revamp the whole authentication system that IT provides. In this way we could close the gap between IT's offer and HEP needs, and align with the WLCG, eliminating the need for the different alternatives mentioned above.

New initiatives are underway to enlarge and increase the use of Federations accross HEP. SciTokens for example is getting a lot of focus lately. Another similar initiative, IOTA CA, was previously evaluated. Both proposals are following the same concept: token translation, from a Web based common token to a specific local token.

Tokens at the heart, not Kerberos

A set of products capable of delivering these authentication functionalities have been identified: - KeyCloak for SAML2, OAuth2, OpenID web based tokens - FreeIPA for the LDAP service - Including a token translation service from token to Kerberos - (Ad-interim) direct Kerberos authentication

Single Sign-On for all

One unique Authentication point for all services

Unification of all authentication systems towards one flexible entry point should allow a better integration of different features and facilitate the roadmap to Federated environments.

Single-Sign-On, based on the KeyCloak product, can deliver many types of tokens: SAML2, OAuth2, OpenID (the latter two as JWT), that can be used directly in applications and systems which natively support them. Being very popular for several years, more and more systems are converging, chiefly on OAuth2 and OIDC (including HTCondor, XRootD via plugins, prototypes for dCache and CVMFS).

By using one unique central Authentication system for all services, that can be widely extended by multiple protocols and translation systems, it will be easy to cover all the current and future needs: - Current and new Federations support - Support for Social Logins (Facebook, Google, etc.) - Support for MultiFactor authentication - Support for one time passwords - Support for any platform and OS (desktops, mobiles, etc.)

Token Conversion Services

Several Token translation services could help to cover the legacy systems which don't support tokens natively. Centralised SSO to Certificate translation for example, as planned in the IOTA CA initiative, could provide SSO to Grid authentication on legacy Grid systems. Alternatively, PAM modules for Linux based terminals could allow consoles to authenticate directly via SSO. A token to SSH keys translation service could also allow 'hops' between terminals or remote commands.

Better and Simpler Authorization

Access to Computing Resources In parallel to improving Authentication services, the Authorization Service project goal is to allow application owners to define authorization schemes in a federated environment, in contrast to the current authorization schemes which requires everyone to hold a CERN computing account.

Users will be able to authenticate with any account (CERN, federated or social) associated to their identity to access the applications. With this scheme it will be possible, for example, to allow retirees and ex-employees to access tax declaration documents, or to allow club members to access club resources, without the need to create a CERN account for them.

Moreover, with such an authorization scheme, ownership of a CERN account will not automatically grant access to most of the CERN resources, as it is the case today.

The same technology stack, based on OAuth2 tokens can be used to rebuild the authorizatioin system for grid computing, including a replacement for VOMS and VOMS-Admin.

WLCG alignment

Future Authentication & Authorisation for WLCG

There is an ongoing WLCG working group for Authorisation focusing on grid authorisation for users. The group consists of many of the key players from IGTF, AARC, e-Infrastructures and experiments, including individuals involved in SciTokens, INDIGO IAM, EGI Checkin. One key objective is to converge on the token schema used within the community to allow interoperability. A second objective is to design a system to enable non-x509 authorisation for all WLCG users.

It is envisaged that this system will be fully integrated with the new CERN Authentication system and manage the grid-specific functionality internally. This separation of functionality is both to avoid special cases in CERN's authentication infrastructure and also to allow the software to be used by WLCG Virtual Organisations (VOs) who may wish to integrate an alternative Authentication source due to having little affiliation with CERN. WLCG services can be recommended by the WLCG management board but each VO has certain liberty to adopt tools as they see fit, developing this service in close collaboration with WLCG stakeholders is essential for successful uptake.

WLCG specific requirements include: * Token translation to the required token type for downstream compute nodes, this includes x509 for legacy systems and OAuth2 for those that support it * Command-line token provisioning * Grid user suspension

Changes ahead

Converging the different authentication systems into a unique point will require changes and upgrades in the services and applications depending on it. - Services that can evolve, will align to token based authentication and widen their user scope. XROOTD, HT Condor, Java and Python based libraries will allow a smooth transition. - Some other services that cannot evolve will have to be replaced.


To provide an intuitive experience to the vast diversity of CERN user categories, it is critical that the authentication and authorisation services evolve. This requires change by both the authentication and authorisation service providers (CDA) and by downstream services, including IT and WLCG. Token based authentication and authorisation has emerged as the clear direction that we should be taking and it is essential that a coordinated effort be made regarding protocols and schemas.