Deployment architecture

The operation 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 Console;

   • blitz-idp - authentication service and User profile;

   • blitz-registration – registration service;

   • blitz-recovery – access recovery service;

   • blitz-keeper – security gateway;

   • blitz-panel – a panel that provides users with quick access to connected applications.

   Note

   Registration and access recovery services, the security gateway and the panel do not have to be installed, if you don’t intend to use their associated 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 specialists within the framework of the corresponding implementation projects.

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

   • PostgreSQL (or other relational DBMS supporting JDBC) - 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 repository. You can use either an existing or specially deployed in your organization repository of accounts for its storage.

   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 to 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 Queue server – used by RabbitMQ. You can also configure the transmission of security events to Kafka. Installing a RabbitMQ queue server is required if the queue server will be used for transmitting events to adjacent systems or as message broker.

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