13.1.2 WEB authentication configurationThe authentication method used on the GUI can be configured any time and not just during the installation process. The configuration is only described in the Installation section, because mostly it is done during the installation process. 13.1.2.1 Authentication methodsPVSR supports several different authentication methods. The application displays the login name and the password fields on the PVSR splash screen. The password is checked by PVSR itself, using the configured authentication method. If the login is successful then it creates a so-called cookie and it authenticates the user during the session with this cookie. When the user logs out then PVSR destroys this cookie and the user can login with a different login name. Not every authentication method belonging to this group allows password setting. This means that when such an authentication method is used and the user is created in PVSR, then the password will not be configured and so the administrator will need to set the password manually. Also in these cases the user cannot change his own password and so the Settings => User => Password menu item is not displayed, unless the CUSTOM_PASSWORD_PAGE parameter is set in the CONFIG_INI.pm file. If it is set and the authentication method doesn't have a built-in password setting feature then PVSR displays the menu item nevertheless and the page configured in the parameter is displayed if someone chooses this menu item. The available authentication methods: · Based on the password file. This method supports the password setting · LDAP: PVSR uses an external LDAP server for authentication. This method does not support the password setting feature, i.e. the administrator has to create the user and set the password in the LDAP server separately · RADIUS: PVSR uses an external RADIUS server for authentication. This method does not support the password setting feature, i.e. the administrator has to create the user and set the password in the RADIUS server separately · CAS (http://www.jasig.org/cas): PVSR uses the CAS (Central Authentication Service) for authentication. This allows SSO (single-sign-on). The method does not support the password setting feature, i.e. the administrator has to create the user and set the password in the CAS server separately. While this authentication generally allows logout (in SSO this means logout from every application) the administrator can disable this in PVSR. The indented use for this is when the CAS server uses automatic domain authentication, since in that case the user cannot really log out · Keycloak (https://www.keycloak.org/): PVSR uses the Keycloak for authentication. This allows SSO (single-sign-on). The method does not support the password setting feature, i.e. the administrator has to create the user and set the password in the Keycloak server separately 13.1.2.2 Setting the authenticationThe configuration is done with the pvsr_auth.cfg file in the PVSR etc directory (/opt/pvsr/etc by default). The application supports a different authentication method for the SOAP and the REST API, in this case the pvsr_auth_rest.cfg file has to be created/edited. 13.1.2.2.1 Basic authenticationOld, no longer supported authentication method. 13.1.2.2.2 Password file-based authenticationThe first line of the pvsr_auth.cfg file must be: password_file Since this method does not have additional parameters, the other lines in the file do not matter. 13.1.2.2.3 LDAP authenticationThe first line of the pvsr_auth.cfg file must be: ldap This method has several configuration parameters. Some of them are required while others are optional. Some of the parameters can have multiple values while others can only have one value. The parameters must be specified in the form name=value. If a parameter has multiple values then they must be specified in separate lines. The parameters are: · ldap_url: the LDAP server is accessed with this URL. The parameter is required and it can have multiple values. If it has multiple values then PVSR tries to connect to the first one, if that's not successful then it tries to connect to the second one, etc… If the connection is successful then the authentication is checked using that server. If there are two URLs configured and both of them are reachable but the login name and password only exists in the second server then the authentication will be unsuccessful. Example: ldap_url=ldap://192.168.35.1:10389/ ldap_url=ldap://192.168.35.2:10389/ · timeout: the number of seconds before PVSR tries another LDAP server. Its value is 10 if not specified timeout=5 · bind_dn and bind_pwd: the DN to be used for the initial BIND operation, i.e. PVSR will connect to the LDAP server with this user name/password to search for the login name given by the user. They are optional parameters and PVSR only takes them into account if both of them are specified. If they are left empty then PVSR uses anonymous bind. The parameters are required if the LDAP server does not allow the anonymous bind. Example: bind_dn=uid=admin,ou=system bind_pwd=password123 · base_dn: PVSR searches for the login name given by the user in the tree hierarchy below this DN. It is a requred parameter and cannot have multiple values. Example: base_dn=o=pvsr · search_attr: PVSR searches for the login name given by the user in this parameter. It is a requred parameter and cannot have multiple values. It is important that PVSR must find exactly one object with the given login name value. Example: search_attr=cn · auth_attr: if PVSR was able to find exactly one DN with the search_attr parameter set to the login name given by the user, and the password was also correct then it takes the value of the auth_attr parameter. It searches then in the PVSR user database for a user whose Login attribute has the same value as the auth_attr. It is a requred parameter and cannot have multiple values. Example: auth_attr=uid · name_attr: if the automatic user creation is configured and this parameter is set then PVSR uses the value of this parameter instead of the value of the auth_attr parameter if it has to create a new user in the system · msad_gig és msad_gig_base_dn: if the msad_gig parameter is set to 1, then PVSR accepts users if they belong to any of the specified Windows AD groups child group, not just when they belong to the specified groups. If the msad_gig_base_dn parameter is set as well then PVSR uses this DN to search for the Windows AD groups and not the DN specified in the base_dn parameter · admin_dn: if PVSR was able to find exactly one DN with the search_attr parameter set to the login name given by the user, and the password was also correct and the DN of the entry is among the values of the admin_dn parameter then PVSR will not even look at the auth_attr parameter. Instead it will login that user as the admin PVSR user. The parameter is optional and it can have multiple values. Examples: admin_dn=cn=Szabó Balázs,ou=valid-users,o=pvsr admin_dn=cn=Kiss Ákos,ou=valid-users,o=pvsr · overwrite_pvsr_group: if it is set to 1 and we are using group filtering (see below) then after the successful login PVSR uses the groups in LDAP to match to one of its groups. It considers those groups first which have the higher security level in PVSR. The LDAP groups are identified by the Login parameter of the PVSR groups. However it is important to note that PVSR will not automatically create groups in its database, so if we want to use this feature then all groups mentioned in the config file must be manually created as user groups in PVSR · create_pvsr_user_from_ldap: if it is set to 1 and the authenticated user does not exists in PVSR then the application automatically creates it, as a non-administrator user · filtering parameters: all of the following parameters can be used for further user filtering before the user is allowed in PVSR. None of them is required, every one of them can have multiple values and if neither is specified then the login is successful if the user exists in PVSR or the DN of the entry is among the admin_dn values. Since the user must either exist in PVSR or be among the admin_dn values, these are already implicit filtering conditions, so normally there is no need to filter the user names further more. However: if even one of them is specified then the user must either match one of them or must be among the admin_dn values o group: the entry must belong to one of the given groups group=cn=pvsr,ou=valid-users,o=pvsr o user: additional filtering based on the search_attr parameter values user=Páka Tamás user=Horváth Kálmán o dn: additional filtering based on the DN parameter values dn=cn=Páka Tamás,ou=valid-users,o=pvsr dn=cn=Horváth Kálmán,ou=valid-users,o=pvsr o filter_attr: arbitrary filtering based on any parameter. The value of the filter_attr must be in the format parameter_name=parameter_value. The LDAP entry must contain the exact same value in the parameter_name parameter filter_attr=allow_pvsr=Yes Simple pvsr_auth.cfg file with anonymous bind: ldap ldap_url=ldap://192.168.35.1:10389/ base_dn=o=pvsr search_attr=uid auth_attr=uid 13.1.2.2.4 RADIUS authenticationThe first line of the pvsr_auth.cfg file must be: radius This method has several configuration parameters. Some of them are required while others are optional. Some of the parameters can have multiple values while others can only have one value. The parameters must be specified in the form name=value. If a parameter has multiple values then they must be specified in separate lines. The parameters are: · host: the RADIUS server IP address and port. The parameter is required and it can have multiple values. If it has multiple values then PVSR tries to connect to the first one, if that's not successful then it tries to connect to the second one, etc… If the connection is successful then the authentication is checked using that server. If there are two hosts configured and both of them are reachable but the login name and password only exists in the second server then the authentication will be unsuccessful. Example: host= 192.168.35.1:1645 host= 192.168.35.2:1645 · timeout: the number of seconds before PVSR tries another RADIUS server. Its value is 10 if not specified timeout=5 · secret: PVSR uses the given secret value when communicating with the RADIUS server. Example: secret=pvsr_secret · admin: if PVSR was able to login into the RADIUS server with the given name and password and the login name is among the values of the admin parameter then PVSR will login that user as the admin PVSR user. The parameter is optional and it can have multiple values. Examples: admin=balazs_szabo admin=akos_kiss · user: the parameter can be used for further user filtering before the user is allowed in PVSR. It is optional and can have multiple values. If it is not specified then the login is successful if the user login name exists in PVSR or the login name is among the admin values. Since the user must either exist in PVSR or be among the admin values, these are already implicit filtering conditions, so normally there is no need to filter the user names further more. However: if it is specified then the user must be among its values or must be among the admin values. Examples user=tamas_paka user=kalman_horvath Simple pvsr_auth.cfg file: radius host=192.168.35.1:1645 secret=pvsr_secret 13.1.2.2.5 CAS authenticationThe first line of the pvsr_auth.cfg file must be: cas This method has several configuration parameters. Some of them are required while others are optional. The parameters must be specified in the form name=value. The parameters are: · server: the URL for the CAS server. The parameter is required and it can only have one value. Example: server=https://my_server/cas_installation/ · timeout: the number of seconds before the PVSR <==> CAS server communication times out. Its value is 10 if not specified · allow_logout: if its value is 0 then PVSR will not display the logout icon. The default value is 1 Simple pvsr_auth.cfg file: cas server=https://192.168.35.3:8443/test-cas/ 13.1.2.2.6 Keycloak authenticationThe first line of the pvsr_auth.cfg file must be: keycloak This method has several configuration parameters. Some of them are required while others are optional. The parameters must be specified in the form name=value. The parameters are: · realm_url: the realm is the Keycloak server is accessed with this URL. The parameter is required. Example: realm_url=http://192.168.25.120:8080/realms/test-realm · timeout: the number of seconds before the PVSR – Keycloak communication times out. Its value is 10 if not specified timeout=5 · client_id: the identifier of the PVSR application in Keycloak. Mandatory parameter. Example: · client_secret: the password used by PVSR when talking to Keycloak with the client_id user. It is optional · overwrite_pvsr_group: if it is set to 1 then after the successful login PVSR uses the roles in Keycloak to match to one of its groups. It considers those groups first which have the higher security level in PVSR. However it is important to note that PVSR will not automatically create groups in its database, so if we want to use this feature then all groups mentioned in the config file must be manually created as user groups in PVSR · create_pvsr_user_from_ldap: if it is set to 1 and the authenticated user does not exists in PVSR then the application automatically creates it, as a non-administrator user |