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. The full eduPUID of the user could be stored in the certificate as a certificate parameter (e.g. alternateName) but this information will not appear in the certificate DN, certificateDN is usually the only information about user's certificate stored in the logs, therefore to improve traceability e-infrastructures should be able to autonomously map eduPUID to the re-hashed user UID used by the CA.

Recommendations for the O= fields

The "O=" fields contain information about the organization of the user. The certification authority should add the values of the following SAML attributes as separate "/O=" fileds in the certificate DN:

• schacHomeOrganisation
• organisationDisplayName
• domain name of the IdP entity ID URL

example:

• "/O=fullyQualifiedNameOrganizationA/O=OrganizationA/O=idp.organizationa.org"

Translating group information

Group information should not be directly encoded in the user personal certificate. In the X.509 protocol, additional attributes can be expressed through an Attribute Certificate (or Authorization Certificate, AC), which is signed by the attribute authority end entity certificate (usually the host certificate of the atuthority releasing the AC).

The advantages of keeping separated authentication and authorization information in two distinguished certificates are the following:

• User certificate can be re-used, without changing the DN, with multiple VOs, in the not-unlikely scenario of users with multiple membership (this include also different roles or subgroups in the same VO).
• AC can have a shorter lifetime than the end entity certificate. Identity information change less frequently than authorization information.
• The user UID (the certificate DN) does not change depending on the VO used by the user.

AC are usually used chained with a delegation proxy certificate. In this way the user proxy certificate chained with the AC contains all the authentication and authorization information needed by the services in a single X.509 artifact.

Recommendations for the translation of authorization entitlements into X.509 AC

• Group membership information should be translated into an attribute certificate (AC) separate from the EEC. AC should be included in a EE proxy certificate
  • RFC3820
  • RFC3281
• One AC should contain information about a single VO to univocally scope the group information
• Groups, sub-groups and roles within the group should be expressed in the form:
  • /<vo>/<group>/<sub-group/../Role=<role>
• AC should be short-lived, max 24h

References