MALT Authentication and Authorization: reasons for change
The services provided by the MALT Authentication and Authorization project are evolutions of existing services. While reducing licensing costs was definitely an important consideration, the new services also address limitations of the previous solutions.
Microsoft License Cost Calculations
A Windows Server Client Access License (CAL) is required for every individual authenticating to a windows server (including the login server). To decrease the number of licenses we must
- Decrease the number of windows servers where authentication occurs
- Decrease the number of users accessing those servers
This defines our priorities:
- Migrate CERN services to a new Single-Sign-On SSO (since every authentication with a CERN account to the old SSO requires a license)
- Migrate all users out of Active Directory and on to a new LDAP & Kerberos alternative (FreeIPA has been chosen). Users that require Microsoft services will remain duplicated in Active Directory.
- Use FreeIPA as the source of authentication for the new SSO
- Ensure that only valid windows use cases remain in AD, i.e. windows specific services and their users. A license will be required for each user.
- Old LDAP and Kerberos
- Microsoft Active Directory (AD)
- The foundation to the whole MS domain. No AD replacement, no MALT.
- License required for every person authenticating to a Windows Server enrolled in AD (including the login server)
- Anyone on the CERN network can query any data, including group membership. No longer acceptable under data protection guidelines
- New LDAP and Kerberos
- Open Source Software with active community and support
- Several technical benefits including reduced reliance on DNS for host resolution (mitigates a security risk)
- Opportunity to rethink data protection of group membership
Single Sign-On (SSO) and applications portal
- Old SSO:
- No official support for OIDC (modern authentication protocol)
- Upgrades not possible: no support for CERN customizations
- Alternative were being evaluated even before MALT started
- New SSO:
- Native support for OIDC
- Native support for SAML (backwards compatibility / 3rd party applications)
- Better integration with EduGain federation
- Standard tools supported by the community
- Built-in access restrictions on level of assurance and multifactor
- Solves authentication problems for users member of too many groups
The old CERN SSO is based on Microsoft Active Directory Federation Services (ADFS) 2.1. Many customizations were introduced on top of the out-of-the-box ADFS version to adapt the service to CERN's needs. Such customizations were no longer supported by more recent ADFS versions; at the same time, modern authentication protocols, such as OIDC, were not properly (and officially) supported by ADFS 2.1.
The new CERN SSO, based on Keycloak, provides native support for the OIDC protocol. The SAML protocol is also supported for backwards compatibility and third party applications.
Even before the MALT initiative started, alternatives to ADFS were being evaluated.
Another advantage offered by the new SSO is that with it support for the Edugain federation can be based on tools maintained by the Edugain community itself (pyFF and SATOSA). The previous solution was relying on a home made implementation, which required frequent updates without the possibility to rely on any community support.
The new application portal allows to register applications to use the new SSO and configure their permission schemes using roles which are directly provided by SSO in the authentication token. This allows to restrict permissions according to the level of assurance of the authentication provider (an indication of how reliable the source of identity information is) and multifactor authentication (for access rights requiring higher security). This also addresses a problem with the old SSO, where authorization was based directly on groups, which did not allow users who are member of too many groups to authenticate.
Groups portal and API
- Egroups (FAP-BC) not actively maintained
- Custom synchronization tool to LDAP
- Applications rely on LDAP for read access (all information is public)
- Privacy (membership visibility) not enforced
- Mail and authorization (LDAP) strictly tied
- New groups portal and API
- Standard LDAP synchronization
- Provides controlled read access
- Will enforce privacy enforced (with restrictions)
- Mail and authorization can be decoupled
User groups are the foundation of all the authorization schemes defined for CERN applications.
Groups are maintained through the Egroups application, developed by FAP-BC.
A custom tool is synchronizing data from egroups to LDAP (Active Directory). Due to the high number of groups, and because all groups are also used as mailing lists, the performance of this synchronization tool has deteriorated over time, to the point that it can take several hours for a change in Egroups to be propagated to LDAP. The new groups service will use a standard synchronization tool to propagate data to FreeIPA (the next LDAP service at CERN), reducing the maintenance effort for the whole infrastructure. Such tool will be based on Microsoft Identity Manager (MIM) in a first time, to reduce the initial development effort. At a later point, a solution not relying on Microsoft software could be developed. It is worth noting, however, that the current configuration requires a single server license, as it only uses a subset of the MIM components. Furthermore, the new service decouples authorization and mailing usage. Among other things, this will offer the advantage that the mailing list service will not slow down the performance of LDAP synchronization.
Synchronization issues are even more relevant if we consider that egroups does not provide a complete API for reading groups information, and that in practice all current applications are relying on LDAP to read group memberships. The new API provides a full and controlled way to read groups information, so that applications will not need to rely on LDAP, which is the most low-level solution possible, to read such information.
Such extensive use of LDAP, and the tight coupling with the mailing functionalities, also poses another problem, related to privacy. Since all groups are publicly readable in LDAP (to any CERN authenticated user), egroups membership visibility restrictions are, in practice, not enforced. The new API will enforce such restrictions, by forbidding closed membership groups to be exported to LDAP. Such groups will still be usable as mailing lists.
Users portal and account management
- Significant cost reduction in MIM licenses
- Single server license vs. a license per user
- Modern integation with 3rd party providers
- Users can login with Edugain, Linkedin, Google etc.
- "Lightweight" accounts no longer required (but still supported)
The new service will improve the account management functionalities currently provided by the old account service. The new setup will greatly decrease the licensing costs, as it uses a reduced set of functionalities from Microsoft Identity Manager: a single server license will be required, instead of a license for each CERN user. The new service allows users to associate alternative (non-CERN) autentication methods to their CERN account, such as federated EduGain accounts or accounts from social providers (Linkedin, Google etc). Thanks to this, it will no longer be required for users to create a specific account to access CERN facilities after their departure. Ex-CERN members will be able to access the Alumni network (or their tax certificates) authenticating with the provider of their choice, in line with modern autentication trends. Support for mail and password logins will still be maintained.
- More flexible lifecycles (based on roles)
- Resources can be assigned to non-CERN users (with a lifecycle)
Thanks to the new identity and roles model, which are basically abstractions over accounts and groups, it will be possible to define life cycles for computing resources that are not necessarily tied to an affiliation with CERN. Resource managers will be able to define more flexible policies and apply them to non-CERN users as well. For example, it will be possible to enforce a rule that reassigns or expires computing resources when a user is no longer member of a certain group (mapped to an appropriate role).