# Architecture Overview
The following diagram gives an architectural overview of a typical MIRACL Trust SSO setup:
The system is made up of the following components:
# 1. The MIRACL Trust SSO 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 Multi-Factor Authentication (MFA) server.
It is necessary to run at least one SSO 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. Note that using more that one IdP server requires using shared external storage which could be setup by REDIS.
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 SSO 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.io/authorize, https://api.mpin.io/oidc/certs and https://api.mpin.io/oidc/token.
# 2. Redis (Optional)
This is an optional dependency. Redis could be used to store data for logged in sessions (read more here). By default MIRACL Trust SSO service uses internal memory storage.
# 3. Consul (Optional)
Consul can be used for secure remote loading of your SSO configuration file. You could just list the Consul address which returns your SSO configuration in the config.yaml as includes.
# 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.
