Goals

The eduTEAMS Stepup Authentication Service ("eduTEAMS Stepup") aims to provide research communities with a capability to:

1) use second factors to improve (first factor based) authentication strength, based on the ownership of a self-registered second factor

2) use a workflow to validate an identity (Identity Proofing) and bind the identity to a specific pre-registered tokens so to improve identity strength

Functional Components

The eduTEAMS Stepup service is based on the OpenConext Stepup service and hence uses similar components. Figure 1 provides an overview of functional components

application overview

The Stepup Platform has been split into 4 functional components, each is implemented as a separate application:

  • Self Service, the application where users can register their own second factor.
  • Registration Authority, the application where Registration Authorities can vet the registered second factors as well as where Registration Authority Administrators can manage the registration authorities themselves.
  • Gateway, the application that contains the SAML gateway. In the gateway the required LoA can be verified with the vetted Second Factors to grant additional confidence about the logged in Identity.
  • Middleware, the authoritative application with respect to all the data handled within the platform

The Self Service, Registration Authority and the Gateway are publicly accessible, the Middleware is not. Furthermore the Self Service and Registration Authority applications do not have an own data-store, all their data is governed by the Middleware application. The middleware application allows (limited) modification of data and reading of data through an API. The Gateway has its own data-store, however the data is still governed by the Middleware, it is read-only for the Gateway. The rationale behind this is that even if the Self Service, Registration Authority and Middleware applications fail, the Gateway must be able to keep functioning as this provides the functionality core to the platform.

eduTEAMS (LSAAI) specific implementation

For eduTEAMS/LSAAI we want to integrate the stepup components in a way that allow us to use the features in combination with the existing proxy architecture of the LSAAI pilot. For the LSAAI pilot, it may be expected the end-user facing components, Self Service and Registration Authority, require to be branded towards the specific community. That is however not needed for the central components, the Gateway and the Middleware. AS the middleware is API driven, it should be possible to have multiple instances of both Self Service and Registration Authority using the Middleware component. As part of the Pilot I propse we test this assumption by deploying a eduTEAMS generic Gateway and the Middleware, but a LSAAI specific Self Service and Registration Authority instance. In addition we deploy an seperate Self Service and Registration Authority instance for the GEANT project which can be used by us and also by other tasks in the GEANT project for testign and experimentation, as shown in figure 2

The above setup should already be able to proved the required functionality as described in Goal #2. As a proof of concept we can use Yubikey and SMS tokens. For using SMS, we will have to purchage a small bundle to allow sending SMS messages.



  • No labels