The AARC (Authentication and Authorization for Research Collaboration) \[1\] framework defines requirements and best practices for configuring OIDC relying parties. OpenProject is lacking some of the required features:

* Requesting additional custom claims
* Authorization and mapping through OIDC claims
* Logical operations on claims
* Association of OIDC group identifiers to OpenProject groups
* Extending / Generalizing UI for configuring OIDC

## Requesting additional custom claims

The default OpenID Connect configuration does not allow for requesting/requiring additional claims through the UI.

## Extended authorization through OIDC claims

Currently, OpenProject OIDC integration provides only basic authorization of users based on claims, effectively rejecting the authentication based on presence or absence of certain claim values. It is not possible to define roles, group or project memberships through existence of claims.

Open question: Is it sufficient to restrict authorization to the memberships of groups, as through that follows the authorization on global roles and project memberships.

## Logical operations on claims

The authorization result should allow logical operations on the existance or presence of claim values. For example, authorize the user if a claim contains values A (AND) B, A (OR) B, or A (AND NOT) Begin of the insertionB.End of the insertion Begin of the deletion B. End of the deletion

Open question: What is an example of such a combination to derive a membership?

## Association of OIDC group identifiers to OpenProject groups

Similar to the LDAP group synchronization, internal OpenProject groups need to be associated with a respective OIDC counterpart through a unique identifier, e.g., a URN.

This allows the OpenProject group to be arbitrarily (re)named without losing the connection to the OIDC claim.

## Extending / Generalizing UI for configuring OIDC

An admin interface exists for creating or managing common OIDC identity providers such as Azure, Google, etc. They are however not configurable or generalizable for other OIDC integrations. This UI needs to be extended to be able to properly specify and encode logic operations on claims.

## Distinction from OIDC + LDAP group synchronization

Currently, OpenProject supports authentication through OIDC in combination with an LDAPv3-compatible directory service to derive groups and their memberships.
This has the advantage of immediately adding users to the respective authorized groups when the synchronization is performed. In contrast to SSO-based authorization, where users are only synchronized upon retreiving their claims during a login phase.

Begin of the insertionFor customers planning to employ AARC, a pre-existing LDAP group synchronization pattern is likely to be active. We need to either:

1. Allow both to operate at the same time, potentially on the same groups. This would require ensuring both methods identify the same user and block each other to prevent race conditions
2. Allow a migration from LDAP to OIDC based group synchronization by taking over the groups for OIDC (e.g., by providing the internal URNs to set them up initially)

_HowEnd of the insertion Begin of the deletion HowEnd of the deletion will this lifecycle be implemented for Begin of the insertionAARC?_End of the insertion Begin of the deletion AARC?End of the deletion

\[1\] [https://aarc-project.eu/](https://aarc-project.eu/)