Francesco Donini co-authored this blog.
This post summarizes our experiences securing the Registration Data Access Protocol (RDAP) service of ccTLD .it by integrating with OpenID Connect (OIDC). Integration is achieved by using one of the most well-known open-source identity and access managers: Keycloak. Access to the RDAP server by human users is provided through a web client or a browser. Automated clients are allowed access via both ‘Basic’ and ‘Bearer’ HTTP authorization schemes. End users are handled through Keycloak and grouped according to different categories, each one assigned with specific access grants.
How to secure RDAP
RDAP, as defined in RFC 7480, doesn’t natively include security services but merely relies on features available in other protocol layers, such as RFC 7481.
The first simple approach to securing RDAP uses the Basic HTTP authorization scheme. However, this solution doesn’t scale well in the RDAP ecosystem if a user anticipates needing to authenticate against any of a large number of RDAP servers. Depending on location, for example, a law enforcement officer might need to access sensitive RDAP data from neighbouring ccTLD registries frequently (for example, the e-evidence initiative in the European Union). A federated authentication system supported by OIDC could make it easier to operate and reuse existing identifiers, as OIDC provides the ability to collect additional user information that can be used by server operators to make fine-grained access control decisions.
The rdap-openid draft
An IETF draft describing a federated authentication system for RDAP based on OIDC has been proposed to reduce client credential management complexity.
OIDC is the protocol that supports the ‘login with Google’ and ‘login with Facebook’ options that many sites offer. A site that offers this functionality is essentially passing the responsibility of authentication to a trusted third-party service. Apart from making things easier for users, this also makes things easier for the site because they don’t have to manage new credentials and the related complexities involved.
The rdap-openid draft further adapts OIDC for the RDAP context. An end user can indicate to an RDAP server that they are intending to submit an authenticated request by using the id query parameter. For example: https://example.com/rdap/domain/example.com?id=user.idp.example
The value for the id parameter is the identifier used by the third-party authentication service. For example, Google typically uses a Gmail address. In line with standard OIDC practice, the RDAP server then redirects the end user to the third-party service for authentication. Once the user has authenticated successfully, they are redirected back to the RDAP server, which then proceeds to execute the query and return the results.
rdap-openid also supports retrieval by the end user of the tokens used in the OIDC process, to avoid having to log in repeatedly. This is necessary because the draft does not support stateful sessions between RDAP servers and clients. When using this feature, the end user submits a request to the RDAP ‘tokens’ endpoint, and then includes those tokens on subsequent requests to authenticate themselves.
According to our evaluation, the drawbacks we have found in this proposal don’t seem to be balanced by its gain in flexibility. Nevertheless, we decided to implement it.
The .it approach
The .it approach exploits the Keycloak capabilities to make RDAP compliant with OIDC with minimum effort and, at the same time, reduce the burden required to implement the rdap-openid draft.
To achieve the goal of securing RDAP and making it user friendly, we have also developed an RDAP web client to facilitate the retrieval of registration data for both authorized and unauthorized human users. Automated clients are also allowed access via both Basic and Bearer HTTP authorization schemes
Management of the OIDC process is delegated to Keycloak. User authentication/authorization and token handling are guaranteed by a ‘Keycloak adapter’.
Operational context
The operational context was defined by a set of constraints that can be grouped into three categories:
- Constraints with the implementation of a generic RDAP server
- RDAP doesn’t distinguish between protected and unprotected resources by design — any user can potentially submit any query and access any resource,
- Although a human user can query an RDAP server via a browser, in practice, the use of an ad hoc client improving the user experience is advisable.
- Access by both authenticated and anonymous users had to be guaranteed.
- Constraints related to the implementation of the rdap-openid draft
- The /tokens and /tokens/revoke endpoints, as well as the additional query parameters, had to be implemented.
- Constraints strictly connected with the implementation of the RDAP server
- The target software platform for the REST services had to be J2EE WildFly. This information was helpful to select the Keycloak adapter.
- The RDAP server had to be deployed through Docker on different software environment.
- Request and response features had to be provided according to the user profiles.
- Identities had to be stored locally.
Architecture
The architecture of the RDAP service (Figure 1) is composed of a frontend implemented as an RDAP client using the ‘React’ framework and a backend implemented as an RDAP server on a ‘WildFly’ application server. Both client and server are secured by a Keycloak acting as an OpenID Provider (OP). The client acts as a Relying Party (RP) regarding the classic OIDC scheme. The software environment for this implementation is the .it OTE (pubtest).
Shortly, two different services will be provided:
The RDAP server acts as both an RS regarding the classic OIDC scheme and an RP for the implementation proposed in the rdap-openid draft.
Each of the software components (Keycloak, RDAP client, and the RDAP server) is deployed on a dedicated Docker swarm stack. All communications outside Docker are based on HTTPS to protect the exchange of information.
User role mapping
According to .it policy on accessing the RDAP server, we defined four client roles and mapped them against users. The roles were: ANONYMOUS, AUTH_REGISTRAR, AUTH_REGISTRY and AUTH_USER. The roles-resources mapping is shown in the following:
- ANONYMOUS — Anonymous user has access to:
- /domain and /help endpoints are allowed.
- /domain: Undisclosed data is either redacted or not returned.
- /help: Only information about the allowed features is provided.
- AUTH_REGISTRAR — An .it registrar has access to:
- Every endpoint is allowed, and all information about the registrar’s sponsored objects is returned. Requests for unsponsored objects are treated in the same way as for anonymous users.
- AUTH_REGISTRY — An .it registry operator has access to:
- Any endpoint is allowed, and the full information is returned.
- AUTH_USER — A user authorized to perform queries for a specific purpose (such as authorities or police officers) has access to:
- The same grants as AUTH_REGISTRY but for a time-limited fixed query. The query is mapped to an additional OIDC claim of the temporary user. The RDAP server will check that the claim and the query submitted match.
rdap.pubtest.nic.it currently implements all the functionality defined in rdap-openid, including token retrieval and refresh.
What’s next?
Further development could be related to the management of the requests from users who are allowed to submit only time-limited fixed queries. According to .it regulation, the registry shouldn’t permit authorities and police officers to obtain registration data except for documented legitimate requests. Usually, those requests are submitted out-of-band and are satisfied by involving both the legal department (who check for admissibility), and the technical department (who collect the requested information). Regrettably, this process no longer meets the current requirements described in a new European Union directive.
Regarding the features provided by the RDAP client, they should be extended to support the other standard query capabilities already available on server side.
Mario Loffredo is the Deputy Chief of the Technological Unit, Digital Innovation at IIT-CNR. He is an active member of working groups at IETF and CENTR, with current interests in domain name protocol and applications, cybersecurity, and web technologies.
Francesco Donini works in the Technological Digital Innovation at IIT-CNR, developing and maintaining applications dedicated to Registrars and Registry operators.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.