You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Multi-factor authentication (MFA) implemented in Haka identity federation provides multi-factor authentication as a service that is easy to adopt for the home organizations and relying services. It uses standards based protocols for message transfer and user authentication. The target audience for the solution is mainly higher education organization employees. The solution can be extended to cover also the students.

Haka MFA implements two use scenarios

  • Service Provider (SP) initiated MFA (flow: SP → MFA → IdP)
  • Identity Provider (IdP) initiated MFA (flow: SP → IdP → MFA)

In the SP initiated use scenario a service provider directs all authentication requests to the MFA service with a keyword requesting a certain authentication level in it's authentication request. The MFA service first redirects the users to their home organization IdP for an ordinary (password) authentication. After that the MFA service performs an authentication using the second factor.

In the SP use scenario the IdPs observe the MFA service as the relying service. This is done by registering the MFA server's SAML assertion consumer URL to the relying service's federation metadata. This allows IdPs to release only relevant user attributes intended for the service.

In the IdP use scenario the MFA service is integrated to an IdP as another authentication method. Based on the authentication request and the policy rules an IdP can decide to request a MFA from the MFA service. If the IdP decides MFA is required, user is redirected to the MFA service after first performing an ordinary (password) authentication at the IdP. The IdP then redirects the user to the MFA service together with their authenticated identifier.

In the IdP use scenario the IdP and MFA service agree on the integration method. The Haka federation operator provides a Shibboleth IdP authentication handler that the home organisations can install to their IdP. The plugin and the MFA service use OpenID Connect protocol in their message exchange, enabling also IdP products other than Shibboleth to use the MFA with the IdP initiated use scenario. The MFA service accepts authentication requests in both SAML2 and OpenID Connect protocols. OpenID Connect is used in the IdP integration to MFA. The SP integration can be done using either protocol.

Currently the MFA service uses Time-based One-Time Password algorithm (TOTP) standard RFC 6238 as an authentication method. In practice, the user can for instance have a TOTP compliant app (such as, Google authenticator) in their smartphone. In addition an SMS-based authentication is used in user registration. When a user is directed to the MFA service their identifier released from the IdP is

examined. If the user has an existing second factor configured, the MFA can be invoked directly. If there are no existing second factors associated to the identifier, the user is directed to register and configure their second factor. The second factor registration is carried out by sending an SMS to the user's registered cellphone number.

  • No labels