Best practices and recommendations for the attribute transaltion from federated authentication to x.509 credentials

This page is a summary of the findings produced by the AARC project on the translation of authentication and authorization attributes from federated authentication credentials to X.509 credentials. This page shows examples of translation between SAML2 attributes and X.509, but the same principles are applicable to OpenID Connect sources of attributes. 

The goal of this short document is to suggest a common way to encode in X.509 credentials authentication and authorization, to increase the re-usability and interoperability of X.509 credentials generated by token translation services.

Authentication and authorization information separation

Where:

"Authentication information" means the information that define the identity of the user such as for example, name, unique identifier or organization.

"Authorization information" means the information that are used to define if a user is entitled to access a service: group membership (virtual organization membership), sub-group membership or roles.

Although this may not be the actual implementation for every use case, we will assume that every authorization model within a community can be modeled as users' membership to groups created in the organization.

One of the goals of the best practices described in this document is that authorization and authentication information can be provided by separated entities, similarly to what may happen in a federated identity scenario, where the IdPs provide the authentication information and the authorization attributes are provided by attribute authorities managed by the communities or other third parties. A similar approach should be implemented for the X.509 credentials, as shown in the following figure.

The information form the IdP are used by a certification authority to create a personal certificate with the authentication information of the user, while the group membership attributes are used by an X.509 group management to extend the user certificate with group membership information.

Translating authentication information

IGTF is the most relevant X.509 certification authorities federation for research infrastructures and e-infrastructures worldwide. the CA federated in IGTF are commonly accepted by EGI, PRACE, EUDAT, OGF and many other service providers federation in the world. This paragraph will focus on the IGTF profile for X.509 certificates as described by the existing policies.

The following are (some of the) the attributes that are permitted in the end entity certificate DN:

DC: Domain
C: Country
L: Locality
O: Organization
CN: Common name

/C=NL/O=NIKHEF/CN=NIKHEF medium-security certification auth 
/O=dutchgrid/O=users/O=egi/CN=Peter Solagna

The first line is the namespace, which usually within IGTF identifies the certification authority, and the second line are the attributes specific of the user. The CA prefix is unique within IGTF (between certification authorities) and the user CN must be unique within the namespace.

The recommendations for the user CN are the following:

1. CN attribute shall be a combination of the SAML attribute "displayName" and the eduPersonUniqueID
   1. If eduPersonUniqueID is not released eduPersonPrincipalName shall be used
   2. if eduPersonPrincipalName  is not released eduPersonTargetedID shall be used
2. The CA must ensure that the CN is unique within their namespace
3. The RFC (5280 or 2459 to check) limits the length of the CN field to 64 characters. The string obtained as a combination of displayName+eduPUID may be longer than the limit. The CA must therefore re-hash the eduPUID to use a shorter, but globally unique, version of the user unique identifier.
   1. The re-hashing makes impossible for the e-infrastructure to map univocally the user's UID provided by the IdP to the certificate DN. This information can be provided by the CA as part of an incident response procedure.
   2. The CA must publish publicly the re-hashing algorithm, any change to the algorithm should follow a clear procedure to communicate the changes to all stakeholders. In this way the e-infrastructure can calculate the re-hashed user eduPUID used in the certificate and store the information internally, for a quicker incident response procedure.

References