Configuring the available attributes#

Stored attributes#

You must go to the “Data Sources” block in the “Stored attributes” section and take the following steps:

  • add a new attribute by clicking the “+Add Attribute” link;

  • specify the attribute name to be used in Blitz Identity Provider; The name of the attribute may be different from its name in the external repository - in latter case, you must specify the conversion rule in the settings of this repository (see Connecting storage via LDAP);

  • specify the value type - data type format (String, Number, Boolean, Bytes, Array of Strings);

  • set the attribute’s parameters:

    • whether it is possible to search for it (“Srch” column);


      If it is an attribute from a connected repository, it is recommended to create a search index for it.

    • whether the attribute is mandatory (the “Mand” column);

    • whether the attribute’s value should be unique in the system (column “Uniq”).

After adding an attribute, it is not allowed to change its name. If it is required to rename an attribute, delete, and create a new one.


In the “Users” section of the user card (see View and edit user attributes), the attributes will be shown in the order in which they were created. It is not possible to change the order of attributes via the admin console. If you need to change the order of attributes, you must manually reorder them in the blitz.conf configuration file in the settings section. In order to display their text names in the “Users” section instead of system attribute names, taking into account the user interface language, it is necessary to define for the created attributes in messages (see Web interface texts) lines with the description of attribute names for the used languages. The strings must have the form<attribute name>.

When you create a new attribute, a mapping of the new attribute is also automatically created in all connected attribute storages to an attribute with the same name. After creating new attributes, you have to check and edit the mapping configurations in the connected storages.If the attribute is not expected to be read from the storage, you have to delete the mapping line - in this case, the attribute will be stored in Blitz Identity Provider database.


If PostgreSQL is used as the DBMS, create a column in the USR_ATR table as well as in the USR table (if internal storage is used). The column name must correspond to the name of the attribute to be added, but be normalized from lowerCamelCase into UPPERCASE_SEPARATED_BY_UNDERSCORE, e.g., middleName -> MIDDLE_NAME. The column type must be chosen based on the type of the attribute value:

  • column with text type for attributes with String and Bytes type (in this case the value will be stored in Base64);

  • column with text[] type for attribute with Array of strings type;

  • a column with a suitable numeric type (bigint, integer, smallint) for attributes with Number type;

  • a column with bool type for an attribute with Boolean type.


It is possible to assign an LDAP directory attribute to a translator that converts the attribute from the format stored in LDAP to the required format in Blitz Identity Provider. For example, this can be useful if you need to process the objectGUID attribute from an Active Directory LDAP directory in Blitz Identity Provider so that the attribute is represented as a GUID string instead of a byte. This is configured via a configuration file, see Attribute translator.

Computed attributes#

To configure computed attributes in the “Computed attributes” block you should do the following actions:

  • add a new attribute by clicking the “+Add Attribute” link;

  • specify the name of the computed attribute;

  • specify the value type - data type format;

  • specify the calculation rule of the attribute based on other attributes or assigning a constant value to it.

Example of rules:

  • to create the First name and last name attribute from the stored attributes family_name and given_name, it is necessary to define the stored attributes family_name and given_name, and then set the computed attribute full_name with the computation rule - $${family_name} ${given_name}.

  • to create the attribute “e-mail domain” from the stored attribute email you need to define the stored attribute email, and then define the computed attribute domain and define its computation rule ${email###*@}.


You can find help on supported substitution string parameters here.


Input value conversion rules#

Input value conversion rules allow checking the correctness of the data input format and ensure that the data is saved in the correct format. Rules are specified using regular expressions. Each rule includes a regular expression that allows decomposition (splitting into parts) of the input value and a rule for saving the obtained parts (layout).

Example of solved tasks:

  • to check if the email attribute contains the @ character, you must specify a ^(.+)@(.+)$ decomposition expression and a ${0-} layout expression;

  • to check the format of the mobile and save it in the format +7(999)1234567, you must specify the decomposition expression ^(\+?)([78]?) ?\(?([0-9]{3})\)? ?([0-9]{3})[- ]?([0-9]{2})[- ]?([0-9]{2})$ and the composition expression +7(${3-})${4-}${5-}${6-}.


Example of configuring input value conversion rules

Output value conversion rules#

These rules allow additional transformations to be performed on computed attributes. For example, only necessary groups can be extracted from an attribute with an array of user groups, or group values from the format CN=name,DC=... should be converted simply to CN names. Examples of settings for such conversion rules are shown in the figure below (the corresponding computed attributes must be created beforehand, see Computed attributes).


Example of configuring output values conversion rules

Setting up attribute purpose#

It is necessary to specify which attribute will be the identifier in the system. The identifier must be unique and not change over time.


It is not recommended to change the base ID in the future, as all user settings are bound to it. Changing the base ID will lose two-factor authentication settings, registered security events, memorized user device lists, connections to external accounts, and user attributes stored in Blitz Identity Provider database.

You can also specify which attributes are used for special purposes:

  1. An attribute used as a marker of account lockout. This attribute must have a value type of Boolean. Blitz Identity Provider supports locking out users stored in the LDAP directory. To use this feature, you must also configure the appropriate attribute in the LDAP directory settings (see Connecting storage via LDAP).

  2. For example, the expression ${surname} ${name} ${middlename-} allows an account (for example, under “Users”) to display the last name, first name, and patronymic name (if it’s present).

  3. Attributes used to store email addresses.

  4. Attributes used to store mobile phone numbers.

Multiple attributes can be specified as e-mail and mobile phone attributes (e.g., for personal and work email address).


Configuring Attribute purpose