V zásadě se dělí na interaktivní (uživatele zadává jméno a heslo) a SSO (Single Sign On, aplikace se snaží převzít ověření z již provedené autentizace v OS). Možná je i kombinace, kdy aplikace zkusí SSO a když se nepovede, nabídne uživateli interaktivní autentizaci.

EGJE nechává autentizaci uživatelů na externí autoritě, tzv. Identity Provideru (IdP). S tímto IdP komunikuje prostřednictvím well-know protokolů, v tuto chvíli EGJE podporuje z těchto protokolů LDAP, NTLM, Kerberos, SAML, OIDC (viz dále v textu). EGJE od této autority očekává zajištění ověření identity v souladu s platnou legislativou (v CZ je to pro režim nižších povinností Vyhláška č. 410/2025 Sb., v SK Vyhláška č. 227/2025 Z. z.)

Poznámka 1: Doporučujeme nepoužívat Windows účty s diakritikou.

Poznámka 2: Pracujeme-li s aplikačním serverem, je vyplnění této záložky důležité na aplikačním serveru (na klientu je bezpředmětné).

Po provedení změn na této záložce je potřeba restartovat AS resp. WEB EGJE server.

V konfigurátoru na záložce Ověření se dynamicky zobrazují údaje potřebné pro zadání autentizace a to dle vybraného druhu z číselníku. Dle vybrané položky se interaktivně zobrazí formulář s potřebnými údaji. Protože je třeba (bez ohledu na typ autentizace) v některých případech zadat LDAP autentizaci (pro umožnění práce s různými sestavami a formuláři), je zde nastavení LDAP autentizace zakotvena i pro všechny typy autentizace.

Na záložce AS/WEB, v rámci režimu Web server lze definovat Konfiguraci pro mobilní přístup a nastavení parametrů, např. http adresa pro přesměrování uživatele, pokud nemá žádný přiřazený profil nebo např. výčet profilů povolených pro Web apod.

2.1 Ověření - zvolený autentizační mechanismus.

2.1.1 mswin_ntlm

Realizováno pomocí Microsoft security package.

Umožňuje SSO (převzetí autentizace od OS) ale pouze pro MS Windows

(u instalace s AS/Web server platí podmínka OS Windows i pro ně)Nevyžaduje žádné další parametry.

AS/Web server musí běžet pod uživatelem z domény.

Nastavení u klienta AS - server je nutné zadávat jménem a nikoliv IP adresou.

Lze použít pro java klienta bez AS.Nepodaří-li se SSO přihlášení následuje autentizační dialog (s doménou).

2.1.2 mswin_ntlmOnly

Nepodaří-li se SSO následuje ukončení aplikace

2.1.3 mswin_ntlmInteractive

Vždy autentizační dialog.

2.1.4 mswin_kerberos

Realizováno pomocí Microsoft security package.

Přísnější autentizace, která zkusí nejprve autentizační protokol kerberos.

SSO jako mswin_ntlm.

Vyžaduje u domény nastavený service principal name SPN (utilita setspn) pro aplikaci a uživatele:

§ utilita setspn (u windows serveru 2003 ji případně doinstalujte z instalačního CD)

§ setspn.exe -A principal účet

kde principal je

HTTP/ServerName pro EGJEWEB,

EGJE/ServerName pro AS

účet účet pod kterým běží AS resp. EGJEWEB

AS/Web server musí běžet pod uživatelem z domény.

Nastavení u klienta AS - server je nutné zadávat jménem a nikoliv IP adresou.

Nepodaří-li se SSO přihlášení následuje autentizační dialog (s doménou).

2.1.5 mswin_kerberosOnly

Nepodaří-li se SSO následuje ukončení aplikace

2.1.6 NTLogin2

autentizace uživatele se přebírá z NT autentizace Windows.
pokud se nepřevezme z OS, přejde systém do režimu NTLoginInteractive

2.1.7 NTLogin2Only

dtto s tím, že je umožněno pouze převzetí přihlášení z OS

2.1.8 NTLoginInternactive s autentizačním dialogem

pokud je server linux a ověření má být SSO vůči AD, je možné použít tyto autentizace, zvládají protokol NTLM2.

K jejich použití je potřeba vyplnit parametry - viz odstavec NTLogin/2 JCifs

2.1.9 NTLogin3

jako NTLogin2 ale umožňuje použít novější SMB2 protokol

2.1.10 NTLogin3Only

dtto s tím, že je umožněno pouze převzetí přihlášení z OS

2.1.11 NTLogin3Internactive s autentizačním dialogem

2.1.12 LDAPOnly

Aplikace vůči ldap serveru (obvykle MS Active directory položka userPrincipalName).
Do položky LDAP/Web - implicitní doména uživatele se pak zadává doména (tj. to co je v userPrincipalName za znakem @ - uživatel to pak nemusí zadávat).

V tomto režimu podporujeme pouze SSL připojení.

2.1.13 LDAPSearch

podobné LDAP Only s tím, že ve LDAP SSL URL je ještě navíc makro pro přihlášení se jménem tedy
např. Ldaps://xxxxxxx/dc=yyy,dc=cz
popis formátu viz http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/url.html

Pozn. filtr zadávejte samostatně do specializované položky LDAPSearch - filter.

a navíc mohou být vyplněny položky:

LDAP - uživatel s právy na čtení

LDAP - heslo uživatele s právy na čtení

přes tohoto uživatele se pak aplikace připojí, prohledá celý podstrom a vyhledá se v něm autenizující se uživatel.
Pokud ldap server umožňuje anonymního uživatele, je možné položky nechat prázdné.

LDAPSearch - filter - Filtr, uplatněný po přihlášení k LDAP serveru

(nutný pro Novell eDirectory)

např. uid=%username%

LDAPSearch – Atribut unikátní identity uživatele – Atribut v AD specifikující hodnotu logname přihlašovaného uživatele. V případě nevyplnění je jako logname v rámci EGJE použita hodnota DN (Distinguished Name). Hodnota tohoto atributu, v případě jeho vyplnění, musí korespondovat s makrem %username% uvedeným v rámci konfigurační položky LDAPSearch – filtr. Př. Nastavení LDAPSearch – filtr: (&(objectClass=person)(employeeNumber=%username%)), LDAPSearch – Atribut unikátní identity uživatele: employeeNumber

2.1.14 Kerberos

Oproti mswin_kerberos zde může být AS/Web na Linux serveru. Existují dva typy autentizace:

· kerberos – pouze interaktívní

· kerberos_sso – nejprve SSO, pokud se nepovede tak interaktivní

Pro obě autentizace je potřeba nastavit krb5.conf soubor (konfigurace realms). U této autentizace je důležité nastavení DNS. U ověřování Linux vůči Active Directory je vhodně, aby přimární DNS server byl doménový řadič Active Directory.

Pokud je zapotřebí, lze povolit starší a míň bezpečnou šifru rc4-hmac. Do [libdefault] v krb5.conf souboru vložit allow_weak_crypto = true a přidat šifru do povoleného výčtu. Nicméně z bezpečnostních důvodů se toto nedoporučuje.

Pokud se nepovolí, může být zapotřebí pro daný účet povolit novější a bezpečnější AES šifry.

Nastavuje se pomocí Group Policy pro Default Domain Policy a Domain Controllers Policy. V Group Policy Management se pro každou nastaví v Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Security Options v Policy Netvork security: Configure encryption types allowed for Kerberos v properties:

· zaškrtnout Define these policy settings

· zaškrtnout jednotlivé požadované šifry (doporučené AES)

Dál je třeba povolit AES šifry pro Kerberos pro servisní účet. Ve vlastnostech účtu v Accounts->Accounts options zaškrtnout položky This account supports Kerberos AES XXX bit encryption.

Po nastavení bude zapotřebí změnit heslo a případně vygenerovat nový keytab soubor viz dále.

Příklad souboru krb5.conf:

[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

Nastavení u klienta AS - server je nutné zadávat jménem a nikoliv IP adresou.

Pro Java klienta bez AS není režim vhodný.

Nepodaří-li se SSO přihlášení následuje autentizační dialog.

Je zapotřebí vytvoříš si v AD servisní účet pro preautentizaci. K němu je zapotřebí vytvořit Service principal name (SPN).

Vytváří se pomocí utilitky setspn:

setspn.exe -A <principal> <účet>

kde principal je

· HTTP/ServerName pro EGJEWEB,

· EGJE/ServerName pro AS

účet - účet pod kterým běží AS resp. EGJEWEB

Pro úspěšné SSO přihlášení je možné zvolit jedno ze dvou nastavení.

Uživatel pro preautentizace: Vyplní se Uživatel pro preautentizaci a jeho heslo. Tento způsob není doporučený na produkčním prostředí.

Keytab soubor: Vytvoří se login.conf soubor, který bude obsahovat cestu ke keytab souboru a Principala služby registrovaného účtu v položce principal. Doporučovaný způsob pro produkční prostředí. Názvy sekcí musí zůstat, jak jsou definovány v příkladu. Práva ke keytab souboru by měl mít uživatel pod kterým se Aplikační nebo Webový server spouští.

Keytab soubor se vygeneruje v DC pomocí utilitky ktpass:

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

kde filename.keytab je místo kam se soubor vygeneruje

principal:

· HTTP/ServerName pro EGJEWEB,

· EGJE/ServerName pro AS

realm - zadaná realm v krb5.conf

doména - vaše doména

účet – servisní účet

heslo - heslo k servisnímu účtu

Pokud je zapotřebí mít pod stejným účtem více služeb (např. EGJEWEB i AS), je možné přidat do existujícího keytab souboru heslo pro další účet. Po vytvoření SPN se zavolá příkaz pro generování keytab souboru kde se mu jako parameter předá původně vygenerovaný keytab soubor:

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

Příklad souboru login.conf:

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

Autentizace OIDC (OpenID Connect) je nyní plně funkční pro webového i Java klienta. Pro její správné fungování je nezbytná registrace aplikace EGJE u poskytovatele identity (Identity Provider – IdP), například Microsoft Entra ID, OKTA.

V konfiguraci aplikace EGJE lze nastavit následující společné položky:

o Vydavatel (Issuer)

§ URL adresa poskytovatele identity, která obsahuje registrovanou aplikaci. Jedná se o povinnou položku. EGJE se pokusí z této adresy stáhnout tzv. Discovery document a načíst z něj potřebná data.

o Discovery document

§ Pokud není možné automaticky stáhnout Discovery document z URL poskytovatele, je možné jeho obsah vložit přímo do konfiguračního souboru.

o Adresa pro přesměrování (Redirect URI)

§ URL adresa aplikace EGJE, na kterou proběhne přesměrování po úspěšné autentizaci v IdP. Tato adresa se liší pro webového a Java klienta a musí být uvedena i v konfiguraci IdP.

· Pro Web klienta: <adresa egjeweb2>/oidc/callback

· Pro Java klienta: egjeapp://oidc-callback

o Client ID

§ Klientské ID získané od IdP, sloužící k identifikaci aplikace.

o Preferované uživatelské jméno (Preferred Username)

§ Název claimu v ID tokenu, který obsahuje přihlašovací jméno uživatele (logname) pro EGJE. Pokud není vyplněn, použije se výchozí hodnota preferred_username.

o Nastavení pro odhlášení z IdP

§ Volitelná položka. Při jejím zaškrtnutí odešle EGJE po odhlášení požadavek na odhlášení i do IdP. Chování se liší mezi klienty:

· Web klient: Odhlášení musí být provedeno tlačítkem. Prohlížeč přesměruje uživatele do IdP, kde proběhne odhlášení, a poté zpět na odhlašovací stránku EGJE.

· Java klient: Při odhlášení nebo zavření aplikace je požadavek odeslán do IdP a aplikace se ukončí, bez ohledu na stav odhlašování.

Položky přepisující hodnoty z Discovery documentuy

Tyto položky umožňují ručně přepsat hodnoty, které EGJE automaticky stáhne z Discovery documentu.

o Veřejné klíče pro ověření podpisů (Public Keys)

§ Discovery document obsahuje URL, odkud lze stáhnout veřejné klíče pro ověření podpisů. Pokud je server nemůže stáhnout, je možné je stáhnout ručně a vložit přímo do konfiguračního souboru.

Nastavení pro jednotlivé klienty

Další nastavení a procesy se liší pro každý typ klienta.

Web Klient

Webový klient podporuje tři režimy OIDC toku:

· Authorization Code Flow: Po přesměrování z IdP si EGJE vymění autorizační kód za přístupový token. Tento proces probíhá na straně serveru EGJE, který komunikuje přímo s IdP serverem.

· Authorization Code Flow with PKCE: Bezpečnější verze předchozího toku s přidáním klíče PKCE (Proof Key for Code Exchange), který brání zneužití autorizačního kódu.

· Implicit Flow: Přístupový token je vrácen přímo v rámci přesměrování (redirect) v těle požadavku (POST). EGJE server v tomto případě nekomunikuje přímo s IdP serverem.

Doplňková nastavení pro Web klienta:

· Client secret: Nutné pro získání tokenu pomocí Authorization Code Flow.

· Adresa pro přesměrování po odhlášení (Post-logout Redirect URI): Adresa, na kterou IdP přesměruje uživatele po úspěšném odhlášení. Typicky se vyplní <adresa egjeweb2>/wp/logout.html, ale lze použít i vlastní adresu. Tato hodnota musí být také vyplněna v IdP.

Java Klient

Tento klient nemá žádná vlastní dodatečná nastavení. Při spuštění EGJE se uživateli v prohlížeči otevře přihlašovací stránka IdP. Po úspěšné autentizaci je aplikace přesměrována zpět a uživateli je nabídnuta možnost spustit EGJE z prohlížeče. Poté si klient EGJE stáhne token přímo ze serveru IdP a použije ho pro autentizaci.

Tento proces využívá Authorization Code Flow with PKCE, což je doporučený způsob pro nativní aplikace. Po spuštění aplikace musí uživatel prázdnou stránku v prohlížeči zavřít. Podobně funguje i proces odhlášení.

2.1.17 SAML

Ověření vůči serveru splňujícímu standard SAML2. Nastavení autentizace se liší pro Java klienta a EGJEWEB2.

Slovník pojmů:

SP – Service provider – webová aplikace EGJE

IdP – Identity provider – důvěryhodný systém ověřující identitu uživatele

Metadata – XML soubor dodaný IdP obsahující nastavení potřebné pro výměnu SAML requestů

SP Metadata - XML soubor generovaný EGJE, obsahující nastavení pro dodání do IdP

SSO – Single Sign On – jednotné přihlášení do více SP

SLO – Single Logout – jednotné odhlášení i IdP a všech podporujících SP

jks – Java KeyStore – uložiště pro ukládání digitálních certifikátů

EGJEWEB2:

Ve Vašem Identity Provideru je potřeba nastavit koncový endpoint, na kterém EgjeWEB přijme SAML Token. Tvar endpointu je následující: https://<egjewebURL>/saml/SSO (pozor, je to case sensitive).

V Identity Provideru může být tato konfigurační položka označena jako Single-Sign-On URL, Destination URL, záleží na Vašem Identity Provideru.

Dále pak je potřeba v konfiguraci EGJE nastavit v rámci zvolené autentizace SAML následující položky:

SP Entity ID: Vámi zvolený identifikátor Vaší aplikace EgjeWEB. Parametr nastavujete v rámci Vašeho Identity Providera. Název položky v IdP se může lišit, např. Audience nebo Audience Restriction. Záleží na Vašem IdP. Podle hodnoty, kterou nastavíte v IdP, nastavte pak odpovídající hodnotu i v konfiguraci EgjeWEB.

IDP SSO URL: Adresa pro zahájení automatického přihlášení iniciovaného ze strany IdP. Položka je nepovinná, pokud nebude nastavena, pro přihlášení uživatelů bude použito přihlášení iniciované ze strany SP (Service Providera) neboli EgjeWEBu. Nastavte zde tedy adresu aplikace, kterou Vám musí dodat Váš IdP, pokud budete aplikovat SSO iniciované Vaším IdP, v opačném případě ponechte prázdné. Pozor, adresou aplikace se zde nemyslí adresa Vaší aplikace EgjeWEB, ale adresa v rámci IdP, přes kterou je možné se na aplikaci EgjeWEB prostřednictvím IdP dostat.

Adresa Web aplikace: Externí adresa, na které je provozována aplikace EgjeWEB, měla by se shodovat s adresou, na kterou IdP zasílá výsledek přihlášení, bez koncového /saml/SSO

IDP metadata: XML dokument s metadaty IdP. Dokument Vám vydá Váš IdP. Pro ADFS v Elanoru je tento dokument možné získat z adresy http://fsso.domena.cz/federationmetadata/2007-06/federationmetadata.xml

IDP metadata – cesta: URL adresa ke XML dokumentu s metadaty IdP. Z této adresy si EgjeWEB2 při spuštění stáhne dokument s metadaty.

Interval pro obnovu metadat v CRON formátu: Interval nastavující obnovu souboru s metadaty bez nutnosti restartu aplikace. V případě potřeby lze obnovu provést u ručně na Adm51/Správa AS/klienta/Web tlačítkem Přenačíst SAML metadata.

U parametru je tlačítko na kontrolu CRON formátu zda je zadaný správně a aplikace ho dokáže přečíst.

EGJE umožňuje uživatelům specifikovat si vlastní Java Keystore s certifikáty, které se použijí pro šifrování, resp. dešifrování SAML Tokenů. Pro manipulaci s keystorem se používá utilita keytool, která je součástí používané Javy.

Do keystoru je nutné pod nějakým aliasem vygenerovat pár klíčů, privátní a veřejný. Privátní klíč použije EgjeWEB pro dešifrování tokenu, který je zašifrován Vaším IdP, veřejný klíč je nutné předat Vašemu IdP. IdP použije veřejný klíč pro zašifrování Tokenu před odesláním tokenu do Egjewebu. Příklad použití utility keytool pro vygenerování páru klíčů:

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

Výše uvedený příkaz vygeneruje pár klíčů pod aliasem spring, heslo ke klíči je secret, heslo ke store je také secret, platnost certifikátu je 365 dní, použitý šifrovací algoritmus je RSA, velikost klíče je 2048 bitů. Keystore se nachází v souboru ./keystore2.jks. Pokud takový soubor dosud neexistuje, bude vytvořen nový.

Vygenerovaný certifikát v keystoru je možné zobrazit příkazem

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

Zobrazený certifikát následně vložte do Vašeho IdP.

Dokumentace k utilitě Java Keystore Javy 11 je k nalezení zde:

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

Na straně konfigurace EgjeWEBu je nutné pak vyplnit následující položky:

Cesta pro uložení jks souboru: Zadejte zde cestu k souboru, kde se nachází Java Keystore s certifikáty pro šifrování/dešifrování SAML Tokenů. Zde zadaný soubor bude pak přímo vložen do konfiguračního jaru. Pokud provedete jakoukoliv změnu v keystoru, je nutné nahrát soubor do konfigurace znovu a restartovat webový server, aby se změna v keystoru projevila v aplikaci. Podobně se manipuluje například i se souborem obsahujícím metadata IdP.

Alias pro klíč: Alias, pod kterým je certifikát v keystoru uložen

Heslo ke store: Heslo ke keystore

Heslo ke klíči: Heslo k privátnímu klíči, který bude sloužit pro dešifrování SAML Tokenu na straně EGJE.

Pokud si nepřejete šifrovat SAML Tokeny, můžete nechat uvedené konfigurační položky nevyplněné.

Další volitelné parametry:

NameID format: Lze nastavit NameID formát který se bude posílat v SAML AuthnRequest. Je potřeba nastavit přesnou hodnotu.

Vytvořit SP metadata: Vytvoří endpoint pro generování SP Metadat obsahující aktuální nastavení. Endpoint se skládá z Adresa Web Aplikace/saml/metadata.

Tlačítko Vytvořit metadata zobrazí aktuální metadata. Více o nastavení viz Generování SP Metadat.

Logname element: Nastavuje atribut ze kterého se má načítat logname pro přihlášení do EGJE ze SAML Assertion.
Defaultní hodnota je Subject/NameID.

Pokud se použije AttributeStatement, je zapotřebí vyplnit položku „Název attributu obsahujícího logname“.

Název attributu obsahujícího logname: Obsahuje název custom attributu obsaženého v elementu „AttributeStatement“ v SAML Assertion pro zjištění logname. Zadává se název obsažený v atributu „Name“ v elementu „Attribute“.

Vždy při spuštění EGJE vynutit ověření: Přidá k SAML requestu parametr forceAuthn=true. Při novém otevření EGJE se vždy vynutí u IdP nová autentizace. IdP musí tento parametr podporovat a musí být povolen. Název položky v IdP se může lišit, např. Honor Force Authnentication.

Při odhlášení z EGJE odhlásit i z IdP: Při odhlášení z EGJE, se zároveň odešle request pro Single Logout z IdP. Tím se uživatel odhlásí z IdP a zároveň ze všech aktuálně přihlášených SP, které tuto funkci podporují. V IdP je zapotřebí SLO povolit a nastavit pro něj URL: https://<egjewebURL>/logout/saml2/slo (pozor, je to case sensitive). Dále je zapotřebí nastavit SP Issuer na stejnou hodnotu jako je nastavené SP Entity ID.

Logovat SAML: Zapne úroveň logování pro SAML knihovny na úroveň debug. Loguje velké množství dat a log se tak stává nepřehledným. Doporučujeme zapínat pouze při řešení problémů se SAML autentizací.

Java klient:

Ve Vašem Identity Provideru je potřeba nastavit koncový endpoint, na kterém klient EGJE přijme SAML Token. Tvar endpointu je následující: http://localhost:<saml_port>/saml/SSO (pozor, je to case sensitive).

V Identity Provideru může být tato konfigurační položka označena jako Single-Sign-On URL, Destination URL, záleží na Vašem Identity Provideru.

Dále pak je potřeba v konfiguraci EGJE nastavit v rámci zvolené autentizace SAML následující položky:

SP Entity ID: Vámi zvolený identifikátor Vaší aplikace EGJE AS. Parametr nastavujete v rámci Vašeho IdP. Název položky v IdP se může lišit, např. Audience nebo Audience Restriction. Záleží na Vašem IdP. Podle hodnoty, kterou nastavíte v IdP, nastavte pak odpovídající hodnotu i v konfiguraci EGJE AS.

IDP metadata: Xml dokument s metadaty IdP. Dokument Vám vydá Váš IdP. Pro ADFS v Elanoru je tento dokument možné získat z adresy http://fsso.domena.cz/federationmetadata/2007-06/federationmetadata.xml.

IDP metadata – cesta: URL adresa ke xml dokumentu s metadaty IdP. Z této adresy si EGJE AS při spuštění stáhne dokument s metadaty.

Interval pro obnovu metadat v CRON formátu: Interval nastavující obnovu souboru s metadaty bez nutnosti restartu AS. U parametru je tlačítko na kontrolu CRON formátu, zda je zadaný správně a aplikace ho dokáže přečíst.

Pro podepisování SAML requestů je potřeba specifikovat Java Keystore s certifikáty, které se použijí pro šifrování, resp. dešifrování SAML Tokenů. Pro manipulaci s keystorem se používá utilita keytool, která je součástí používané Javy.

Do keystoru je nutné pod nějakým aliasem vygenerovat pár klíčů, privátní a veřejný. Privátní klíč použije EGJE AS pro dešifrování tokenu, který je zašifrován Vaším IdP, veřejný klíč je nutné předat Vašemu IdP. IdP použije veřejný klíč pro zašifrování Tokenu před odesláním tokenu do EGJE AS. Příklad použití utility keytool pro vygenerování páru klíčů:

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

Vygenerovaný certifikát v keystoru je možné zobrazit příkazem

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

Zobrazený certifikát následně vložte do Vašeho IdP.

Dokumentace k utilitě Java Keystore Javy 11 je k nalezení zde:

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

Na straně konfigurace EGJE AS je nutné pak vyplnit následující položky:

Cesta pro uložení jks souboru: Zadejte zde cestu k souboru, kde se nachází Java Keystore s certifikáty pro šifrování/dešifrování SAML Tokenů. Zde zadaný soubor bude pak přímo vložen do konfiguračního jaru. Pokud provedete jakoukoliv změnu v keystoru, je nutné nahrát soubor do konfigurace znovu a restartovat AS, aby se změna v keystoru projevila v aplikaci. Podobně se manipuluje například i se souborem obsahujícím metadata IdP.

Alias pro klíč: Alias, pod kterým je certifikát v keystoru uložen

Heslo ke store: Heslo ke keystore

Heslo ke klíči: Heslo k privátnímu klíči, který bude sloužit pro dešifrování SAML Tokenu na straně EGJE.

Pokud si nepřejete šifrovat SAML Tokeny, můžete nechat uvedené konfigurační položky nevyplněné.

Port pro SSO/SLO: číslo portu, na kterém lokální server naslouchá pro přesměrování do IdP a zpět. Zadaný port musí být součástí URL pro SSO a SLO endpointy.

Další volitelné parametry:

NameID format: Lze nastavit NameID formát který se bude posílat v SAML AuthnRequest. Je potřeba nastavit přesnou hodnotu. Pokud se nevyplní použije se hodnota urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Vytvořit SP metadata: Vytvoří endpoint pro generování SP Metadat obsahující aktuální nastavení. Endpoint se skládá z http://<adresa_as>:<saml_metadata_port>/saml/metadata.

Tlačítko Vytvořit metadata zobrazí aktuální metadata. Více o nastavení viz Generování SP Metadat.

Port pro generování SP metadat: port na kterém se spustí server pro generování SP metadat.

Logname element: Nastavuje atribut ze kterého se má načítat logname pro přihlášení do EGJE ze SAML Assertion.
Defaultní hodnota je Subject/NameID.

Pokud se použije AttributeStatement, je zapotřebí vyplnit položku „Název attributu obsahujícího logname“.

Vždy při spuštění EGJE vynutit ověření: Přidá k SAML requestu parametr forceAuthn=true. Při novém spuštění EGJE se vždy vynutí u IdP nová autentizace. IdP musí tento parametr podporovat a musí být povolen. Název položky v IdP se může lišit, např. Honor Force Authnentication.

Při odhlášení z EGJE odhlásit i z IdP: Při odhlášení z EGJE, se zároveň odešle request pro Single Logout z IdP. Tím se uživatel odhlásí z IdP a zároveň ze všech aktuálně přihlášených SP, které tuto funkci podporují. V IdP je zapotřebí SLO povolit a nastavit pro něj URL: http://localhost:<saml_port>/saml/SLO (pozor, je to case sensitive). Dále je zapotřebí nastavit SP Issuer na stejnou hodnotu jako je nastavené SP Entity ID. Pro odhlášení z IdP je zapotřebí mít vyplněný keystore pro podepsání SAML tokenů.

Podepsat SAML SSO Request: Podepíše SAML request pro přihlášení. Využívá se pro IdP, které nepodporují nastavení atributu WantAuthnRequestsSigned v metadatech z IdP. Pro podepsání je zapotřebí mít vyplněný keystore.

Generování SP metadat:

Kromě základního generování metadat je možné parametricky doplnit dodatečné informace. Pro jejich doplnění je nutné ručně upravit soubor config_local.properties v archivu config_egje.jar. Pro tyto atributy lze obvykle nastavit více hodnot například pro každý jazyk vlastní hodnotu.

Aby se správně zobrazovala čeština, je potřeba upravovat soubor v kódování ISO-8859-1.

Doplnit lze následující oblasti:

o UIInfo – Element UIInfo v elementu Extensions

§ Slouží k dodatečnému nastavení informací o spouštěné aplikaci.

§ Nastavit lze tyto elementy: Description, DisplayName, InformationUrl.

§ Pro každý element se nastaví atribut lang obsahující jazyk, pro který jsou informace vyplněny.

§ Příklad nastavení v 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

§ Slouží k dodatečnému nastavení informací o organizaci.

§ Nastavit lze tyto elementy: name, displayname, url.

§ Pro každý element se nastaví atribut lang, obsahující jazyk, pro který jsou informace vyplněny.

§ Příklad nastavení v 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

§ Slouží k zadání kontaktní osoby.

§ Nastavit lze tyto elementy: company, given_name, sur_name, email_address, telephone_number.

§ E-mailové adresy i telefonní čísla lze zadat pro daný kontakt vícekrát za pomoci indexů.

§ Pro daný typ kontaktu lze nastavit atribut contactType.

§ Příklad nastavení v 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

Autentizace NTlogin* bez číslovky 2 byli zrušeny v e202409 a od e202411 se pomocí nich nejde do EGJE přihlásit.

Autentizace NTlogin2* jsou zde pouze pro zpětnou kompatibilitu. Nedoporučujeme je používat.

Autentizace NTlogin3* však bezpečnostní kritéria splňují a pro OS linux jsou vhodné. Tyto autentizace využívají novější SMB2 protokol.

SSO autentizace (NTLogin3 a NTLogin3Only) nepoužívá zabezpečený secure channel pro NETLOGON komunikaci s doménovými controllery. Pro správnou funkčnost je pro servisní NTLM účet zapotřebí použít nezabezpečeného Netlogon připojení viz. odkaz: 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

Na zprovoznění zabezpečené komunikace pracujeme a bude podporována v další verze IS EGJE.

IP adresy doménových řadičů (NT Login)
IP adresa autentizačního serveru pro NT login (je-li jich více jsou odděleny čárkou; použit je pak první, který je spuštěn)

Není-li vyplněn, je použit řadič zjištěný z NT login implic. domény

V praxi je někdy výhodné zadat jiný server než doménový řadič, který volání zprostředkuje (SSO u Web aplikace a doménovým řadičem Windows 2003)

NT login implic.doména předvyplnění položky doména u NT login

Pro NTlogin2 je třeba vyplnit parametry:

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

Účet počítače pro připojení k DC (NT Login2)
Computer account for connection to DC (NT Login2) (ntlm2ServerAccount)

Účet počítače pro připojení k DC (NT Login2) - Heslo
Password of computer account (NT Login2) (ntlm2ServerPassword)

Více technických informací o NTlogin2 je možné získat na webu u knihoven

jespa-1.1.21 Jespa_Operators_Manual.pdf

Je zde dobře popsáno vytvoření computer account v AD, který je pro NTlogin2 zapotřebí.

Pozn. knihovny jespa EGJE nepoužívá, není tedy třeba jejich licence.

Stručně je postup vytvoření computer account následující:

· vytvoření účtu nějakou ze standardních utilit (Active Directory Users and Computers (ADUC) MMC Snap-In.)
Maximálně 15 znaků z A-Z, a-z, 0-9,“-„, „_“

· nastavení hesla – z příkazové řádky skriptem

prvním parametrem je jméno účtu následované znaky $ a @ DNS doménovým jménem a druhým heslo
př. C:\tmp>SetComputerPassword elanor1$@firma.corp heslo

Heslo musí být jiné než jméno účtu.
Úspěšné provedení indikuje hláška „The password was set successfully“.

2.1.19 smart_card

Autentizace je k dispozici od e201905 pro java klienta, od e201909 i pro web klienta.

Jde o tzv. 2-faktorovou autentizaci, kdy klient pro přihlášení potřebuje vsunout kartu do čtečky a zadat heslo, které EGJE ověří vůči certifikátu na kartě.

Systém jsme vyvinuli a testovali na čtečce a kartě prodávané firmou První certifikační autorita (https://www.ica.cz/Order-Hardware, Smart-Card Reader GemPC USB-SL, Smart Card Starcos 3.5).

Certifikát si uživatel zaeviduje pomocí formuláře Opv51 - Osobní certifikát, přičemž vlastní veřejný klíč je uložen do úložiště společného s Opv31 (jako uchaz_dok_typ 51 - Osobní certifikát I.).

To slouží pro tuto autentizaci místo standardního Adm10 / Logname, které používají všechny ostatní autentizace.

Pro tuto autentizaci jsou v sekci Smart Card další parametry:

- Zdroj certifikátů: combo Čipová karta/Osobní certifikáty uživatele

- Certifikační autorita: certifikát autority v binárním formátu. Je-li vyplněno, lze pro autentizaci použít pouze certifikáty touto autoritou vydané.

- Jméno v certifikátu se musí shodovat se jménem v EGJE - checkbox

Kontrola shody Jména a Příjmení - certifikát, vs. Osb02.

V EGJEWeb je tato autentizace funkční pro tomcat + Chrome nebo EDGE.

Ve Firefoxu také funguje, ale je třeba nastavit PKCS#11 modul v konfiguraci.

Přičemž zde je hláška Firefoxu pro zadání pinu, která je trochu odtažitá: "Please enter the master password for the 9203050100050786."

Příklad konfigurace tomcatu pro tuto autentizaci:

<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 Údaje pro změnu hesla pomocí LDAP a autentizaci LDAP:

LDAP - SSL URL á

adresa a port ldap serveru

např. ldaps://xxxx:636

resp. adresa port i kořen, pod kterým jsou uživatelé systému (mohou být i v podřízených uzlech)
např. ldaps://prgxx1:636/OU=Country.Czech,OU=ElanorUsers,DC=myorg,DC=cz

LDAPSearch - filtr

aditivní filtr

použije se typicky s Novell eDirectory resp. s Microsoft AD resp. všude tam kde filtr nejde psát přímo do přihlašovacího řetězce LDAP - SSL URL.

např. uid=%username%

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

LDAP-speciální uživatel pro práci s LDAP (+heslo)

uživatel použitý pro přihlášení a procházení LDAP serveru resp. pro činnost v rámci správy uživatelů Adm12.

uživatel je také použit při změně hesla v AD po jeho expiraci (resp.první přihlášení)

obvykle musí být uveden i s doménou

např. ldapadmin@myorg.cz

LDAP/Web - implicitní doména uživatele

doména, která se doplňuje při přihlášení za uživatelské jméno (typicky pro LDAPOnly)

např. myorg.cz

Web - ldap base s maxPwdAge (změna hesla)

ldap adresa pro ziištění maximální doby platnosti hesla

např. dc=myorg,dc=cz

Jde o varování ještě před expirací hesla.

Zjišťování se provádí pouze pro LDAPOnly a pro uživatele, kteří mají práva na Xpw01.

Pozn. v EGJE implementována i změna hesla po expiraci, viz výše.

LDAP/Web - doba (počet dní) předstihu před vypršením hesla

doba, po jejímž dosažení systém vyžaduje jeho změnu

Web - telefon na správce - zobrazen v případě, kdy vypršelo heslo

Web - e-mail na správce - zobrazen v případě, kdy vypršelo heslo

LDAP/Web - zpráva - heslo nesplňuje pravidla

zpráva, kterou systém odpoví v případě, že nové zadané heslo při změně hesla nesplňuje podmínky na heslo kladené

Pozn. Další parametry pro vytváření uživatele v LDAP repository (form. Adm12) jsou v Adm21/Konfigurační parametry/Vytváření uživatelů LDAP/AD.

Soubor s požadavky na reset hesla (úplná cesta):

EGJE Web umožňuje z adresy

http://xxxxxx/egjeweb2/ref/resetpass

generovat textový soubor s požadavky na reset hesla

Tento parametr udává plnou cestu k tomuto souboru.

(následné promítnutí souboru např. do Active Directory již aplikace neřeší)

WEB / http adresa - přesměrování - uživ.nemá profil:

je parametr, který použije aplikace EGJEWEB v případě, že dojde sice k ověření uživatele, ale tomu správce nepřiřadil žádný aplikační profil pro přístup do EGJE. V tomto případě aplikace přesměruje prohlížeč na tuto adresu, kde předpokládáme, že jsou uvedeny organizační informace, jak se má uživatel dále zachovat.

Výčet profilů povolených pro WEB.

Z této konkrétní instalace EGJEWeb2 se pak půjde přihlásit jen na uvedené zaměstnanecké, manažerské nebo referentské profily. Jde o regulární výraz. Např. MANA.*|ZAME.* znamená profily s kódy začínajícími MANA nebo ZAME.

Nekontrolovat e-mailovou adresu odesilatele

Nastavení, zdali provádět kontrolu formální správnosti adresy odesílatele mailu (obvykle firemní mail osoby uživatele - Osb02)

2.2 Konfigurace pro mobilní přístup

Pro přístup z mobilů/tabletů včetně zpřístupnění mimo intranet či doménu může být v organizaci speciální instalace EGJEWeb2.

Zde může být zadáno speciální ověření „Mobile“, ale může zde být i jiné ověření, ale pro prohlížeče mobilů / tabletů s mobilním user agentem je stejně vždy používáno ověření Mobile.

Pokud tedy správce u serveru zadá ověření Mobile, není dovoleno žádné jiné ověření. I uživatelé PC pak podléhají mobilnímu ověření. Což může být využito pro některé externí přístupy i z PC.

Zabezpečení aplikace má pak trochu jinou strukturu:

Zde v Configuratoru / AS,WEB-režim Web server je možné zadat „Výčet profilů povolených pro WEB“.
Z této konkrétní instalace EGJEWeb2 se pak půjde přihlásit jen na uvedené zaměstnanecké, manažerské nebo referentské profily. Jde o regulární výraz. Např. MANA.*|ZAME.* znamená profily s kódy začínajícími MANA nebo ZAME.
Pozn. omezení platí pro celou EGJEWeb2 tedy i pro přístupy z PC tj. přes nějaké jiné ověření (např. mswin_ntlm aj.)
Adm02 / Povoleno pro autentizaci mobil/tablet - který profil smí dostupný být z mobilu tj. mobilní autentizací (plošně pro všechny EGJEWeb2)
Adm10 / Povolení přístupu z mobilních zařízení - která osoba smí přistupovat do aplikace z mobilu/tabletu (tj. pomocí mobilního ověření).
Adm16 – Správce nebo Manažer či jiný uživatel se zadaným mobilním profilem a povolením zde (tedy z ověřeného uživatele) vytvoří dočasné heslo pro vytvoření autentizace v konkrétním zařízení a konkrétním prohlížeči v něm (pozor je třeba jej mít v režimu „mobilní user agent“ tzn. nemít např. v mobilním Chrome zaškrtnuto „Verze webu pro PC“).
Heslo si může do mobilního zařízení (má-li jej právě v ruce) rovnou opsat, nebo jej odeslat na e-mail zadaný personalistou v Osb02 (druh komunikace 31) – tlačítko „Odešli heslo e-mailem“.
Pozn. pokud má uživatele více mobilních zařízení nebo jej mění je vhodné si tyto přístupy evidovat se jménem zařízení.
Pokud má uživatel tento e-mail přístupný v mobilním zařízení, je zprovoznění nejpřímočařejší. Otevře si e-mail a klikne na link v něm. Ten již jednorázové heslo obsahuje a aplikaci v konkrétním mobilním zařízení zprovozní.
Pokud ne, zadá v mobilním prohlížeči adresu aplikace a do jediné v tu chvíli zobrazené položky zadá jednorázové heslo.
Zároveň je v obou případech vhodné si rovnou z mobilního prohlížeče odkaz na aplikaci přidat na plochu a příště ji již spouštět odsud.
Jednorázové heslo je dočasné, při jeho generování se zadává jeho platnost (standardně 10 minut).
Když uživatel mobilní zařízení ztratí, je potřeba z EGJE co nejrychleji v Adm16 přístup pomocí tohoto zařízení zneplatnit (tlačítko Zneplatni přístup)!
Případně, má-li uživatel zařízení více a není jasné, které je které, tak zneplatnit všechny resp. zrušit v Adm10 uživateli mobilní povolení úplně.
Přímo v mobilní aplikaci má uživatel volbu „Zrušení přístup z mobilního zařízení“ (nad volbou Odhlášení). Po dotazu se pak přístup z konkrétního prohlížeče konkrétního mobilního zařízení zneplatní shodně jako výše uvedenou akcí „Zneplatni přístup“ z Adm16 resp. smazáním řádku s evidencí přístupu tamtéž.

Pozn.: v Adm21 / Parametry komunikace je parametr "http(s) adresa EGJEWeb2 pro mobilní přístup:" Tato adresa je použita v Adm16 při akci Odešli heslo e-mailem. V e-mailu je link složený z této adresy a parametru – jednorázového hesla.

Možnost vypnutí mobilní autentizace

V konfiguraci zpřístupňované utilitou Configurator je na záložce AS,WEB-režim Web server parametr (v pořadí druhý)

Pro mobilní zařízení (dle user agent) použít vždy autentizaci Mobile Ano/Ne

Jeho nastavení na Ne pak způsobí, že i z mobilních zařízení, které se prohlížeči hlásí jako

user agent = mobile, se bude volat ta autentizace, která je uvedena o řádek výš v položce autentizace.

3 Nastavení přístupových práv v aplikaci

Přiřazení / Vytvoření uživatele

Pokud Osoba uživatele/referenta ještě v db není a nemá v ní jako zaměstnanec, zakládáme ji pomocí průvodce Adm01p. Takto ji vytvoříme jako osobu s PV se statusem 21.

Uživatelé referenti, zaměstnanci, manažeři, kteří jsou v db již evidováni (obvykle jako zaměstnanci), mít speciální uživatelský PV nemusí. Specifikaci atributů uživatele pak zadáme pomocí formuláře Adm01 resp. Adm10.

U uživatele zadáme profil a jazyk, případně omezení na Organizaci a pomocí zadání "Profil - autentizace" propojíme autentizaci s Osobou v db. Autentizační přihlašovací jméno (jména) zadáváme v tomto (těchto) tvarech:

Autentizace Windows NT

WinDoména\uživatel př. MOTOR\jigecz

Autentizace kerberos, LDAP

uživatel@doména př. jigecz@motor.cz

Autentizaci uživatele buď přebírá z operačního systému (SSO) nebo ji interaktivně zadá (jméno heslo). Režim jsou popsány v předcházející kapitole Nastavení - configurator_egje.

U každého přiřazení profilu vyplňujeme jazyk uživatelského rozhraní.

Upozornění: ve státní správě všem vyplňujeme jazyk "cs_ST" místo standardního "cs".

Vytvoření a editace profilu

Profil vytváříme a editujeme na formuláři Adm02.

3.1 U profilu na první záložce definujeme typ přihlášení a přístupová práva k řádkům:

· Typ přihlášení - rozlišení mezi personalistickým přihlášením ke dni a mzdářským přihlášením k období

Zároveň položka definuje nabízení data při editaci časově sledovaných položek.

K dispozici jsou typy:

1 Přihlášení k datumu - změna časových údajů od 1.tohoto měsíce

2 Přihlášení k období - změna časových údajů od 1.zvoleného období

3 Přihlášení k datumu - změna časových údajů od ref.data

4 Přihlášení k datumu - změna časových údajů od 1.násl.měsíce

5 Přihlášení k období - změna časových údajů od 1.násl. období

· Typ GUI - pro jaké UI je profil určen. Hodnoty jsou:

1 - Java a Web klient - rozhraní referent

2 - Starý Web klient

3 - Web klient - rozhraní referent

4 - Java klient - rozhraní referent

11 - HR portál - rozhraní zaměstnanec samostatně prodávaný produkt

12 - HR portál - rozhraní manažer samostatně prodávaný produkt

21 - Pouze WS - Bez přístupu do UI EGJE, přístup pouze webovou službou

Práva dle SO a SJ, použitá i pro omezení práv k osobám a PV

· SJ resp. SO pro omezení práv - organizace je (resp. může být) rozdělena na správní jednotky (SJ) a správní oddíly (SO). SJ je rozdělením navenek - je protějškem různých institucí typu Zdravotní pojišťovna, Finanční úřad atd.
Skládá se z minimálně jednoho (ale může jich být i více) SO.
SO je rozdělením pro zpracování mezd. Pro SO definujeme výplatní termín, na SO provádíme hromadné výpočty a uzávěrky.
Upozornění: Pro zrychlení zpracování práv k řádkům doporučujeme SJ, SO na profilu, tam kde je to možné, uvádět, zpracování práv je pak rychlejší a promítne se i do nabídkových ComboBoxů SJ a SO, ve kterých je nabídka SJ či SO a nikoliv osoby a PV.

· U zaměstnaneckého, manažerského ale i u některých referenčních profilů, které jdou přes celou organizaci by vyplňování SJ, SO vedlo k tomu, že by se profily musely vytvářet pro každý SO zvlášť.

Aby to nutné nebylo, je pro tyto případy vhodné použít nastavení atributu "Chybějící práva na SJ, SO určit z příst. osob/PV:" = Ano.

Pracuje to tak, že se projdou všechny PV, na které má uživatel práva a zjistí se jejich všechny SO, SJ a Legislativy. Tyto se pak vezmou a tvoří omezení uživatele v těchto třech parametrech a také pak omezují nabídkové ComboBoxy SJ a SO.

· SO zpřístupnit i nezařazené - definice má význam pro ty typy PV, které se na SO nepřiřazují (uživatel, lektor, uchazeč...). Nastavením na Ano se takové osoby (PV) stanou viditelnými
(Přiřazení PV k SO se provádí na Opv01 záložka Správní oddíl).
Pozn.: Pro sestavy, které čerpají z mezd a řádková práva se u nich vyhodnocují z mezd položka nemá význam, neboť ve mzdách jsou pouze osoby/PV zařazené na SO.

Další podmínky omezení práv k osobám a PV

· PV - režim práv k řádkům - možnost zadat další aditivní podmínku k omezení pomocí SJ, SO.
Může nabývat těchto hodnot:

VSE	Všechno (v rámci dalších podmínek na SO, SJ, statusy, chráněné PV)
STRU	Osoby a PV zařazené na strukturu
STRU_PRIMO_HIST	Osoby a PV zařazené na strukturu, přístup v celé historii, ale max do data, kdy má přístup k osobě
ST_POD	Osoby a PV zařazené na struk.a podř. struk.
VL_OSO	Vlastní osoba
ST_MANA	Osoby a PV ze struktur, u kterých je uživatel označen jako manažer
ST_MANA_POD	Osoby a PV ze struktur, u kterých je uživatel označen jako manažer a podřízená střediska
ST_MANA_PRIMO	Od ST_MANA se liší tím, že kromě zaměstnanců, kterým je uživatel manažerem (dle uvedené struktury) má přístup i k manažerům přímo podřízených jednotek. Obvykle jde o podřízené vedoucí v organizační struktuře.
ST_MANA_POD_OBD	Od ST_MANA_POD se liší tím, že vyhodnocuje, zdali zaměstnanec pod uživatele patřil alespoň jeden den v období (měsíci).
ST_MANA_OBD	dtto ale pro režim ST_MANA
ST_POD_OBD	dtto ale pro režim ST_POD
STRU_OBD	dtto ale pro režim STRU
ST_KUMUL, ST_KUMUL_POD	Instalace na VŠE umožňuje nastavit další 2 režimy. V následující Adm02 položce "PV typ struktury" správce vyplní 8. PV výčet prvků zůstává prázdný. Realizuje se tím režim zaměstnance pod dvěma manažery. Předpokládá se zadání více prvků (středisek) struktury 8 na jedno PM v Pmi01 tzn. PM pracuje pro 2 střediska. Přístup k zaměstnanci na tomto PM tak získávají 2 manažeři 2 prvků (středisek) struktury 8.

Pozor: všechny _OBD režimy platí pouze pro přímé přiřazení struktury použité pro definici práva! Přiřazení se provádí na PV v Opv01/Struktury.

Pozn.: Pro účely práv typu *MANA* manažera zaniklého střediska už nepovažujeme za manažera, jemuž náleží zařazení a podřízení. Jinými slovy k datumu zjišťování bereme u těchto režimů v potaz vznik a zánik prvku (Str01).

· PV - typ struktury pro práva k PV
typ struktury (Str01)

· PV - výčet prvků struktury pro práva k PV:
Pro typ STRU, ST_POD a ST_POD_OBD se zde uvádí kód(y) struktur pro omezení právy.
Používá se kód resp. kódy oddělené čárkou. Pro zadání negativní podmínky “vše kromě” se před výčet napíše znak ”!" - viz dále odstavec.
Pokud ponecháme hodnotu nevyplněno, bere se struktura (typicky středisko), na které je zařazen přihlašující se uživatel resp. které je manažerem (ST_MANA, ST_MANA_POD, ST_MANA_PRIMO, ST_MANA_OBD, ST_MANA_POD_OBD).

Pro VSE,VL_OSO, ST_MANA, ST_MANA_POD, ST_MANA_PRIMO, ST_MANA_OBD, ST_MANA_POD_OBD položka nemá význam.

· ST_MANA* práva v režimu přístup k celé historii:
Příznak se používá u referentů typu mzdová účetní, jejichž práce má roční charakter. Nastavení na Ano pak referentovi navíc zpřístupňuje zaměstnance, které měl ve aktuálním roce alespoň jeden den přístupné.
Tento režim je dostupný pouze pro ST_MANA*. V ostatních režimech toto není podporováno

· PV - zpřístupnit i nezařazené PV - definice má význam pro ty typy PV, které se na strukturu nepřiřazují (uživatel, lektor, uchazeč...). Nastavením na Ano se takové osoby (PV) stanou viditelnými
(Přiřazení PV na strukturu se provádí na Opv01 záložka Zařazení do struktur).

· PV - výčet povolených statusů PV - aditivní definice práv na základě výčtu položky Opv01/Popis/Status vztahu osoba org.
Častou hodnotou bývá např. pro mzdové účetní omezení 1,2 (tedy ta počítaná) resp. 1,2,3

· PV - výčet statusů pro práva- aditivní definice práv na základě výčtu položky Opv01/Popis/Status - práva. Na rozdíl od minulé položky, kde číselník je ve správě Elanoru, u této položky je číselník ve správě uživatele (Jpc01 / status_prava). Pro zadání negativní podmínky “vše kromě” se před výčet napíše znak ”!" - viz dále odstavec.

· PV - zpřístupnění chráněných PV - aditivní definice práv na základě příznaku, který správce může osobě - PV nastavit v Adm11 / PV / Chráněná osoba.

Všechny tyto podmínky jsou vyhodnocovány jako "a zároveň". Nastavení více podmínek tedy obvykle vede k větší restrikci.

Vlastní vyhodnocení práv k řádkům:

Ve většině míst aplikace se práva k řádkům vyhodnocují z průběžných kmenových dat.
Tzn. z dat formulářů Opv01 (Trvání, Popis, Struktury), Str01 (Hierarchie od-do, Jiné struktury, Manažer – osoba v EGJE).

V datech, kde převažuje pohled na zúčtované mzdy, však EGJE vychází z toho jako to bylo v tom měsíci zúčtováno.

Tzn. Vyp02/Kopie struktur (dle Str01/Použití struktury=1-MZDY), Vyp01 (výpočet), Str05.

Jde o tyto sestavy: 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 formuláře Vyp07, Vst01h, Slm05.

Povolení přiřadit

· PV - výčet typů struktury - povolení přiřazení:
je-li prázdné, tak bez omezení, je-li vyplněno výčtem typů struktury (navigace Str01) tak omezují, které struktury smí uživatel zaměstnanci přiřazovat (Opv01, Opv04, Opv05)

· Preferovaný navigační seznam Pv
Pro profil je možné vybrat implicitní navigační seznam pro formuláře s tímto navigačním seznamem (např. Osb02, Opv01, Vyp01, Kva01, Dav01...)

Práva k řádkům - další objekty

(systém skupin ŘP je komplexněji popsán v Adm_uzdoc – kapitola Adm06)

· Omezení číselníků dle skupin ŘP - uživatel uvidí (obvykle v nabídkových ComboBoxech) jen ty hodnoty z příslušného číselníku, které jsou označeny touto skupinou (výčet oddělovaný čárkou, nebo intervaly oddělené čárkou. Např. 1,7-9,23-26,29, … atd). Pro zadání negativní podmínky “vše kromě” se před výčet napíše znak ”!" - viz dále odstavec.

· Přidat vlastní skupinu z Org.str. - přidá ke skupinám v předchozím řádku ještě tu skupinu, která je uvedena u organizačního střediska, na které je uživatel zařazen.

· Omezení editace číselníků dle skupin ŘP - pro uživatele, kteří editují číselníky - musí zde mít výčet všech skupin, jimiž označené řádky v číselníku mají vidět a editovat (jinak vidí jen řádky bez označení skupinou). Pro zadání negativní podmínky “vše kromě” se před výčet napíše znak ”!" - viz dále odstavec.

· Přidat vlastní sk. z Org.str. - editace - dtto úvodní dvojice, ale pro účel editace číselníků

· Omezení editace číselníku struktur (výčet typů) - výčet typů struktury (navigace Str01), které uživatel smí editovat. Např. 2,3 způsobí, že uživatel v Str01 uvidí a může editovat pouze Organizační strukturu (2) a Pracovní místa (3).
To může být zkombinováno s omezením editace jen některých řádků (pomocí předchozích dvou parametrů)

· PM - práva k PM dle organizační struktury
nastavení na Ano způsobí, že v navigačním seznamu pracovních míst (Pm), budou pouze ta PM, která jsou na organizačních střediscích, ke kterým má uživatel přístup (předpokládá se definování práv podle organizační struktury). Navigační seznam je použit např. u Pmi01, Pmi08, Pmi09.
Není-li položka vyplněna, omezení není uplatňováno.

· Typy dokumentů (Opv31, Rea0x) - výčet
Parametr poskytuje možnost zadat výčet typů dokumentu, které smí uživatel u zaměstnance, resp. uchazeče vidět a editovat. Pro zadání negativní podmínky “vše kromě” se před výčet napíše znak ”!" - viz dále odstavec.

· Typy dokumentů pouze pro čtení (Opv31, Rea0x) - výčet
Parametr poskytuje možnost zadat výčet typů dokumentu, které smí uživatel u zaměstnance, resp. uchazeče vidět, ale nikoliv zadávat a editovat.
Pro zadání negativní podmínky “vše kromě” se před výčet napíše znak ”!" - viz dále odstavec.

Výčet druhů komun. kontaktů (Pkz01, Osb01/2) - analogicky – zadává se výčet čísel druhů, včetně záporného výčtu iniciovaného znakem ”!".

Práva k uchazečům - navigace

· UCHAZ - výčet statusů - navigace
možnost omezit zobrazovaný seznam uchazečů pomocí výčtu statusů (čárkami oddělované číselné hodnoty statusu uchazeče).
Týká se i statusů.

Práva k uchazečům - procesní omezení

· UCHAZ - výčet statusů - smí nastavit
možnost zadat výčet statusů, které smí uživatel u uchazeče nastavit / přiřadit

Docházka – definice verifikační úrovně uživatele pro oblast docházky

· Úroveň editace docházky - verifikační a editační úroveň profilu pro ověření řádků resp. pro oprávnění přístupu k řádkům v evidenci docházky (DD, DZ, MV, MZ, doklady).
K dispozici jsou úrovně:
3 Zaměstnanec; 13 Vedoucí I.; 23 Vedoucí; 33 Správce resp. mzdová účetní

Zobrazení protokolů z DOCH, DAV

1 - Standard (popup) (tj. jako dosud)

2 - Potlačit zobrazování protokolu v dialogu tzn. nezobrazovat vůbec

3 - V EGJEWEB protokol do záložky EGJE (ve std. klientovi popup - 1)

Typické použití je celoobrazovkový režim terminálů s EGJEWEB.

Chybějící práva na SJ, SO určit z podřízených osob (ST*, VL_OSO)

Manažerský/zaměstnanecký profil obvykle bývá průřezový pro celou organizaci a nevytvářejí se jeho varianty pro různé SJ/SO. Zapnutím této volby je možné výčty SJ, SO online dopočítávat při přihlášení dle SO, SJ zařazených manažerovi přístupných PV.

Tato práva na SJ/SO se pak typicky používají v různých nabídkových comboboxech a to v sestavách i formulářích.

Implicitně příznak není zapnutý a tato aditivní akce se po přihlášení neprovádí.

Doporučené a obvyklé profily

V tabulce zmiňujeme jen ty atributy, které se odchylují hodnot předvyplněných při Adm02/Nový profil.

Typ	Popis
Zaměstnanec	SJ, SO nevyplněno, Chybějící práva na SJ, SO určit z podřízených osob = Ano PV režim práva = VL_OSO
Manažer - osoby ze struktur, jichž je manažerem	SJ, SO nevyplněno, Chybějící práva na SJ, SO určit z podřízených osob = Ano PV režim práva = ST_MANA PV Typ struktury = 2 (obvykle org. struktura) Pozn. U každého prvku struktury 2 musí být vyplněn manažer (Str01, Str02 / Manažer - Osoba v EGJE Může i nemusí mít přístupnou vlastní osobu (PV - zpřístupnění chráněných PV)
Manažer - dtto + manažeři podřízených středisek	dtto PV režim práva = ST_MANA_PRIMO
Manažer - všichni podřízení	dtto PV režim práva = ST_MANA_POD
Manažer, pověřená osoba - osoby ze struktury, na kterou je sám zařazen	SJ, SO nevyplněno, Chybějící práva na SJ, SO určit z podřízených osob = Ano PV režim práva = STRU (resp. ST_POD pro všechny z podstředisek) PV Typ struktury = 2 (obvykle org. struktura ale může jít i o jinou) PV výčet prvků struktury pro STRU, ST_POD = nevyplněno
Referent mzdová účetní - celý SO	SJ, SO vyplněn (mohou být výčty) PV režim práva = VSE
Referent mzdová účetní - přiřazené PV	SJ, SO pokud konstantní tak vyplněn (mohou být výčty) PV režim práva = ST_MANA PV Typ struktury = 14 - Mzdová účetní Pozn. U každé mzdové účetní tj. prvku struktury 14 musí být vyplněna vazba na osobu/uživatele tj.Str01, Str02 / Manažer - Osoba v EGJE. Tím je dosaženo, že profil pro více mzdových účetních může být jeden a přesto má každá MÚ svoje zaměstnance. Zaměstnanci mohou být zařazeni pod mzdovou účetní (struktura 14): na PV v Opv01/Struktury na PM v Pmi01, Str01, Str02 na Org. středisku v Str01, Str02 U referenta tohoto typu je vhodné nastavit příznak „ST_MANA* práva v režimu přístup k celé historii:“ na Ano a zpřístupnit tak referentovi i data svěřených zaměstnanců z doby před vznikem PV referenta.
Jiný referent - přiřazené PV	dtto mzdová účetní, pouze číslo struktury bývá jiné typicky 15 - 18 resp. 13

Výhodou použití profilů ST_MANA pro referenty je to, že se pro všechny (nebo alespoň skupinu) referentů daného typu může použít společný profil.

Na tento profil se pak dají přehledně vázat další konfigurace:

Adm06 - obecné skupiny, skupiny SLM, skupiny kalendářů

Epr02 - eProposal

Adm02 - role zařazené na profil

Mail - možnost odeslat zprávu všem na profile

Při vytvoření speciálního profilu pro každého referenta zvlášť je potřeba uvedené konfigurace udržovat pro každý profil samostatně a to může být u většího počtu referentů pracné a nepřehledné.

Typicky mívá takový referent profil s tímto nastavením:

SJ, SO vyplněn (mohou být výčty)
PV režim práva = STRU

PV Typ struktury = některá ze struktur 13-18

PV výčet prvků struktury pro STRU, ST_POD

= seznam uživatelských kódů prvků struktury oddělených čárkou

Jak nakonfigurovat struktury, aby byly použitelné pro přístupová práva podle struktur (tj. režimy ST*).

Na Str01 je potřeba nastavit:

Vazby mezi strukturami:

Zadává-li se struktura na PM, pak
"Podřízená struktura (vyplňuji kde)" bude 3 - Pracovní místo
a "Nadřízená (vyplňuji co)" bude např. 14 - Mzdová účetní

Pokud údaje zadávám už na Organizačním středisku, pak
"Podřízená" bude 2 - Organizační struktura.

Pokud zadáváme na PV (Opv01 / Struktury), pak v záložce Použití struktury zadáváme pro tu konkrétní strukturu (např. 14 - Mzdová účetní) hodnotu 2-KMEN-PV.

Pozn.: pokud v Opv01 / Struktury smí tuto strukturu přiřazovat jen někdo, je možné ostatním profilům se zápisovým právem na tuto záložku nastavit výčet Adm02 / PV - výčet typů struktury - povolení přiřazení: takový, aby tuto strukturu neobsahoval.

Na strukturách platí zásady nepřímého přiřazení. Na organizačním středisku tedy mohu vyplnit nečastější hodnotu (třeba tu Mzdovou účetní do Str01 / Stru / Manažer osoba v EGJE, odchylky pak vyplnit na PM a nebo až na PV.

Tak je možné výhodně minimalizovat počet míst, kde je údaj vyplňován.

Pro práva typu ST_MANA*, použitého pro referenty, je možné řešit situaci, kdy referentů je pro tu samou skupinu osob/PV více a jsou rovnocenní. V tom případě se zaškrtne checkbox (např. u té struktury 14) v Str01 / Jméno struktury a jejích hladin / Smí být paralelně více manažerů/osob.

Následně je pak možné v Str01 / Stru / / Manažer osoba v EGJE), zadat více paralelních referentů.

Tento režim by se ale neměl používat u struktur, použitých pro schvalování (workflow dle Adm14), proto jej nenabízíme pro strukturu 2, která je takto použita nejčastěji.

Negativní vymezení přístupu k Osobám a PV

Od e201809 je možné kromě standardního zadání "všichni, kteří mají cosi" zadat přístupová práva k řádkům (tj. osobám a PV) negativně, tedy "všichni, kromě těch, kteří mají cosi".

Dává to tak snadnou alternativu k "PV - zpřístupnění chráněných PV", které používá atribut Adm11/PV/"Chráněná osoba/PV".

Všichni kromě umožňujeme zadat pro:

· PV - výčet statusů pro práva

· PV - výčet prvků struktury pro STRU, ST_POD (právě a pouze pro tyto 2 režimy)

· Omezení číselníků dle skupin ŘP

· Omezení editace číselníků dle skupin ŘP

· Typy dokumentů (Opv31, Rea0x) - výčet. Čtení i zápis

· Výčet druhů komun. kontaktů (Pkz01, Osb01/2)

Negativní výčet se zadá tak, že se do prvního znaku položky pro hodnotu zadá znak"!".

Tedy např. pokud do "PV - výčet statusů pro práva" zadáme např. hodnotu "!5", pak budou přístupné ty PV, které nemají v položce Opv01 / Popis / Status práva hodnotu "5".

Znak "!" je funkční právě a pouze na místě prvního znaku a říká, že vše za tím bude vyhodnoceno negativně. Není tedy možné v rámci jedné položky kombinovat pozitivní a negativní zpracování.

Alternativní vyhodnocování práv k osobám a PV (řádková práva offline)

Na větších databázích je často u manažerských a referentských přístupů dlouhé úvodní otevírání oken, které je spojené s načítáním navigačních seznamů a seznamů v combo boxech.

Od e202109 umožňujeme řešení, které pracuje částečně offline, a které toto načítání a tím první otevření oken typu Wflow, Epr01, Kva01,... výrazně urychlí.

Zprovoznění je volitelné a má více kroků, které spolu souvisejí:

· na profilu se nastavuje, že profil je v oblasti řádkových práv vyhodnocován pomocí offline kopií dat: Adm02 / PV - práva k řádkům přes Elis51: Ano

· offline práva jsou generována procesní sestavou Elis51. Její spouštění zaevidujte na Adm53 a spouštějte ji jedenkrát denně, typicky ráno nebo v noci.
Sestava má parametry:
! Společný číselník struktur - hierarchický

! Zařazení PV do struktur

! Manažery struktur

! Kompetence na strukturách

Pro účely offline práv je zapotřebí potřeba nastavit první dva parametry. Přímo u Elis51 se to dělá checkboxy, v Adm53 se u parametrů
r_FillDataCstr, r_FillDataTpvStr nastaví/ponechá „1“, další 2 je možné pro účely práv dát na „0“.

Je k zvážení, u kterých profilů offline vyhodnocení nastavit – primárně je to určeno pro profily manažerů, resp. referentů s právy přes struktury (ST*). Je vhodné vše odzkoušet. Daní je, že práva jsou vyhodnocována k času spuštění, resp. dokončení sestavy Elis51. Její častější spouštění než 1x či dvakrát denně by mohlo působit výkonové potíže, nicméně principiálně možné je.

Na Adm10 je záložka Struktury offline, která dává nahlédnout do prvních dvou offline úložišť, na záložce je také online pohled do záznamů přiřazení manažerů struktury. Zde jsou používány online hodnoty, tj. ty, které jsou také z jiného pohledu na Str01, Str02 / „Manažer/Osoba v EGJE“.

Adm01 / Přístupná PV pak zobrazuje výsledek, tj. jaké osoby / PV bude mít uživatel na profilu přístupné.

Vytvoření a editace role

Roli vytvářením a editujeme na formuláři Adm03.

Role s čísly 1- 499 jsou ve správě Elanor a jsou pro uživatele needitovatelné.

Uživatelské role mají vyhrazený interval 500-999.

Často se používá, že uživatel má v profilu nějakou (nějaké) standardní roli elanor (1-499) a správce mu navíc přiřadí nějakou(é) roli nad 500, ve které práva přidává resp. ubírá práva ke standardním rolím. Ubírání práv se děje nastavením záporné hodnoty práva v uživatelské roli. Tedy např. přiřazení práva -2 Odnětí zápisu i čtení způsobí, že přiřazení práva zápisu a čtení definované ve standardní roli pro uživatele přestane být platné.

Práva přiřazujeme na záložce Práva k objektům. A zde na záložce Objekt nastavujeme Souhrnnou hodnotu přístupového práva. Pro formuláře dvojstupňově ( 0 nic / 1 čtení / 2 zápis i čtení), pro sestavy a procesy pak jednostupňově (0 nesmí spustit / 1 smí spustit). S tím obvykle vystačíme. Upozorňujeme, že souhrnná hodnota by měla obsahovat maximum z práv přiřazených případně na Podřízené objekty.

V případě nutnosti je možné u některých formulářů v záložce Podřízené objekty - editace nastavit práva i detailnějším částem formuláře (záložka, datový formulář, položka). Práva se zde nastavují jako kaskáda. Tedy od hrubého k jemnějšímu. Vyhodnocení pak pokračuje v této hierarchii, dokud je alespoň nějaké právo ( > 0) až k úrovni položka. Pro zjištění kódových označení si správce může příslušný formulář, k němuž nastavuje práva, spustit z příkazové řádky s parametrem „-edit“ (př. Opv01 -edit ). Následně ve formuláři vidí pojmenování jednotlivých komponent.

Tento aparát se používá i pro selektivní přiřazení hromadné změny.

Standardním režimem je, že uživatel má přístupné všechny části formuláře s výjimkou těch, které mu správce zakáže buď pomocí práv (Adm03), nebo pomocí konfigurace (Adm04)

Systém však od e201303 umožňuje také režimy 1 a 2. Jejich volba se provede v Adm03 položkou "Práva uvnitř formuláře - režim" s hodnotami

0 - Standard - dle typu práv

1 - Implicitně žádná práva na záložky a datové formuláře

2 - Implicitně žádná práva na nic včetně položek

Kde 0 je implicitní hodnota a indikuje standardní režim.

Režim 1 znamená, že správce vyjmenuje přístupné záložky a datové formuláře, zatímco položky datového formuláře budou přístupné všechny resp. ty, které nezakáže.

V režimu 2 je i položky třeba vyjmenovávat. Upozorňujeme, že pokud má mít uživatel přístup i pro zápis, je třeba mu přidělit všechny povinné položky (indikovány vykřičníkem před nadpisem) a položky, které jsou pro interní logiku a případné kontroly nezbytné.

Upozorňujeme, že některé části formulářů mohou mít povinné ovládací prvky, bez kterých nebude formulář funkční, popř. nebude zobrazovat data.

Nastavení je tedy citlivou věcí. Správci může pomoci si formulář zobrazit ve standardním klientovi z příkazové řádky s parametrem -edit kdy uvidí interní názvy částí formuláře a snadněji se poté v záložce Podřízené objekty - editace zorientuje.

Pro usnadnění jsme v nových režimech udělali automatické zpřístupnění panelů, které jsou také ve vnitřní struktuře formuláře uloženy.

Nastavený režim je tedy vždy třeba vyzkoušet. Nemůžeme garantovat, že všechny nastavené režimy práv budou funkční dle představ.

Uživatel může mít práva k formuláři zprostředkované více rolemi včetně podřízených objektů:

Od e201601 jsme upravili logiku zpracování této situace.

Před e201601 měla explicitně zadaná práva na Podřízený objekt přednost před právy zděděnými z nadřízeného prvku.

Od e201601 jsou oboje práva brána rovnocenně a i zděděná práva, pokud jsou vyšší než ta explicitně zadaná, se mohou uplatnit.

V praxi šlo obvykle o vyhodnocení práv na položky, kdy v jedné roli byla například zadána práva ke čtení přímo na konkrétní položky

(ať už to bylo v kterémkoliv z režimů "Práva uvnitř formuláře - režim" viz výše)

a v druhé roli bylo právo na zápis na celou záložku.

Před e201601 tedy vyhodnocení bralo přednostně ta čtecí práva zadaná na jednotlivé položky,

Od e201601 zohledňuje i zděděné právo, vyhodnocení bere to vyšší právo z obou, a tím jsou v tomto příkladu zápisová práva definovaná na celou záložku.

Od e201605 pak řešíme situaci Master tabulka + více detailových záložek, kdy jedna z nich je hlavní, přes kterou se obsluhují data master tabulky.

U Master-Detail se zohlední práva i na tuto hlavní detailovou komponentu. Pokud má uživatel k hlavnímu detailu práva pouze na čtení, celá Master-Detail bude také pouze pro čtení. Práva z detailu se ale nedědí na ostatní případné záložky v detailu, dědí se pouze ta práva, která jsou nastavená na celý Master-Detail.

Pokud tedy chcete například nastavit uživateli zápisová práva na Str01/Struktura hierarchicky/Manažer, nastavíte zápisová práva k MasterDetail (ZalStrHier), čtecí práva k Detail (ZalStrHierDetail) a zápisová práva k Manažerovi (cecstrmanaPan).

Pozn. MasterDetail (ZalStrHier) může také zdědit zápisová práva ze záložky Struktura hierarchicky (ZalStrHierPanel).

4 Upozornění

Seznam přístupných částí dokumentace je zde.