Deployment architecture#

The functioning of Blitz Identity Provider is based on the interaction of the following architectural components:

  1. Web Server. You can use your company’s existing web server to load balance and remove SSL encryption from incoming traffic.

  2. Blitz Identity Provider services:

    • blitz-console – admin console;

    • blitz-idp – authentication service and user personal account;

    • blitz-registration – enrolment service;

    • blitz-recovery – access recovery service;

    • blitz-keeper – security gateway.

    Note

    You do not need to install the Enrollment, Access Recovery, and Security Gateway services if you do not plan to use their related features.

  3. DBMS. You can use Couchbase Server, PostgreSQL, Postgres Pro.

    Attention

    Interaction of Blitz Identity Provider with PostgreSQL is performed via JDBC. Any relational DBMS with JDBC support can be used instead of PostgreSQL, but it should be separately agreed with our technical experts within the framework of the corresponding implementation projects.

    • Couchbase Server is recommended for building authentication systems with a peak load of over 1000 requests per second, more than 1 million authentications per day, and with high fault tolerance requirements.

    • PostgreSQL (or other relational DBMS supporting JDBC) is recommended when creating authentication systems with moderate load and medium requirements for fault tolerance, as well as when using domestic operating systems.

  4. Account and password storage. You can use an existing or specifically deployed repository.

    Supported:

    • LDAP-compliant storage. It can be any server supporting LDAP protocol, as well as Microsoft Active Directory, Samba4, FreeIPA;

    • other types of repositories, to connect Blitz Identity Provider to them you need develop special REST-services.

    If you need to deploy a new LDAP directory, it is recommended that you use 389 Directory Server, which is included with the OS, as your LDAP directory.

  5. Optional RabbitMQ as Queue server. It is also possible to configure the transmission of security reports to Kafka. Installation of the RabbitMQ Queue server is required if it is to be used to pass events to adjacent systems or as a message broker.

Deployment is possible in a configuration with minimal resources or in a cluster.