Architecture and Flow Diagrams

Product Architecture

The following diagram gives an architectural overview of a typical MIRACL Trust SSO setup:

architecture

The system is made up of the following components:

1. The IdP Server

This carries out the user authentication and communicates with the configured Service Providers via the SAML protocol. The authentication backend is the MIRACL Trust Zero-Factor Authentication (ZFA) server.

It is necessary to run at least one IdP server. It is recommended to run multiple IdPs in conjunction with a Load Balancer to manage the multiple servers. The aim is to ensure availability in terms of the service being able to cater for large numbers of users, and reliability in terms of continuity of service provided by ensuring a minimum number of servers are always running.

Best practice in server management should be followed in terms of managing graceful shutdowns of servers, making restorable backups before update procedures, ensuring enough servers are running at any one time whilst updates are running, redirecting traffic as needed, testing before rollout to all servers, etc.

The service does not directly provide TLS support. A TLS termination proxy is required in order to ensure that every communication to and from the IdP server is encrypted.

Note that it is strongly advisable to ensure that the base url "/", "/status" and "/metadata" endpoints are not publicly exposed.
It is also important that your network settings allow connection to the https://api.mpin.io/.well-known/openid-configuration endpoint, as this is where the program attempts to get the platform configuration. It also needs outgoing access to https://api.mpin.authorize/, https://api.mpin.io/oidc/certs and https://api.mpin.io/oidc/token

2. Redis (mandatory)

This is considered a dependency. Redis is used to store data for logged in sessions.

3. Consul/Etcd (optional / mandatory for Docker)

Consul or Etcd can be used for secure remote loading of your IdP configuration file. For a standard debian or rpm installation, the IdP configuration can be loaded from a local file in /etc/srv-idp/config.json. Use of Consul or Etcd is mandatory for Docker installations.

4. Statsd (optional)

StatsD can be used to collect usage metrics which can then be used with a StatsD-compatible client such as Graphite (https://github.com/etsy/statsd/blob/master/docs/graphite.md) to visually render key system performance information such as session starts, logins, communicating with the authentication server, spikes in 404 statuses etc. A useful Docker image for Graphite can be found at https://github.com/hopsoft/docker-graphite-statsd

 

Flow Diagrams

idp-initiated-login

sp-initiated-login

idp-services

idp-logout

Top