The initial idea was to just consume attributes from the federations ("eduPersonEntitlement" etc.) that state if a person is an NREN-admin or an institution-admin. This idea has been dropped due to several reasons:

• Naming collisions. The attribute value we want for NRENs and institutions may already be taken.
• Reliance on attributes set by IdPs. Are the roles always kept-up-to-date and can we rely on them?
• Finally, an IdP-admin might raise her permission by just setting the NREN-admin attribute.

It was decided to bootstrap Confusa using a bootstrap script with an initial NREN admin using the eduPersonPrincipalName and entitlement (eduPersonEntitlement, 'confusaAdmin'). All persons with this attribute set can be granted administrator-rights, it is a necessary, but not sufficient condition. In order to achieve administrator status, the ePPN must be added to the admins-table.
The admins-table states the type of admin a given user is. There are 3 kinds of adminstrators:

NREN-admin

Can add other NREN-admins and subscriber (sub)admins. Revocation rights should at least be given to the incident response team.

Subscriber admin

Can add other subscriber admins and subadmins as well as revoking certificates for all users belonging to the organization.

Subscriber subadmin

Can only revoke certificates, not add new admins. This intended to fulfill the IT-support scenario where the common action is to revoke certificates, but you want tight control over who is granted (sub)admin rights.

Confusa's approach to reauthentication

For sensitive actions like requesting a new certificate or revoking certificates, reauthenticating the user is desirable, so open and forgotten sessions by users who did not log out can not be abused by malicious third parties. A suggestion to handle reauth from NRENs foresees the following:

• A user may reuse their federated identity from the session, if performing less sensitive actions, should they have one
• If the user performs a sensitive action, Confusa forces a reauthentication and pulls the refreshed attributes. Thus Confusa asks the user to establish their identity upon performing sensitive actions.

This approach is near optimal, because it exploits both the advantages of identity federations, allowing the user to not have to login for every service they use, while ensuring security for sensitive operations by enforcing reauthentication for them. Confusa does not use this approach, however. The reason is implementational. The only secure way to setup the above scenario with simplesamlphp implies configuring two different service providers, because the simplesamlphp-API call for forced reauthentication currently does not protect against replay-attacks.

Setting up two times two simplesamlphp service providers (escience and personal with and without forced reauth) is operationally unacceptable. Thus, we use a simplified approach.

• Require authentication of every user that enters Confusa
• Upon sensitive actions check a timeout value that can be configured per NREN
• If the user has used the session longer than the timeout, log the user out.
• Because the page is protected she will have to reauth

Reauthentication with OAuth

The OAuth-AuthManager does not have explicit reauthentication. Currently, we extend the OAuthDataStore with our own subclass that gets the reauth-timeout parameter as it is retrieved on per-NREN basis via a special attribute. Subsequently, it limits the validity period of the OAuth access token to the validity period in the attribute. The access token will expire after the reauth-period, forcing the user to get a new one.