Basically, is divided into interactive (user enters username and password) and SSO (Single Sign On, the application tries to take over verification from the authentication already made in OS).

Also combination is possible, when an application tries SSO and when it fails, will offer interactive user authentication.

EGJE leaves user authentication to an external authority, the so-called Identity Provider (IdP). It communicates with this IdP via well-known protocols, currently EGJE supports LDAP, NTLM, Kerberos, SAML, OIDC (see further in the text).

EGJE expects this authority to ensure identity verification in accordance with applicable legislation (in the Czech Republic, for the regime of lower obligations, it is No. 410/2025 Coll., in Slovakia Decree No. 227/2025 Coll.)

Note 1: We don’t recommend to use Windows account with diacritics.

Note2: Working with application server, this page is without usage for client configuration.

After changes in this tab it is necessary to restart AS respectively WEB EGJE server.

In the configurator, on the Authentication tab, the data required for entering authentication is dynamically displayed, according to the selected type from the code list. According to the selected item, a form with the necessary data is displayed interactively. Since it is necessary (regardless of the authentication type) to enter LDAP authentication in some cases (to enable work with various reports and forms), the LDAP authentication setting is also embedded here for all types of authentications.

On the AS/WEB tab, within the Web server mode, you can define the Configuration for mobile access and set parameters, e.g. http address for redirecting the user if he has no assigned profile or e.g. a list of profiles allowed for the Web, etc.

2.1 Authentication – selected authentication mechanism.

2.1.1 mswin_ntlm

Produced by Microsoft security package.
Enables SSO (authentication taking over from the OS) but only for MS Windows
(the installation of the AS / Web server, OS Windows is also mandatory for them)
It does not require any additional parameters.
AS / Web server must run under the user from domain.
Client setup - enter the server name as a name and not as an IP address.
You can use it for the java client without AS also.
If fails the SSO authentication login, it'll follow a dialogue (with the domain).

2.1.2 mswin_ntlmOnly

If fails the SSO application quits.

2.1.3 mswin_ntlmInteractive

Application always uses the authentication dialog.

2.1.4 mswin_kerberos

Produced by Microsoft security package.
Stringent authentication, that first tries Kerberos authentication.
SSO like mswin_ntlm.
It requires to set up a service principal name SPN for a domain (setspn utility) for applications and users:

· setspn utility (for Windows Server 2003 it or yourself from the installation CD)

· setspn.exe-A principal account

where the principal is
HTTP / ServerName for EGJEWEB,
EGJE / ServerName ASfor
account the account running the AS respectively. EGJEWEB

AS / Web server must run under the user from the domain.
Client setup - enter the server name as a name and not as an IP address.
If fails the SSO authentication login, it'll follow a dialogue (with the domain).

2.1.5 mswin_kerberosOnly

If fails the SSO application quits.

2.1.6 NTLogin2

user authentication is taken from Windows NT Authentication,

If fails the SSO authentication login, it'll follow the NTLoginInteractive

2.1.7 NTLogin2Only

dtto with the exception that only login takeover from the OS is allowed

2.1.8 NTLoginInternactive

the authentication dialog (common for ntlm and ntlm2)

if server is linux and authentication should be SSO with AD, there is a possibility to use

protocol NTLM2.

It is necessary to fill some parameter - see paragraph NTLogin/2 JCifs description

2.1.9 NTLogin3

Similar to NTLogin2 but allows the use of the newer SMB2 protocol

2.1.10 NTLogin3Only

dtto with the exception that only OS-based login takeover is allowed, but it enables the use of the newer SMB2 protocol

2.1.11 NTLogin3Internactive

with authentication dialog

2.1.12 LDAPOnly

application to the LDAP server (typically Microsoft Active Directory entry userPrincipalName.

To the "LDAP / Web entries - default domain user" admin enters the domain (ie what is in userPrincipalName after the @ character- the user than need not enter it)

In this mode the ssl connection is allowed only.

2.1.13 ldapsearch

similar to LDAPOnly. In a LDAP SSL URL is in addition the macro with the name

e.g. ldaps: / / xxxxxxx / dc = yyy , dc = com

see http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/url.html format description

Note: you should set the filter to separate specialized item LDAPSearch - filter.

Other items:

LDAP - user with rights to read

LDAP - password for user with rights to read

Through this user, the application accesses and searches the whole subtree and finds in it the authenticating user.

If the LDAP server allows anonymous users you can leave the items blank.

LDAPSearch - filter - Filter, asserted after logging to the LDAP server

(required for Novell eDirectory)

e.g. uid =%username%

LDAPSearch – the unique identity attribute of the user – the attribute in AD specifying the logname value of the logged-in user. If not filled in, the DN value is used as the logname within EGJE (Distinguished Name). The value of this attribute, if filled, has to correspond to the macro %username% listed within the configuration item LDAPSearch – filter. E.g. Setting of LDAPSearch – filter (&(objectClass=person)(employeeNumber=%username%)), LDAPSearch – the unique identity attribute of the user: employeeNumber

2.1.14 kerberos

Compared to mswin_kerberos, here the AS/Web component can run on a Linux server.

There are two types of authentication:

· kerberos – only interactive

· kerberos_sso – Authentication sequence: SSO first; if SSO is not executed, fallback to interactive login

Obsah obrázku text, snímek obrazovky, řada/pruh, Písmo

Obsah generovaný pomocí AI může být nesprávný.

For both authentication methods, it is necessary to configure the krb5.conf file (realm configuration).

For this type of authentication, correct DNS settings are essential.

When configuring Linux authentication against Active Directory, it is recommended that the primary DNS server is the Active Directory domain controller.

If required, it is possible to enable the older and less secure rc4-hmac cipher.

In such a case, add allow_weak_crypto = true to the [libdefaults] section of the krb5.conf file and include the cipher in the list of allowed encryption types.

However, due to security reasons, this is not recommended.

If not enabled, it may be necessary to allow newer and more secure AES ciphers for the given account.This is configured via Group Policy in the Default Domain Policy and the Domain Controllers Policy.

In Group Policy Management, for each policy navigate to:

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options

Then, in the policy Network security: Configure encryption types allowed for Kerberos, adjust the settings in Properties:

· Select (check) Define these policy settings

· Select (check) the required encryption types — AES is recommended)

It is also necessary to enable AES ciphers for Kerberos for the service account.

In the account properties under Account → Account Options, check the items:

“This account supports Kerberos AES XXX-bit encryption.”

After applying this setting, it will be necessary to change the password and, if required, generate a new keytab file (see section below).

krb5.conf file example:

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

ticket_lifetime = 24000

default_realm = FIRMA.CZ

dns_lookup_realm = false

dns_lookup_kdc = true

default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

[realms]

FIRMA.CZ = {

kdc = serverdc.firma.cz:88

admin_server = serverdc.firma.cz:749

default_domain = firma.cz

}

[domain_realm]

.firma.cz = FIRMA.CZ

[kdc]

profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]

pam = {

debug = false

ticket_lifetime = 36000

renew_lifetime = 36000

forwardable = true

krb4_convert = false

}

2.1.15 kerberos_sso

In the AS client configuration, the server must be specified by hostname and not by IP address.

For the Java client without AS, this mode is not suitable.

If SSO login fails, an authentication dialog will appear.

It is necessary to create a service account in Active Directory for pre-authentication. For this account, you must also create a Service Principal Name (SPN)

The SPN is created using the setspn utility:

setspn.exe -A <principal> <account>

kde principal je

· HTTP/ServerName for EGJEWEB,

· EGJE/ServerName for AS

account - The SPN must be created for the account under which AS (or EGJEWEB) is running

For successful SSO login, one of the following two configurations can be used.

Pre-authentication user

Specify the pre-authentication user and their password.

This method is not recommended for production environments.

Keytab file:

Create a login.conf file that contains the path to the keytab file and the service principal of the registered account in the principal entry.

This method is the recommended option for production environments.

The section names in the configuration must remain exactly as defined in the example.

Access rights to the keytab file should be granted to the user under which the Application Server or Web Server is running.

The keytab file is generated on the DC using the ktpass utility:

ktpass -out <path\to\file\filename.keytab> -princ <principal>@<realm> -mapUser <doména>\<účet> -mapOp set -pass <heslo> -ptype KRB5_NT_PRINCIPAL -kvno 0 -crypto All

where filename.keytab is the location where the file will be generated

principal:

· HTTP/ServerName for EGJEWEB,

· EGJE/ServerName for AS

realm - the realm specified in krb5.conf

damain - your damain

account – service account

password – service account password

If it is necessary to run multiple services under the same account (e.g., EGJEWEB and AS), it is possible to add the password for the additional account to the existing keytab file.

After creating the SPN, run the command for generating the keytab file and pass the previously generated keytab file as a parameter:

ktpass -in <path\to\file\filename.keytab> -out <path\to\file\filename.keytab> -princ <principal>@<realm> -mapUser <doména>\<účet> -mapOp set -pass <heslo> -ptype KRB5_NT_PRINCIPAL -kvno 0 -crypto All

login.conf file example:

kerberos-client {

com.sun.security.auth.module.Krb5LoginModule required;

};

kerberos-client-sso {

com.sun.security.auth.module.Krb5LoginModule required

useTicketCache=true

doNotPrompt=true;

};

kerberos-server {

com.sun.security.auth.module.Krb5LoginModule required

useKeyTab=true

keyTab="<cesta ke keytab souboru>"

principal="<Principal služby>" // HTTP/ServerName nebo EGJE/ServerName

storeKey=true

isInitiator=false;

};

2.1.16 OIDC

OIDC (OpenID Connect) authentication is now fully functional for both the Web client and the Java client.

For correct operation, it is necessary to register the EGJE application with the Identity Provider (IdP), such as Microsoft Entra ID or OKTA.

In the EGJE application configuration, the following common items can be set:

o Issuer

§ The URL address of the Identity Provider where the application is registered. This is a mandatory field.

EGJE will attempt to retrieve the so-called Discovery Document from this address and load the required configuration data from it.

o Discovery document

§ If it is not possible to automatically download the Discovery Document from the Identity Provider’s URL, its content can be inserted directly into the configuration file.

o Redirect URI

§ The URL address of the EGJE application to which the user is redirected after successful authentication at the IdP. This address differs for the Web client and the Java client, and it must also be specified in the IdP configuration.

· For Web client: <adresa egjeweb2>/oidc/callback

· For Java client: egjeapp://oidc-callback

o Client ID

§ The Client ID obtained from the IdP, used to identify the application.

o Preferred Username

§ The name of the claim in the ID token that contains the user’s login name (logname) for EGJE. If this field is not specified, the default value preferred_username is used.

o Settings for IdP logout

§ An optional setting. When enabled, EGJE will send a logout request to the IdP after the user logs out. The behavior of this option may differ between clients:

· Web client: Logout must be performed using the logout button. The browser will redirect the user to the IdP, where the logout is processed, and then back to the EGJE logout page.

· Java clinet: On logout or when the application is closed, a logout request is sent to the IdP, and the application is terminated, regardless of the logout status.

Items overriding values from the Discovery Document

. Configuration entries that allow manualy overriding values obtained from the Discovery Document.

o Public keys for signature verification

§ The Discovery Document contains the URL from which the public keys for signature verification can be downloaded. If the server cannot download them automatically, it is possible to download the keys manually and insert them directly into the configuration file.

Settings for individual clients

Further settings and processes differ for each client type.

Web Client

Web client supports 3 OIDC flows modes:

· Authorization Code Flow: After being redirected from the IdP, EGJE exchanges the authorization code for an access token. This process takes place on the EGJE server side, which communicates directly with the IdP server.

· Authorization Code Flow with PKCE: A more secure version of the previous flow with the addition of PKCE (Proof Key for Code Exchange), which prevents misuse of the authorization code.

· Implicit Flow: The access token is returned directly as part of the redirect, in the body of the request (POST). In this case, the EGJE server does not communicate directly with the IdP server..

Additional settings for WEB clinet:

· Client secret: Required for obtaining a token using the Authorization Code Flow.

· The address to which the user is redirected after logout: The address to which the IdP redirects the user after successful logout. Typically, this is set to <egjeweb2 address>/wp/logout.html, but a custom address can also be used. This value must also be specified in the IdP configuration.

Java Client

This client does not have any additional custom settings.

When EGJE is launched, the user’s browser opens the IdP login page.

After successful authentication, the application is redirected back, and the user is given the option to start EGJE from the browser. The EGJE client then downloads the token directly from the IdP server and uses it for authentication.

This process uses the Authorization Code Flow with PKCE, which is the recommended method for native applications. After launching the application, the user must close the empty browser window. The logout process works in a similar way..

2.1.17 SAML

Verification against a server that complies with the SAML2 standard. Authentication settings differ for the Java client and EGJEWEB2.

Glossary of Terms:

SP – Service provider – WEB application EGJE

IdP – Identity provider – trusted system verifying user identity

Metadata – XML file provided by the IdP containing the settings needed for exchanging SAML requests

SP Metadata – XML file generated by EGJE including settings for Idp

SSO – Single Sign On – Single sign-on to multiple Service Providers

SLO – Single Logout – Single logout from both the IdP and all associated Service Providers

jks – Java KeyStore – Storage for saving digital certificates

EGJEWEB2:

In your Identity Provider, you need to configure the endpoint where EgjeWEB will receive the SAML Token. The format of the endpoint is as follows: https://<egjewebURL>/saml/SSO (note that it is case sensitive).

In the Identity Provider, this configuration setting may be labeled as Single-Sign-On URL, Destination URL, or similar, depending on your Identity Provider..

Next, you need to configure the following items in EGJE within the selected SAML authentication:

SP Entity ID: The identifier for your EgjeWEB application chosen by you. This parameter is set within your Identity Provider. The name of this item in the IdP may vary, such as Audience or Audience Restriction, depending on your IdP. Set the corresponding value in the EgjeWEB configuration according to the value you set in the IdP.

IDP SSO URL: The address for initiating automatic login initiated by the IdP. This item is optional; if not set, login for users will use SP (Service Provider) initiated login, i.e., EgjeWEB. Enter the address provided by your IdP here if you will be using IdP-initiated SSO; otherwise, leave it blank. Note that this address is not the address of your EgjeWEB application but the address within the IdP through which you can access the EgjeWEB application via the IdP.

Web Application Address: The external address where the EGJEWEB application is hosted. It should match the address to which the IdP sends the login result, excluding the trailing /saml/SSO.

IDP Metadata: XML document with IdP metadata. This document is provided by your IdP. For ADFS in Elanor, this document can be obtained from the address http://fsso.domena.cz/federationmetadata/2007-06/federationmetadata.xml.

IDP Metadata – Path: URL address to the XML document with IdP metadata. EgjeWEB2 will download the metadata document from this address upon startup.

Metadata Refresh Interval in CRON Format: Interval setting for refreshing the metadata file without needing to restart the application. If needed, you can manually refresh it using the button "Reload SAML Metadata" in Adm51/Správa AS/klienta/Web. There is a button to check the CRON format to ensure it is entered correctly and that the application can read it.

EGJE allows users to specify their own Java Keystore with certificates to be used for encrypting and decrypting SAML Tokens. The keytool utility, which is part of the Java installation, is used to manage the keystore.

In the keystore, you need to generate a key pair, including a private and public key, under some alias. The private key is used by EgjeWEB for decrypting the token that is encrypted by your IdP, while the public key needs to be provided to your IdP. The IdP will use the public key to encrypt the token before sending it to EgjeWEB.

Here is an example command using the keytool utility to generate a key pair:

keytool -genkeypair -alias spring -keypass secret -validity 365 -storepass secret -keystore keystore2.jks -keyalg RSA -keysize 2048

Command above generates a key pair under the alias spring, with the key password secret, keystore password secret, a certificate validity of 365 days, using the RSA encryption algorithm, and a key size of 2048 bits. The keystore will be saved in the file ./keystore2.jks. If the file does not exist, a new one will be created.

You can view the generated certificate in the keystore using the command:

keytool -keystore keystore2.jks -alias spring -list -rfc -storepass secret

Subsequently, you need to paste the displayed certificate into your IdP.

Documentation for the Java Keystore utility in Java 11 can be found here:

https://docs.oracle.com/en/java/javase/11/tools/keytool.html

On the EgjeWEB configuration side, you need to fill in the following items:

Path to the JKS File: Enter the path to the file containing the Java Keystore with certificates for encrypting/decrypting SAML Tokens. This file will be directly included in the configuration JAR. If you make any changes to the keystore, you must upload the file to the configuration again and restart the web server for the changes to take effect in the application. Similarly, you handle the file containing IdP metadata.

Alias for Key: The alias under which the certificate is stored in the keystore.

Keystore Password: The password for the keystore.

Key Password: The password for the private key that will be used to decrypt the SAML Token on the EGJE side.

If you do not wish to encrypt SAML Tokens, you can leave these configuration items blank.

Additional Optional Parameters:

NameID format: It is possible to set the NameID format that will be sent in the SAML AuthnRequest.

Create SP Metadata: Creates an endpoint for generating SP metadata containing the current configuration. The endpoint consists of Web Application Address/saml/metadata.

The Create Metadata button displays the current metadata.

For more details on configuration, see Generating SP Metadata.

Logname element: Sets the attribute from which the login name for signing into EGJE should be retrieved from the SAML Assertion. The default value is Subject/NameID. If AttributeStatement is used, it is necessary to fill in the field “Name of the attribute containing the login name”..

Název attributu obsahujícího logname: Contains the name of the custom attribute included in the “AttributeStatement” element in the SAML Assertion for determining the login name. The value entered should be the name specified in the “Name” attribute within the “Attribute” element.

Always enforce verification on EGJE startup: Adds the parameter forceAuthn=true to the SAML request. When EGJE is reopened, it will always enforce a new authentication with the IdP. The IdP must support and have this parameter enabled. The item name in the IdP may vary, such as "Honor Force Authentication."

Logout from EGJE also logs out from IdP: When logging out from EGJE, a request for Single Logout (SLO) is also sent to the IdP. This logs the user out from the IdP as well as from all currently logged-in Service Providers (SPs) that support this function. The IdP needs to have SLO enabled and configured with the URL: https://<egjewebURL>/logout/saml2/slo (note that it is case sensitive). Additionally, the SP Issuer must be set to the same value as the SP Entity ID.

Log SAML: Enables logging level for SAML libraries to debug. This logs a large amount of data and can make the log file cumbersome. It is recommended to enable this only when troubleshooting SAML authentication issues.

Java client:

In your Identity Provider, you need to configure the endpoint where EGJE client will receive the SAML Token. The format of the endpoint is as follows: http://localhost:<saml_port>/saml/SSO (note that it is case sensitive).

In the Identity Provider, this configuration item may be labeled as Single-Sign-On URL, Destination URL, or similar, depending on your Identity Provider.

Next, you need to configure the following items in EGJE within the selected SAML authentication:

SP Entity ID: The identifier for your EGJE AS application chosen by you. This parameter is configured within your IdP. The item name in the IdP may vary, such as Audience or Audience Restriction, depending on your IdP. Set the corresponding value in the EGJE AS configuration according to the value you set in the IdP.

IDP Metadata: XML document with IdP metadata. This document is provided by your IdP. For ADFS in Elanor, this document can be obtained from the address: http://fsso.domena.cz/federationmetadata/2007-06/federationmetadata.xml

IDP Metadata – Path: URL address to the XML document with IdP metadata. EGJE AS will download the metadata document from this address upon startup.

Metadata Refresh Interval in CRON Format: Interval setting for refreshing the metadata file without needing to restart the AS. There is a button to check the CRON format to ensure it is entered correctly and that the application can read it.

To sign SAML requests, you need to specify a Java Keystore with certificates to be used for encrypting and decrypting SAML Tokens. The keytool utility, which is part of the Java installation, is used to manage the keystore.

In the keystore, you need to generate a key pair, including a private and public key, under some alias. The private key will be used by EGJE AS to decrypt the token encrypted by your IdP, while the public key must be provided to your IdP. The IdP will use the public key to encrypt the token before sending it to EGJE AS. Here is an example command using the keytool utility to generate a key pair:

keytool -genkeypair -alias spring -keypass secret -validity 365 -storepass secret -keystore keystore2.jks -keyalg RSA -keysize 2048

This command generates a key pair under the alias spring, with the key password secret, keystore password secret, a certificate validity of 365 days, using the RSA encryption algorithm, and a key size of 2048 bits. The keystore will be saved in the file ./keystore2.jks. If the file does not exist, a new one will be created.

You can view the generated certificate in the keystore using the command:

keytool -keystore keystore2.jks -alias spring -list -rfc -storepass secret

Subsequently, paste the displayed certificate into your IdP.

Documentation for the Java Keystore utility in Java 11 can be found here:

https://docs.oracle.com/en/java/javase/11/tools/keytool.html

On the EGJE AS configuration side, you need to fill in the following items:

Path to the JKS File: Enter the path to the file containing the Java Keystore with certificates for encrypting/decrypting SAML Tokens. This file will be directly included in the configuration JAR. If you make any changes to the keystore, you must upload the file to the configuration again and restart the AS for the changes to take effect in the application. Similarly, you handle the file containing IdP metadata.

Alias for Key: The alias under which the certificate is stored in the keystore.

Keystore Password: The password for the keystore.

Key Password: The password for the private key that will be used to decrypt the SAML Token on the EGJE side.

If you do not wish to encrypt SAML Tokens, you can leave these configuration items blank.

Port for SSO/SLO: The port number on which the local server listens for redirection to the IdP and back. The specified port must be part of the URL for the SSO and SLO endpoints.

Additional Optional Parameters:

NameID format: It is possible to set the NameID format that will be sent in the SAML AuthnRequest. It is necessary to specify the exact value. If not specified, the default value urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified will be used.

Create SP Metadata: Creates an endpoint for generating SP metadata containing the current configuration. The endpoint is available at:

http://<as_address>:<saml_metadata_port>/saml/metadata

The Create Metadata button displays the current metadata.

For more information on configuration, see Generating SP Metadata.

SP Metadata Generation Port: The port on which the server for generating SP metadata will run.

Always enforce verification on EGJE startup: Adds the parameter forceAuthn=true to the SAML request. When EGJE is restarted, it will always enforce a new authentication with the IdP. The IdP must support and have this parameter enabled. The item name in the IdP may vary, such as "Honor Force Authentication."

Logout from EGJE also logs out from IdP: When logging out from EGJE, a request for Single Logout (SLO) is also sent to the IdP. This logs the user out from the IdP as well as from all currently logged-in Service Providers (SPs) that support this function. The IdP needs to have SLO enabled and configured with the URL: http://localhost:<saml_port>/saml/SLO (note that it is case sensitive). Additionally, the SP Issuer must be set to the same value as the SP Entity ID. To enable logout from the IdP, the keystore for signing SAML tokens must be configured.

Sign SAML SSO Request: Signs the SAML request for login. This is used for IdPs that do not support setting the WantAuthnRequestsSigned attribute in the IdP metadata. To sign the request, the keystore must be configured.

Log SAML: Enables logging level for SAML libraries to debug. This logs a large amount of data, making the log file cumbersome. It is recommended to enable this only when troubleshooting SAML authentication issues.

Generating SP Metadata:

In addition to basic metadata generation, it is possible to parametrically add additional information. To do so, you need to manually edit the config_local.properties file inside the config_egje.jar archive.

These attributes can typically support multiple values — for example, a separate value for each language.

To ensure correct display of Czech characters, the file must be edited using the ISO-8859-1 encoding.

The following areas can be extended:

o UIInfo – The UIInfo element within the Extensions element

§ Used to configure additional information about the launched application.

§ The following elements can be set: Description, DisplayName, InformationUrl.

§ Each element includes a lang attribute specifying the language for which the information is provided.

§ Example configuration in properties:

saml_extensions_uiinfo[0].displayname=EGJE CZ

saml_extensions_uiinfo[0].description=Personálně-mzdový systém

saml_extensions_uiinfo[0].informationurl=https://elanor.cz

saml_extensions_uiinfo[0].lang=cs

o Organization

§ Used to configure additional information about the organization.

§ The following elements can be set: name, displayname, url.

§ Each element includes a lang attribute specifying the language for which the information is provided.

Example configuration in properties:
saml_organization[0].name=Elanor
saml_organization[0].displayname=Elanor
saml_organization[0].url=https://elanor.cz
saml_organization[0].lang=cs

o ContactPerson

§ Used to define a contact person.

§ The following elements can be set: company, given_name, sur_name, email_address, telephone_number.

§ Multiple email addresses and phone numbers can be specified for a contact using indexes.

§ The contactType attribute can be set for the given contact type.

Example configuration in properties:
saml_sp_contact[0].contactType=technical
saml_sp_contact[0].company=Elanor
saml_sp_contact[0].given_name=Guy
saml_sp_contact[0].sur_name=Technical
saml_sp_contact[0].email_address[0]=mailto:technical@example.com
saml_sp_contact[0].telephone_number[0]=+720123456987

2.1.18 NTLogin/2/3 JCifs

NTlogin* authentications without number 2 were canceled in e202409 and from e202411 it is not possible to log in to EGJE using them.

Authentications NTlogin2* are for backwards compatibility. We do not recommend using them.

Authentications NTlogin3* meet safety criteria and are appropriate for Linux OS. These authentications use the newer SMB2 protocol

SSO authentication (NTLogin3 and NTLogin3Only) does not use a secure channel for NETLOGON communication with domain controllers. For proper functionality, it is necessary to use an unsecured Netlogon connection for the service NTLM account, see link: https://support.microsoft.com/en-au/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e#bkmk_thegrouppolicy

We are working on implementing secure communication, and it will be supported in the next version of IS EGJE.

IP addresses of domain controllers (NT login)

IP address of an authentication server for NT login (if there is more they are separated by a comma; the first one , which is running, is used then)

If none is found, then controller from NT login default domain is used.

In practice, there is sometimes convenient to specify a different server than the domain controller that conveys a call on (SSO for Web application and the Windows 2003 domain controller)

NT login default domain fills the value into domain item for NTlogin dialog.

For NTlogin2 you should fill also parameters:

Simple (non-FQDN) hostname of DC host (NT Login2) (domainControllerName)

Computer account for connection to DC (NT Login2) (ntlm2ServerAccount)

Password of computer account (NT Login2) (ntlm2ServerPassword)

More technical information about NTlogin2 you can find with libraries

jespa-1.1.21 Jespa_Operators_Manual.pdf

There is a well-described creation computer account in AD, which is needed for NTlogin2.

Note: EGJE doesn't use Jespo library, so there are no licenses needed.

Briefly, the process of creating computer account into AD is following:

· Create an account with any of the standard utilities (Active Directory Users and Computers (ADUC) MMC Snap-In).

A maximum length is 15 characters from A-Z, a-z, 0-9, '-', '_'

· Set a password - from command line with script

first parameter is the account name followed by @ and $ and DNS domain name and a second is a password

ex. C:\tmp> SetComputerPassword elanor1$@firma.corp password

The password must be different than the name of the account.

Successful implementation indicates the message "The password was set successfully."

2.1.19 smart_card

Authentication is available from e201905 for java client and from e201909 for web client also.

This is a so-called 2-factor authentication, where the login client needs to insert the card into the reader and enter a password that EGJE verifies against the card's certificate.

We have developed and tested the system on a reader and card sold by First Certification Authority (https://www.ica.cz/Order-Hardware, Smart Card Reader GemPC USB-SL, Smart Card Starcos 3.5).

The user registers the certificate using the Opv51 - Personal Certificate form, while the public key itself is stored in a common storage with Opv31 (as uchaz_dok_typ 51 - Personal Certificate I).

This is used for this authentication instead of the standard Adm10 / Logname that uses all other authentication.

For this authentication, there are other parameters in the Smart Card section:

- Certificate Source: combo Smart Card / User Personal Certificates

- Certificate authority: authority certificate in binary format. If filled in, only certificates issued by this authority can be used for authentication.

- The name in the certificate must match the name in the EGJE - checkbox

Name and Last Name Checks - Certificate vs. Osb02.

In EGJEWeb, this authentication works for tomcat + Chrome or EDGE.

It also works in Firefox, but you need to set up the PKCS # 11 module in your configuration.

While here is a pin-off message from Firefox that is a little distant: "Please enter the master password for the 9203050100050786."

An example of tomcat configuration for this authentication:

<Connector port="8548" protocol="HTTP/1.1" SSLEnabled="true"

maxThreads="150" scheme="https" secure="true"

truststoreFile="${catalina.home}/conf/trust.jks" truststorePass="tomcat"

keystoreFile="${catalina.home}/conf/prghr2.pfx" keystorePass="79798796"

keystoreType="pkcs12" keyAlias="{d2046356-d048-4cac-8a82-9f195766c035}"

clientAuth="true" sslProtocol="TLS" />

2.1.20 Data for changing passwords via LDAP and LDAP authentication:

LDAP - SSL URL

address and port of the LDAP server

e.g. ldaps://xxxx:636

respectively address and port and the root under which there are system users (may also exist the child nodes)

e.g ldaps://prgxx1:636/OU=Country.Czech,OU=ElanorUsers,DC=myorg,DC=cz

LDAPSearch - filter

additional filter

typically is used with Novell eDirectory or with Microsoft AD and also in all situations when filter can't be in directly in connection URL

e.g. uid=%username%

resp. (&(objectclass=person)(userPrincipalName=%username%@myorg.cz))

LDAP-specific user to work with LDAP (+ password)

this user is used to log on and browse an LDAP server, respectively for action in the user management Adm12.

user is used for expired password change in AD

usually is fill with domain e.g. ldapadmin@myorg.cz

LDAP / Web - default domain for the user

domain, which is added behind the username when you log in

e.g. myorg.cz

Web - LDAP base with maxPwdAge (change password),

LDAP address to discover the maximum password duration

e.g. dc=myorg,dc=cz

It is a warning before password expiration.

Discovering is functional for LDAPOnly for users with rights to Xpw01.

Note: in EGJE is also password change before expiration - see some lines higher

LDAP / Web - time (days) in advance of the expiration a password

It is a period before password expiration when system achieves the password change dialog (typically for LDAPOnly)

Web - administrator's phone - displayed when the password has expired

Web - administrator's e-mail - displayed when the password has expired

LDAP/ Web - Notice - password does not fulfill the rules

configurable notice for the end user for this situation

Note: Additional parameters for creating users into the LDAP repository (form. Adm12) are parameters Adm21/Configuration parameters / LDAP / AD users creation.

File for requests to reset passwords (full path):

EGJE Web enables the address

http://xxxxxx/egjeweb2/ref/resetpass

to generate a text file with requests to reset a password

This parameter specifies the full path to that file.

(The followup-projection into the Active Directory the application does not solve)

WEB / http address - redirect - user has no profile assigned:

is parameter, used by EGJEWEB in case successful authentication, but current user hasn't assigned rights profile in application by its administrator.

In this case browser redirect user to this address. We consider, there will be information about what to do, whom to contact.

The list of profiles allowed for the WEB.

Parameter can reduce, for this particular EGJEWeb2 installation, list of profiles offered to the employee, manager or referent. It is a regular expression. E.g. MANA. * | EMP. * means that only profiles their codes starting with MANA, or EMP.

Exclude check the e-mail address of the sender

Setting whether to check the formal correctness of the sender's email address (usually personal business e-mail - Osb02)

2.2 Configuration for mobile access

Access from mobile phones / tablets including access outside the intranet or domain may be organized with special installation of EGJEWeb2.

There may be assigned a special authentication "Mobile", but there may be here also other authentication, but the browsers of mobile phones / tablets with mobile user agent always used authentication Mobile. If an administrator at the server enters authentication Mobile other authentication is not allowed. Even PC users are subject to authentication Mobile. Which can be used for some external accesses also from the PCs.

Security of the application in this case has a slightly different structure:

• Here in the Configurator / AS,WEB- Web server mode you can enter the "The list of profiles allowed for the WEB".

For this particular EGJEWeb2 installation a reduced list of profiles is offered to the employee, manager or referent. It is a regular expression. E.g. MANA. * | EMP. * means that only profiles their codes starting with MANA, or EMP.

Note. Restriction applies to the whole EGJEWeb2 also for the access from PC through some other authentication (e.g. mswin_ntlm etc.).

• Adm02 / Mobile authentication allowed – tells which profile is available from your mobile via Mobile authentication (valid for all EGJEWeb2 installation)

• Adm10 / Mobile access permission – tells what person can access the application from his phone / tablet (ie. Using a mobile authentication).

• Adm16 – administrator or manager or other user with the specified mobile profile and permission here (ie as the authenticated user) creates a temporary password used then to create authentication on specific mobile device and in specific browser (attention browser should be in mode "mobile user agent ' ie. not to have eg. in mobile Chrome checked "Request desktop site").

Password you can write directly to your mobile device (button “Show password”), or send it to the email entered a personnel clerk in Osb02 (kind of communication 31) – button "Send via by e-mail."

Note. If the user has multiple mobile devices, or change the device we recommend to write the record these with the name of the device.

• If the user has accessed this e-mail on a mobile device, it is straightforward commissioning. Opens the email application and clicks on a link in the e-mail. One-time password is also in link and it makes mobile device EGJE access operable.

If not, user write the application address in mobile browser and fill the one-time password here.

In both cases it is recommended to create application mobile desktop link from your mobile browser and then run application from it.

• One-time password is temporary, while the generation is entered its validity (usually 10 minutes).

• When a user loses a mobile device, you need from an EGJE as quickly as possible invalidate the access from Adm16 (button “Invalidate access”)!

Alternatively, if a user has multiple devices, and it is not clear which is which, invalidate all respectively admin can cancel in Adm10 mobile access entirely.

• Directly in mobile application user has the settings menu option "Delete mobile access token". After the dialog to make sure is then access from a particular browser particular mobile device invalidated in the same way as of Adm16 “Invalidate access” respectively. deleting whole record with the evidence of access there.

Note.: in Adm21 / Communication parameters is parameter "http (s) EGJEWeb2 address for mobile access:" This address is used in Adm16 during sending your password via email. The email link is composed of this addresses and parameter - one-time password.

Ability to turn off mobile authentication

In the configuration utility Configurator is made in tab AS,WEB- Web server mode parameter (second ranked)

"For mobile device (by user agent) use Mobile authentication" Yes / No

When set to No then from mobile devices, which are reported as a browser

User Agent = mobile, will be called the standard authentication, which is written on the line above this parameter in item authentication.

3 Setting access rights in application

User Assignment / Creation

In situation that person is not in database, we use Adm01p to create it (with status 21).

But users, referents, employees, managers existing in database (usually as employees) don't need other special employment. User's attributes and profiles we set via Adm01 or Adm10 forms.

For a user, we enter his/her profile and language. To "Profil - autentizace" ("Profile – authentication") we enter authentication login name (names):

Authentication Windows NT

WinDomain\user e.g. MOTOR\jigecz

Authentication kerberos, LDAP

user@domain e.g. jigecz@motor.cz

Authentication is taken from operating system (SSO) or is entered interactively (name and password). Modes are described in next chapter.

For each profile assignment we fill in language of user interface.

Note: At state administration we fill in "cs_ST" instead of standard "cs".

Support of English language "en" is currently only partial.

Profile creation and editing

We create and edit profile using form Adm02.

3.1 For each profile, at the first tab we define login type and access rights to lines:

· Login type – to differentiate between personnel and payroll agenda type login to a period

Item also differentiate start date to edit items with time tracking.

Values:

1 Login to date - change time data from 1st this month

2 Login to period - change time data from 1st selected period

3 Login to date - change time data from reference date

4 Login to date - change time data from 1st next months

5 Login to period - change time data from 1 next period

· GUI Type - for what UI is the profile. Values are:

1 - Java and Web client - interface officer

2 - Old Web client

3 - Web client - interface officer

4 - Java client - interface officer

11 - HR portal - interface employee separately sold product

12 - HR portal - interface manager separately sold product

21 - WS Only Without access to EGJE UI, web services access only

Unit of administration (AU, SJ) and Internal Unit (IU, SO) limitations

· SJ (AU) or SO (IU) for limitation of rights – organization is (or may be) divided into administration units (SJ=AU) and administration sections (SO=IU).
AU is an "outwards" division – it partners with various institutions, such as Health insurance companies, Tax Administration Office, etc.
IU is a division used for payroll processing. At IU we define pay days, at IU we make group calculations and balances.
Note: We recommend to fill in AU, IU when are known. It can fit the content of the Combo Boxes more precisely.

· For employee, manager but also for some reference profiles going through the whole organization, filling in AU, IU leads to create profiles separately for each IU.
To avoid this, it is appropriate to set "Yes" in the
"Not filled AU,IU rights take from accessible emp.:" attribute in this case.
Accessible AU, IU (and Legislation) are collected from all accessible employees. These values are then used to restrict values in ComboBoxes with AU, IU.

· Make IU accessible even when unassigned – definition applicable for those PV types, which are not assignable to IU (user, instructor, applicant,…). Selecting "Ano" ("Yes") will make such persons (PVs) visible.
(Assignment of employee to IU is made using Opv01, tab "Správní oddíl" ("Internal unit")).
Note: For payroll reports, this item is not relevant, because in payroll are only employees with IU assigned.

Other conditions for Person and employee access

· Employee row permission mode - evaluation method of account of structures (for PV) – option to enter another additive clause to filter by AU, IU. May have the following values:

VSE	All
STRU	Persons and PV assigned to structure
STRU_PRIMO_HIST	Persons and PV assigned to structure, the access in the whole history, but to the limit of the date of the access to the person.
ST_POD	Persons and PV assigned to structure and substructure
VL_OSO	Own person
ST_MANA	Persons and PV assigned to structure, which is managed by user
ST_MANA_PRIMO	It differs from ST_MANA in this aspect: user has access also to managers of directly subordinated structure items. Usually this is subordinate managers in the organizational structure.
ST_MANA_POD_OBD	It differs from ST_MANA_POD in that it evaluates whether the employee was assigned to the user for at least one day during the period (month).
ST_MANA_OBD	ditto for regime ST_MANA
ST_POD_OBD	ditto for regime ST_POD
STRU_OBD	ditto for regime STRU
ST_KUMUL ST_KUMUL_POD	Installation VŠE can use also these 2 modes. I Adm02 admin set for "Employee - structure type for emp. permission" structure 8; Employee - list of struct. elements for STRU, ST_POD remains empty. It support mode where there are two managers of one employee. There is more centers of structure 8 for one Position (stru 3) in Pmi01. Position works for more centers and 2 managers of structure 8 element now have access to employee sitting on position.

Note: all _OBD rules are valid only for direct structure assignment!
Direct assignment is entered in Opv01/Structures for employee.

Note: for purposes of type *MANA*we consider than manager of non-valid structure is not a manager seeing the subordinate staff.
In other words, we use structure member's Date of termination (Str01) to evaluate the user rights.

· Employee - structure type for emp. permission:
structure type (Str01)

· Employee - list of structure elements for permissions
For STRU, ST_POD and ST_POD_OBD types, the code(s) of structures is/are entered here to make restrictions according to access rights.
Code or codes are entered separated by comma.
If we leave the value blank, the structure (typically a department) where the logged-in user belongs is taken into account.
To specify a negative condition “everything except”, the symbol “!” is placed before the list - see the paragraph below.

For ST_MANA, ST_MANA_POD, ST_MANA_PRIMO, ST_MANA_OBD, ST_MANA_POD_OBD value should be blank and it means the structure items where the user is the manager.

For VSE, VL_OSO, ST_MANA, ST_MANA_POD, ST_MANA_PRIMO, ST_MANA_OBD, ST_MANA_POD_OBD this item is inapplicable.

· ST_MANA * rights in full access history:
The flag is used for payroll clerks. Their work is annual.
The Yes setting gives to the clerk access to employees who have accessible at least one day in the current year.

This mode is available only for ST_MANA*. In other cases this is not supported.

· Employee - give access also to non-assigned – definition applicable for those PV types, which are not assignable to structure (user, instructor, applicant,…). Selecting "Ano" ("Yes") will make such persons (PVs) visible.
(Assignment of PV to structure is made using Opv01, tab "Zařazení do struktur" ("Assignment to structures")).

· Employee allowed emp. status list:
additive definition of rights based on account of the item Opv01/Popis(Description)/Status of relationship person-org.
Common value for e.g. payroll clerks is restriction 1,2 (i.e. the counted ones) resp. 1,2,3

· Employee allowed emp.right status list:
additive definition of rights based on account of the item Opv01/Popis(Description)/Status - rights. Unlike previous item where the codetable is administered by Elanor, for this item is codetable in the administration by user (Jpc01 / status_prava). To specify a negative condition “everything except”, the symbol “!” is placed before the list - see the paragraph below.

· Employee - access of protected persons – additive definition based on attribute, which the administrator may assign to a person – PV – at Adm11 / PV / Chráněná osoba (Protected person).

All conditions are evaluated as "AND". Therefore, setting multiple conditions typically results in higher level of restriction.

Own line rights evaluation:

In most application locations, access rights to lines are evaluated from ongoing master data.

From Opv01 form (Duration, Description, Structure), Str01 (Hierarchy from-to, Other Structures, Manager - EGJE Person).

To view data from payroll however, EGJE is based on data of structures copied into payroll each month.

So: Vyp02 / Copies of Structures (according to Str01 / Structure Use = 1-MZDY), Vyp01 (calculation), Str05.

These are the following reports: Aps03, Coe01, Coe05, Con24, Dan16, Evs15, Kon14, Poj02, Poj05, Poj07, Poj10, Poj32, Poj34, Poj41, Pos02, Pos32, Rek02p, Rek05p, Rek11, Rek12, Rek22, Rek23, Rek24, Rek25, Rek26, Sra03, Sra04, Sra06, Sra08, Vyk27, Vyk32, Vyk33, Vyp14, Vyp17, Vyp19, Vyp20, Vyp21, Vyp24.

Plus forms Vyp07, Vst01h, Slm05.

Permissions to assign

· Employee -list of structure types - can set:
if empty - all types; otherwise list of types (from Str01 navigation) which user can assign to employee (Opv01, Opv04, Opv05)

· Preferred navigation list of Employees
Administrator can set default navigation list for forms with this navigation (e.g. Osb02, Opv01, Vyp01, Kva01, Dav01...)

Rights for rows - other objects
(groups of row level rights system is described in Adm_uzdoc - Chapter Adm06)

· Codetable’s rights by groups - the user will see (usually in the combobox) only the values of the codetable, which are marked with this group. (comma separated list , or list of intervals. Interval is with minus separator. E.g. 1,7-9,23-26,29, To specify a negative condition “everything except”, the symbol “!” is placed before the list - see the paragraph below.

· Add own group from Org.str. - Added to the groups in the previous row still have a group that is listed in the organizational center, which the user is assigned (“his” group).

· Codetable’s editing rights by groups - for users who edit codetables - there must be a list of all the groups, which user is able to see and edit (when empty user just sees the lines without marking group).
To specify a negative condition “everything except”, the symbol “!” is placed before the list - see the paragraph below.

· Add own group from Org.str.-edit - adds “his” group to previous row

· Structure codetable rights (list of str. types) - a list of types of structures (navigation Str01), the user can edit. E.g. 2, 3 causes the user in Str01 see and can edit only the organizational structure (2) and positions (3).
This can be combined with restrictions “Codetable’s editing rights by groups” (using the previous two parameters)

· Positions - row rights by organizational structure

Set to Yes causes the navigation list positions (Pm), will be only the positions, which is in organizational centers for which the user has access (assuming the definition of rights according to the organizational structure). The navigation list is used in e.g. Pmi01, Pmi08, and Pmi09.

If the item is not filled, the restriction is not applied.

· Document types (Opv31, Rea0x) - list:

Admin can set here the list of (employee or applicant) document types accessible to read and write to the user.
To specify a negative condition “everything except”, the symbol “!” is placed before the list - see the paragraph below.

· Document read-only types (Opv31, Rea0x) - list:

Admin can set here the list of (employee or applicant) document types accessible to read to the user.
To specify a negative condition “everything except”, the symbol “!” is placed before the list - see the paragraph below.

· List of types of communication contacts (Pkz01, Osb01/2) – similarly, a list of type numbers is entered, including a negative list initiated by the symbol “!”..

Access to Applicants - navigation

· RECRU - status list - navigation
The option to limit the displayed list of applicants by specifying statuses (comma-separated numerical values of the applicant's status). This also applies to statuses.Access to Applicants - workflow restrictions

· RECRU - status list - can set:
possibility to reduce status values which user can set

Attendance - definition of user level verification for attendance area

· Attendance edit level - verification and editing the profile level to control the permission to access the rows in the attendance records (daily and monthly attendance data).

The levels available are:

3 Employee; 13 Leader I.; 23 Director, Manager or 33. payroll clerk

Logs display mode (Attendance)

1 - Standard (popup)

2 - Suppress the log display in dialog

3 - EGJEWEB - log display in EGJE tab (in std. client equals to 1)

Typical usage is the fullscreen mode of terms with EGJEWEB.

Not filled AU, IU rights take from accessible employees

Manager/employee profile is usually one, common for whole organization. There aren't modifications for different AU, IU. Switch this attribute causes the online recalculation of sets of accessible AU, IU immediately after login. Source is AU, IU of accessible employees.

These rights are typically used for comboboxes in report parameters and forms also.

Default is this switch off.

Recommended and usual profiles

In table are only attributes different from default values for Adm02/New profile.

Type	Description
Employee	AU, IU not filled. Not filled AU,IU rights take from accessible emp.= Yes Employee - row permission mode = VL_OSO
Manager - persons from managed structures	AU, IU not filled. Not filled AU,IU rights take from accessible emp.= Yes Employee - row permission mode = ST_MANA Employee - structure type for emp. permission = 2 (org. structure usually) Note. For each structure 2 record manager should be filled (Str01, Str02 / Manager - person in EGJE) Own person accessibility depends on "Employee - access of protected persons" content.
Manager - ditto + managers of subordinate centers	ditto Employee - row permission mode = ST_MANA_PRIMO
Manager - all subordinates	ditto Employee - row permission mode = ST_MANA_POD
Manager, referent (person in EGJE) - persons from structure onto which is he assigned.	AU, IU not filled. Not filled AU,IU rights take from accessible emp.= Yes Employee - row permission mode = STRU (resp. ST_POD for all from subordinates centers) Employee - structure type for emp. permission = 2 (org. structure usually but also others) Employee - list of struct. elements for STRU, ST_POD = not filled
Referent payroll clerk - whole IU	AU, IU filled (lists can be) Employee - row permission mode = VSE
Referent payroll clerk - assigned employees	AU, IU filled if constant (lists can be) Employee - row permission mode = ST_MANA Employee - structure type for emp. permission = 14 - Payroll clerk Note. For each payroll clerk (part of structure 14) should be filled assignment to person/user - Str01, Str02 / Manager - person in EGJE. So one profile can be used for more payroll clerks, but each has her own employees. Employees can be assigned to payroll clerk (structure 14) on employment - Opv01 / Structrures on position - Pmi01, Str01, Str02 on organization center - Str01, Str02 For this referent type you should set the flag "ST_MANA* modes in access whole history mode:" Yes, and make accessible the employees date from the period before the referent entered the organization (Opv01 Emp. starting date).
Other referent - assigned employees	ditto payroll clerk - only the nr. of structure is different. typically 15 - 18 resp. 13

Advantage of ST_MANA usage for referents is common profile for all (or for group) referents of one type.

To this profile you can join other configuration:

· Adm06 - groups of row level rights - general groups, wage code groups, calendar groups

· Epr02 - eProposal

· Adm02 - role assigned to profile

· Mail - send message to all on profile

When each referent has own profile, these configurations should be filled separately to each profile. It is a lot of work and it is confusing.

Typically this referent has:

AU, IU filled (lists can be)
Employee - row permission mode = STRU

Employee - structure type for emp. permission = 13-18

Employee - list of struct. elements for STRU, ST_POD

= list of user codes from the structure - comma separated

How to configure structures to be usable for access rights by structures (ie, ST * modes).

On Str01 you need to set:

Relations to the other structures:

If the structure is specified on Position, then

"Subordinate Structure (Fill In Where)" will be 3 - Position

and "Superior (fill in What)" will be eg 14 - Payroll clerk

If I enter the data on the Organizational Center, then "Subordinate" will be
2 - Organizational structure.

If you enter for an employee (Opv01 / Structure), then in the "Structure usage" tab, enter 2-PERSONAL DATA for that specific structure (eg 14 – Payroll clerk).

Note: If only any user can assign this structure to Opv01 / Structures, it is possible to set on the other profile the write permission - Adm02 / "Employee – list of structure types – can set:". Admin writes a list of structure types without this structure here.

The principles of indirect assignment are applied on the structures.
So, I can fill the most common value on the organizational center (such as the Payroll clerk) into Str01 / Stru / "Manager / Person in EGJE", then fill the deviations on Position or directly to the employee.

Thus, it is possible to minimize the number of places where the data is filled.

For ST_MANA* rights used for referents, it is possible to address the situation, where there are more equal referents for the same group of persons / employees. In that case, a checkbox (eg for structure 14) is checked in Str01 / Name of structure and levels / "Simultaneously may be more managers / people:".

Then, in Str01 / Stru / / "Manager - Person in EGJE" you can enter more than one parallel referents.

However, this mode should not be used for the structures used for approval (Adm14 workflow), so it is not suitable for the structure 2, that is used for approval mostly.

Negative definition of access to Persons and Employees

From e201809, in addition to the standard assignment, "All who have something" can give access rights to lines (ie. persons and employees) negatively, "everyone except those who have something."

It makes this an easy alternative to " Employee - access of protected persons" using the Adm11 / Emp. / "Protected employee" attribute.

We all allow you to specify for:

• Employee - allowed emp. rights status list

• Employee - list of struct. elements for STRU, ST_POD (just for these 2 modes)

• Codetable's rights by groups

• Codetable's editing rights by groups

• Document types (Opv31, Rea0x) – list. Read and write.

• List of types of commun. contacts (Pkz01, Osb01/2)

Negative list is entered by entering the "!" character into the first character of the value entry.

Thus, for example, if you enter the value of "!5" for " Employee - allowed emp. rights status list" then those employees, that do not have the value "5" in the Opv01 / Description / Status - rights, will be accessible.

The "!" sign is functional just at the place of the first character and says everything behind will be evaluated negatively. Therefore, it is not possible to combine positive and negative processing within one item.

Alternative evaluation of rights to Persons and Employees (row rights)

In larger databases there is often (by manager’s and referent’s access) very long opening the windows (because of loading navigator’s lists and lists in combo boxes). From e202109 we provide the resolution, which make partly offline and which speed up this loading (the first opening of windows the type of Wflow, Epr01, Kva01).

Putting into service is optional and it contains more related steps:

· on the profile there is configured, that the profile is in the area of row rights evaluated by the offline copies of dates: Adm02 / PV – rights fo profile rows through Elis51:Yes

· the offline’s rights are generated by processing report Elis 51. You configure on Adm53 its starting – you start it one a day – typically in the mornng or in the night.

The report includes these parametres:

! Common codetable of structures - hierarchic

! Emp. assignment to structures

! Managers of structures

! Competences on the structures

For purposes of offline rights is needed to configure the first two parametres. On Elis51 there are checkboxes, on Adm53 by the parametres r_FillDataCstr, r_FillDataTpvStr

you set „1“, the next two (for function rights) you can set „0“.

It is to consider, in which profiles you set the offline evaluation – primarily, it is given for manager’s and referent’s profiles with the rights over the structures (ST*). It is possible to try it. The rights are evaluated in time of starting, as the case may be time of finishing the report Elis51. More often starting (more than once or twice a day) can causes capability problems, but on principle it can be.

On Adm10 there is a flat Structures offline, there are the first two offline disposal sites. There is also online view to records of assigning of managers’s structures on the flat. Here are used online values, i.e. those, which are also on Str01, Str02 / „Manager/Person in EGJE“ (from the another view).

Adm01 / Accessible Employees show the result i.e. which persons / Employees will user have on his profile accessible.

Role creation and editing

We create and edit role using form Adm03.

Roles numbered 1-499 are administered by Elanor and are not editable by user.

Reserved interval for user roles is 500-999.

It is quite commonly used that user has in his/her profile assigned certain standard Elanor role(s) (1-499) and the administrator, in addition, assigns to him/her some role(s) above 500 where the administrator adds or restricts rights to standard roles. Restriction is made by setting a negative value of the right in user role. It means that e.g. assignment of the right ‑2 Restrict read and write will cause that rights assigned in the standard role of such user will no longer be valid.

We assign the rights at tab "Práva k objektům" ("Rights to objects"). And here, on the tab "Objekt" ("Object") we set "Souhrnná hodnota přístupového práva" ("Access right summary value"). For forms double-level (0 no rights / 1 read / read and write), for reports and processes single-level (0 execution disabled / 1 execution enabled). Normally, this is sufficient. Please note that the "Summary value of access right" should contain a maximum of reights eventually assigned to child objects.

If necessary, some forms in section "Podřízené objekty – editace" ("Subordinate objects - edit") allow to set rights also for more detailed parts of a form (bookmark, data form, item). Here, the rights are set as a cascade in this order, i.e. from rough to fine. Evaluation then continues in this hierarchy as long as there's any right applicable ( > 0) up to the level "item". To distinguish code name of the form’s component admin can run command line parameter “-edit” (e.g. Opv01 -edit ). Form is then opened with component names.

This procedure is used to assign bulk change permissions also.

The default mode is that the user has accessible all sections of the form except that it revokes using either administrator rights (Adm03), or through configuration (Adm04)

However, the system also allows from e201303 version modes 1 and 2. Their choice is made in Adm03 item "Rights inside the form - mode" with values:

0 - Standard - by rights type (revoking mode)

1 - Adding mode (tabs, data forms), revoking mode (fields)

2 - Adding mode (tabs, data forms and fields)

Where 0 is the default value and indicate the standard mode.

Mode 1 means that the administrator enumerates open tabs and data forms, while data entry forms are available all resp. those not prohibited.

In mode 2 also items should be enumerated. Please note that if you want the user with write access, it is necessary to assign all required fields (indicated by an exclamation mark before the title) and items that are for internal logic and any checks necessary.

Please note that some of the forms may have mandatory controls, without which the form is not functional, eventually. it does not display data.

Setting is therefore sensitive thing. It can be helpful for admin to display the form (in the standard client) from the command line with the -edit parameter. Here he sees the names of internal parts of the form and then he can easier orient in the tab Child Objects.

For your convenience, we have made for the new mode automatic accessibility for panels, which are also is stored in the internal structure of the form.

The selected configuration is always necessary to test. We cannot guarantee that all preset rights configurations will be operational by your expectation.

The user may have the rights to form via multiple roles, including child objects:

From e201601 we modified the processing logic of the situation.

Before e201601 had explicitly specified rights on the child object precedence over the rights inherited from the parent element.

From e201601 are both equal. User has inherited rights when they are higher than explicitly specified rights.

In practice, it was usually on the evaluation of the rights to the item, when in one role were rights to read any specific items (whether it was in any of the modes ' Rights inside the form - mode:" see above) and in the second role was the right to write to whole tab.
Before e201601 evaluation result was user can reader only read.

Since e201601 evaluation result is user can write - inherited rights defined on the whole tab are used.

Since e201605 we handle situations Master table + multiple detail tabs, and one of them is the main via which user updates also the master table data.

The master-detail handles this main detail component rights. If the user has rights to it only for reading a Master-Detail will also be read-only. The rights does not inherit to any other detail tabs. These tabs inherits only rights from the entire Master-Detail.

Therefore, to set the user rights to write on Str01 / Hierarchical structure / Manager, you set write rights to MasterDetail (ZalStrHier), and reading rights to Detail (ZalStrHierDetail) and write rights to the Manager tab (cecstrmanaPan).

NB. MasterDetail (ZalStrHier), may also inherit rights from tab Hierarchical structure (ZalStrHierPanel).

4 Note

List of available parts of documentation you may find here.