Architecture

The following image shows the architecture of the OLYMPUS solution and the flows in an application scenario.

ol_architecture

Roles and components

OLYMPUS issuer

The OLYMPUS issuer is a virtual Identity Provider (vIdP) comprised of multiple IdPs, offering two alternatives for issuance. An IdP has three key components:

  • Distributed Authentication: Handles authentication of users averaging PESTO and other related functionality like managing identity provers.

  • Distributed Token Management: It is in charge of distributed token generation (PESTO approach). Each IdP generates a token share given an access policy. When all the necessary token shares have been generated, the user client will be able to combine them into a valid access token to be presented to the Relying Party (RP, also called Service Provide (SP)).

  • dP-ABC Credential Management: It is responsible for the management of distributed credentials (dp-ABC approach). As in the distributed tokens approach, each of the IdPs will generate a share (credential share). The user will be able to combine them in a full credential which will contain all the user attributes. Unlike in the previous approach, the credential can be reused several times to derive crypto-proofs to be presented to the relying party.

User

OLYMPUS offers an user client which can be integrated in applications willing to use the solution. The client includes:

  • Client logic: Handles general client logic like interaction with IdPs…

  • Credential management: Present only if the dp-ABC approach is used, manages credential usage (combination presentation generation…).

Relying party (RP), or Service Provider (SP)

Protects access to a range of resources or services. It will generate the access policies that the user will need to satisfy to access to the service. The RP will rely on the verification library provided by OLYMPUS (though for the PESTO approach a standard JWT verifier would suffice) to verify the validity of user presentations.

Flows

The clients will keep an active session such that the password and optional MFA token is only needed to the first API call in a session. After that the password (or retrieved signing key in case of Pesto and dp-ABC) will be cached locally along with a server generates session cookie. For the rest of the session only the username and session cookie is needed by the server to authenticate the client. Exceptions are critical tasks such as deleting the user’s or adding/removing MFAs. Furthermore, if distributed password authentication is used (through the Pesto or dp-ABC clients) then signatures on every REST call is needed using the user’s retrieved signing key. It should be noted that once an MFA has been associated to a user’s account it must always be used in order for the user to authenticate. Furthermore, session cookies are used regardless of whether an MFA is associated with the user’s account.