V zásade sa delí na interaktívne (používateľa zadáva meno a heslo) a SSO (Single Sign On, aplikácia sa snaží prevziať overenie z už vykonanej autentizácia v OS).

Možná je aj kombinácia, kedy aplikácie skúsi SSO a keď sa nepodarí, ponúkne používateľovi interaktívnu autentizáciu.

EGJE necháva autentizáciu užívateľov na externej autorite, tzv. Identity Provideru (IdP). S týmto IdP komunikuje prostredníctvom well-know protokolov, v tejto chvíli EGJE podporuje z týchto protokolov LDAP, NTLM, Kerberos, SAML, OIDC (pozri ďalej v texte). EGJE od tejto autority očakáva zabezpečenie overenia identity v súlade s platnou legislatívou (v CZ je to pre režim nižších povinností Vyhláška č. 410/2025 Zb., v SK Vyhláška č. 227/2025 Z. z.)

Poznámka 1: Odporúčame nepoužívať Windows účty s diakritikou.

Poznámka 2: Ak pracujeme s aplikačným serverom, je vyplnenie tejto záložky dôležité (na klientovi je bezpredmetné).

Po vykonaní zmien na tejto záložke je potrebné reštartovať AS resp. WEB EGJE server.

V konfigurátore na záložke Overenie sa dynamicky zobrazujú údaje potrebné pre zadanie autentizácie a to podľa vybraného druhu z číselníka. Podľa vybranej položky sa interaktívne zobrazí formulár s potrebnými údajmi. Pretože je potrebné (bez ohľadu na typ autentizácie) v niektorých prípadoch zadať LDAP autentizáciu (pre umožnenie práce s rôznymi zostavami a formulármi), je tu nastavenie LDAP autentifikácie zakotvené aj pre všetky typy autentifikácie.

Na záložke AS/WEB, v rámci režimu Web server je možné definovať Konfiguráciu pre mobilný prístup a nastavenie parametrov, napr. http adresa pre presmerovanie užívateľa, pokiaľ nemá žiadny priradený profil alebo napr. zoznam profilov povolených pre Web a pod.

2.1 Overenie - zvolený autentizačný mechanizmus.

2.1.1 mswin_ntlm

Realizované pomocou Microsoft security package.

Umožňuje SSO (prevzatie autentizácie od OS) ale iba pre MS Windows

(u inštalácie s AS/Web server platí podmienka OS Windows i pre nich)

Nevyžaduje žiadne ďalšie parametre.

AS/Web server musí bežať pod používateľom z domény.

Nastavenie u klienta AS - server je nutné zadávať menom a nie IP adresou.

Je možné použiť pre java klienta bez AS.

Ak sa nepodarí SSO prihlásenie, nasleduje autentizačný dialóg (s doménou).

2.1.2 mswin_ntlmOnly

Ak sa nepodarí SSO nasleduje ukončenie aplikácie

2.1.3 mswin_ntlmInteractive

Vždy autentizačný dialóg.

2.1.4 mswin_kerberos

Realizované pomocou Microsoft security package.

Prísnejšia autentizácia, ktorá skúsi najprv autentizačný protokol kerberos.

SSO ako mswin_ntlm.

Vyžaduje u domény nastavený service principal name SPN (utilita setspn) pre aplikáciu a používateľa:

§ utilita setspn (u windows serveru 2003 ju prípadne doinštalujte z inštalačného CD)

§ setspn.exe -A principal účet

kde principal je

HTTP/ServerName pro EGJEWEB,

EGJE/ServerName pro AS

účet účet, pod ktorým beží AS, resp. EGJEWEB

AS/Web server musí bežať pod používateľom z domény.

Nastavenie u klienta AS - server je nutné zadávať menom a nie IP adresou.

Ak sa nepodarí SSO prihlásenie, nasleduje autentizačný dialóg (s doménou).

2.1.5 mswin_kerberosOnly

Ak sa nepodarí SSO nasleduje ukončenie aplikácie

2.1.6 NTLogin2

autentizácia používateľa sa preberá z NT Windows autentizácie. Ak sa neprevezmez OS, prejde systém do režimu NTLoginInteractive

2.1.7 NTLogin2Only

dtto s tým, že je umožnené iba prevzatie prihlásenia z OS

2.1.8 NTLoginInternactive

s autentizačným dialógom (spoločné pre ntlm i ntlm2)

ak je server linux a overenie má byť SSO voči AD je možné použiť tieto autentizácie, zvládajú protokol NTLM2.

K ich použitiu je potrebné vyplniť parametre - pozri odsek 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

aplikácia voči ldap serveru (obyčajne MS Active directory položka userPrincipalName). Do položky LDAP/Web = implicitná doména používateľa sa potom zadáva doména (t.j. to čo je v userPrincipalName za znakom @ - používateľ to potom nemusí zadávať).

V tomto režime podporujeme iba SSL pripojenie.

2.1.13 LDAPSearch

podobne Only s tým, že v LDAP SSL URL je ešte navyše makro pre prihlásenie sa menom:
napr. Ldaps://xxxxxxx/dc=yyy,dc=cz
popis formátu (pozri http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/url.html

Pozn. filter zadávajte samostatne do špecializovanej položky LDAPSearch - filter.

a naviac môžu byť vyplnené položky:

LDAP - používateľ s právami na čítanie

LDAP - heslo používateľa s právami na čítanie

cez tohto používateľa sa potom aplikácia pripojí, prehľadá sa celý podstrom a vyhľadá sa v ňom autenizujúci sa používateľ.
Pokiaľ ldap server umožňuje anonymného používateľa, je možné položky nechať prázdne.

LDAPSearch - filter - Filter, uplatnený po prihlásení k LDAP serveru

(nutný pre Novell eDirectory)

napr uid =% username%

LDAPSearch – Atribút unikátnej identity užívateľa – Atribút v AD špecifikujúci hodnotu logname prihlasovaného užívateľa. V prípade nevyplnenia je ako logname v rámci EGJE použitá hodnota DN (Distinguished Name). Hodnota tohto atribútu, v prípade jeho vyplnenia, musí korešpondovať s makrom %username% uvedeným v rámci konfiguračnej položky LDAPSearch – filter. Pr. Nastavenie LDAPSearch – filter: (&(objectClass=person)(employeeNumber=%username%)), LDAPSearch – Atribút unikátnej identity užívateľa: employeeNumber

2.1.14 Kerberos

Oproti mswin_kerberos tu môže byť AS/Web na Linux serveri. Existujú dva typy autentizácie:

· kerberos – iba interaktívny

· kerberos_sso – najprv SSO, pokiaľ sa nepodarí tak interaktívny

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

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

Pre obe autentizácie je potrebné nastaviť krb5.conf súbor (konfigurácia realms). Pri tejto autentizácii je dôležité nastavenie DNS. Pri overovaní Linux voči Active Directory je vhodne, aby primárny DNS server bol doménový radič Active Directory.

Pokiaľ je potrebné, je možné povoliť staršiu a menej bezpečnú šifru rc4-hmac. Do [libdefault] v krb5.conf súboru vložiť allow_weak_crypto = true a pridať šifru do povoleného zoznamu. Avšak z bezpečnostných dôvodov sa toto neodporúča.

Ak sa nepovolí, môže byť potrebné pre daný účet povoliť novšie a bezpečnejšie AES šifry.

Nastavuje sa pomocou Group Policy pre Default Domain Policy a Domain Controllers Policy. V skupine Policy Management sa pre každú konfiguráciu nastavia v Configuration->Policies->Windows Settings->Security Settings->Local Policies->Security Options v Policy.

· začiarknuť Define these policy settings

· zaškrtnúť jednotlivé požadované šifry (odporúčané AES)

Ďalej je potrebné povoliť AES šifry pre Kerneros pre servisný účet. Vo vlastnostiach účtu v Accounts->Accounts options zaškrtnúť položky This account supports Kerberos AES XXX bit encryption.

Po nastavení bude potrebné zmeniť heslo a prípadne vygenerovať nový keytab súbor viď ďalej.

Príklad súboru 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

Nastavenie u klienta AS - server je nutné zadávať menom a nie IP adresou.

Pre Java klienta bez AS nie je režim vhodný.

Ak sa nepodarí SSO prihlásenie nasleduje autentizačný dialóg.

Je potrebné vytvoríš si v AD servisný účet pre preautentizáciu. K nemu je potrebné vytvoriť Service principal name (SPN).

Vytvára sa pomocou utilitky setspn:

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

kde principal je

• HTTP/ServerName pre EGJEWEB,

• EGJE/ServerName pre AS

účet - účet pod ktorým beží AS resp. EGJEWEB

Pre úspešné SSO prihlásenie je možné zvoliť jedno z dvoch nastavení.

Užívateľ pre preautentizáciu: Vyplní sa Užívateľ pre preautentizáciu a jeho heslo. Tento spôsob nie je odporúčaný na produkčnom prostredí.

Keytab súbor: Vytvorí sa login.conf súbor, ktorý bude obsahovať cestu ku keytab súboru a Principala služby registrovaného účtu v položke principal. Odporúčaný spôsob pre produkčné prostredie. Názvy sekcií musia zostať, ako sú definované v príklade. Práva ku keytab súboru by mal mať užívateľ pod ktorým sa Aplikačný alebo Webový server spúšťa.

Keytab súbor sa vygeneruje v DC pomocou 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 miesto kam sa súbor vygeneruje

principal:

• HTTP/ServerName pre EGJEWEB,

• EGJE/ServerName pre AS

realm - zadaná realm v krb5.conf

doména - vaša doména

účet – servisný účet

heslo - heslo k servisnému účtu

Pokiaľ je potrebné mať pod rovnakým účtom viac služieb (napr. EGJEWEB aj AS), je možné pridať do existujúceho keytab súboru heslo pre ďalší účet. Po vytvorení SPN sa zavolá príkaz pre generovanie keytab súboru kde sa mu ako parameter odovzdá pôvodne vygenerovaný keytab súbor:

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

Príklad súboru 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

Autentizácia OIDC (OpenID Connect) je teraz plne funkčná pre webového aj Java klienta. Na jej správne fungovanie je nevyhnutná registrácia aplikácie EGJE u poskytovateľa identity (Identity Provider – IdP), napríklad Microsoft Entra ID, OKTA.

V konfigurácii aplikácie EGJE je možné nastaviť nasledujúce spoločné položky:

· Vydavateľ (Issuer)

o URL adresa poskytovateľa identity, ktorá obsahuje registrovanú aplikáciu. Ide o povinnú položku. EGJE sa pokúsi z tejto adresy stiahnuť tzv. Discovery document a načítať z neho potrebné dáta.

· Discovery document

o Ak nie je možné automaticky stiahnuť Discovery document z URL poskytovateľa, je možné jeho obsah vložiť priamo do konfiguračného súboru.

· Adresa pre presmerovanie (Redirect URI)

o URL adresa aplikácie EGJE, na ktorú prebehne presmerovanie po úspešnej autentizácii v IdP. Táto adresa sa líši pre webového a Java klienta a musí byť uvedená aj v konfigurácii IdP.

§ Pre Web klienta: <adresa egjeweb2>/oidc/callback

§ Pre Java klienta: egjeapp://oidc-callback

· Client ID

o Klientske ID získané od IdP, slúžiace na identifikáciu aplikácie.

· Preferované užívateľské meno (Preferred Username)

o Názov claimu v ID tokenu, ktorý obsahuje prihlasovacie meno užívateľa (logname) pre EGJE. Ak nie je vyplnený, použije sa predvolená hodnota preferred_username.

· Nastavenie pre odhlásenie z IdP

o Voliteľná položka. Pri jej zaškrtnutí odošle EGJE po odhlásení požiadavku na odhlásenie aj do IdP. Správanie sa líši medzi klientmi:

§ Web klient: Odhlásenie musí byť vykonané tlačidlom. Prehliadač presmeruje užívateľa do IdP, kde prebehne odhlásenie, a potom späť na odhlasovaciu stránku EGJE.

§ Java klient: Pri odhlásení alebo zatvorení aplikácie je požiadavka odoslaná do IdP a aplikácia sa ukončí, bez ohľadu na stav odhlasovania.

Položky prepisujúce hodnoty z Discovery documentuy

Tieto položky umožňujú ručne prepísať hodnoty, ktoré EGJE automaticky stiahne z Discovery documentu.

· Verejné kľúče pre overenie podpisov (Public Keys)

o Discovery document obsahuje URL, odkiaľ je možné stiahnuť verejné kľúče na overenie podpisov. Ak ich server nemôže stiahnuť, je možné ich stiahnuť ručne a vložiť priamo do konfiguračného súboru.

Nastavenie pre jednotlivých klientov

Ďalšie nastavenia a procesy sa líšia pre každý typ klienta.

Web Klient

Webový klient podporuje tri režimy OIDC toku:

· Authorization Code Flow: Po presmerovaní z IdP si EGJE vymení autorizačný kód za prístupový token. Tento proces prebieha na strane servera EGJE, ktorý komunikuje priamo s IdP serverom.

· Authorization Code Flow with PKCE: Bezpečnejšia verzia predchádzajúceho toku s pridaním kľúča PKCE (Proof Key for Code Exchange), ktorý bráni zneužitiu autorizačného kódu.

· Implicit Flow: Prístupový token je vrátený priamo v rámci presmerovania (redirect) v tele požiadavky (POST). EGJE server v tomto prípade nekomunikuje priamo s IdP serverom.

Doplnkové nastavenia pre Web klienta:

· Client secret: Nutné pre získanie tokenu pomocou Authorization Code Flow.

· Adresa pre presmerovanie po odhlásení (Post-logout Redirect URI): Adresa, na ktorú IdP presmeruje užívateľa po úspešnom odhlásení. Typicky sa vyplní <adresa egjeweb2>/wp/logout.html, ale je možné použiť aj vlastnú adresu. Táto hodnota musí byť tiež vyplnená v IdP.

Java Klient

Tento klient nemá žiadne vlastné dodatočné nastavenia. Pri spustení EGJE sa užívateľovi v prehliadači otvorí prihlasovacia stránka IdP. Po úspešnej autentizácii je aplikácia presmerovaná späť a užívateľovi je ponúknutá možnosť spustiť EGJE z prehliadača. Potom si klient EGJE stiahne token priamo zo servera IdP a použije ho na autentizáciu.

Tento proces využíva Authorization Code Flow with PKCE, čo je odporúčaný spôsob pre natívne aplikácie. Po spustení aplikácie musí používateľ prázdnu stránku v prehliadači zavrieť. Podobne funguje aj proces odhlásenia.

2.1.17 SAML

Overenie voči serveru spĺňajúcemu štandard SAML2. Nastavenie autentizácie sa líši pre Java klienta a EGJEWEB2.

Slovník pojmov:

SP – Service provider – webová aplikácia EGJE

IdP – Identity provider – dôveryhodný systém overujúci identitu používateľa

Metadata – XML súbor dodaný IdP obsahujúci nastavenia potrebné pre výmenu SAML requestov

SP Metadata - XML súbor generovaný EGJE, obsahujúci nastavenia pre dodanie do IdP

SSO – Single Sign On – jednotné prihlásenie do viacerých SP

SLO - Single Logout - jednotné odhlásenie aj IdP a všetkých podporujúcich SP

jks – Java KeyStore – úložisko na ukladanie digitálnych certifikátov

EGJEWEB2:

Vo Vašom Identity Provideri je potrebné nastaviť koncový endpoint, na ktorom EgjeWEB prijme SAML Token. Tvar endpointu je nasledujúci: https://<egjewebURL>/saml/SSO (pozor, je to case sensitive).

V Identity Provideri môže byť táto konfiguračná položka označená ako Single-Sign-On URL, Destination URL, záleží na Vašom Identity Provideri.

Ďalej potom je potrebné v konfigurácii EGJE nastaviť v rámci zvolenej autentizácie SAML nasledujúce položky:

SP Entity ID: Vami zvolený identifikátor Vašej aplikácie EgjeWEB. Parameter nastavujete v rámci Vášho Identity Providera. Názov položky v IdP sa môže líšiť, napr. Audience alebo Audience Restriction. Záleží na Vašom IdP. Podľa hodnoty, ktorú nastavíte v IdP, nastavte potom zodpovedajúcu hodnotu aj v konfigurácii EgjeWEB.

IDP SSO URL: Adresa pre začatie automatického prihlásenia iniciovaného zo strany IdP. Položka je nepovinná, pokiaľ nebude nastavená, pre prihlásenie užívateľov bude použité prihlásenie iniciované zo strany SP (Service Providera) alebo EgjeWEBU. Nastavte tu teda adresu aplikácie, ktorú Vám musí dodať Váš IdP, pokiaľ budete aplikovať SSO iniciované Vaším IdP, v opačnom prípade ponechajte prázdne. Pozor, adresou aplikácie sa tu nemyslí adresa Vašej aplikácie EgjeWEB, ale adresa v rámci IdP, cez ktorú je možné sa na aplikáciu EgjeWEB prostredníctvom IdP dostať.

Adresa Web aplikácie: Externá adresa, na ktorej je prevádzkovaná aplikácia EGJEWEB, mala by sa zhodovať s adresou, na ktorú IdP zasiela výsledok prihlásenia, bez koncového /saml/SSO.

IDP metadáta: XML dokument s metadátami IdP. Dokument Vám vydá Váš IdP. Pre ADFS v Elanore je tento dokument možné získať z adresy http://fsso.domena.cz/federationmetadata/2007-06/federationmetadata.xml.

IDP metadáta – cesta: URL adresa ku XML dokumentu s metadátami IdP. Z tejto adresy si EgjeWEB2 pri spustení stiahne dokument s metadátami.

Interval pre obnovu metadát v CRON formáte: Interval nastavujúci obnovu súboru s metadátami bez nutnosti reštartu aplikácie. V prípade potreby je možné obnovu vykonať u ručne na Adm51/Správa AS/klienta/Web tlačidlom Prenačítať SAML metadáta.

Pri parametri je tlačidlo na kontrolu CRON formátu či je zadaný správne a aplikácia ho dokáže prečítať.

EGJE umožňuje používateľom špecifikovať si vlastný Java Keystore s certifikátmi, ktoré sa použijú na šifrovanie, resp. dešifrovanie SAML Tokenov. Na manipuláciu s keystorom sa používa utilita keytool, ktorá je súčasťou používanej Javy.

Do keystoru je nutné pod nejakým aliasom vygenerovať pár kľúčov, privátny a verejný. Privátny kľúč použije EgjeWEB na dešifrovanie tokenu, ktorý je zašifrovaný Vaším IdP, verejný kľúč je nutné odovzdať Vášmu IdP. IdP použije verejný kľúč na zašifrovanie Tokenu pred odoslaním tokenu do EgjeWEBu. Príklad použitia utility keytool pre vygenerovanie páru kľúčov:

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

Vyššie uvedený príkaz vygeneruje pár kľúčov pod aliasom spring, heslo ku kľúču je secret, heslo ku store je tiež secret, platnosť certifikátu je 365 dní, použitý šifrovací algoritmus je RSA, veľkosť kľúča je 2048 bitov. Keystore sa nachádza v súbore ./keystore2.jks. Ak takýto súbor ešte neexistuje, bude vytvorený nový.

Vygenerovaný certifikát v keystore je možné zobraziť príkazom

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

Zobrazený certifikát následne vložte do Vášho IdP.

Dokumentácia k utilite Java Keystore Javy 11 je k nájdeniu tu:

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

Na strane konfigurácie EgjeWEBu je nutné potom vyplniť nasledujúce položky:

Cesta pre uloženie jks súboru: Zadajte tu cestu k súboru, kde sa nachádza Java Keystore s certifikátmi pre šifrovanie/dešifrovanie SAML Tokenov. Tu zadaný súbor bude potom priamo vložený do konfiguračnej jari. Ak vykonáte akúkoľvek zmenu v keystore, je nutné nahrať súbor do konfigurácie znovu a reštartovať webový server, aby sa zmena v keystore prejavila v aplikácii. Podobne sa manipuluje napríklad aj so súborom obsahujúcim metadáta IdP.

Alias pre kľúč: Alias, pod ktorým je certifikát v keystore uložený

Heslo ku store: Heslo ku keystore

Heslo ku kľúču: Heslo k privátnemu kľúču, ktorý bude slúžiť na dešifrovanie SAML Tokenu na strane EGJE.

Ak si neželáte šifrovať SAML Tokeny, môžete nechať uvedené konfiguračné položky nevyplnené.

Ďalšie voliteľné parametre:

NameID format: Je možné nastaviť formát NameID, ktorý sa bude posielať v SAML AuthnRequest. Je potrebné nastaviť presnú hodnotu.

Vytvoriť SP metadáta: Vytvorí endpoint pre generovanie SP Metadat obsahujúci aktuálne nastavenia. Endpoint sa skladá z Adresa Web Aplikácie/saml/metadatá. Tlačidlo Vytvoriť metadáta zobrazí aktuálne metadáta. Viac o nastavení viď Generovanie SP Metadat.

Logname element: Nastavuje atribút, z ktorého sa má načítať logname pre prihlásenie do EGJE zo SAML Assertion.
Predvolená hodnota je Subject/NameID.
Ak sa použije AttributeStatement, je potrebné vyplniť položku „Názov atribútu obsahujúceho logname“.

Názov attributu obsahujúcého logname: Obsahuje názov custom atribútu obsiahnutého v elemente „AttributeStatement“ v SAML Assertion pre zistenie logname. Zadáva sa názov obsiahnutý v atribúte „Name“ v elemente „Attribute“.

Vždy pri spustení EGJE vynútiť overenie: Pridá k SAML requestu parameter forceAuthn=true. Pri novom otvorení EGJE sa vždy vynúti pri IdP nová autentizácia. IdP musí tento parameter podporovať a musí byť povolený. Názov položky v IdP sa môže líšiť, napr. Honor Force Authnentication.

Pri odhlásení z EGJE odhlásiť aj z IdP: Pri odhlásení z EGJE, sa zároveň odošle request pre Single Logout z IdP. Tým sa užívateľ odhlási z IdP a zároveň zo všetkých aktuálne prihlásených SP, ktoré túto funkciu podporujú. V IdP je potrebné SLO povoliť a nastaviť pre neho URL: https://<egjewebURL>/logout/saml2/slo (pozor, je to case sensitive). Ďalej je potrebné nastaviť SP Issuer na rovnakú hodnotu ako je nastavené SP Entity ID.

Logovať SAML: Zapne úroveň logovania pre SAML knižnice na úroveň debug. Loguje veľké množstvo dát a log sa tak stáva neprehľadným. Odporúčame zapínať iba pri riešení problémov so SAML autentizáciou.

Java klient:

Vo Vašom Identity Provideri je potrebné nastaviť koncový endpoint, na ktorom klient EGJE prijme SAML Token. Tvar endpointu je nasledujúci: http://localhost:<saml_port>/saml/SSO (pozor, je to case sensitive).

V Identity Provideri môže byť táto konfiguračná položka označená ako Single-Sign-On URL, Destination URL, záleží na Vašom Identity Provideri.

Ďalej potom je potrebné v konfigurácii EGJE nastaviť v rámci zvolenej autentizácie SAML nasledujúce položky:

SP Entity ID: Vami zvolený identifikátor Vašej aplikácie EGJE AS. Parameter nastavujete v rámci Vášho IdP. Názov položky v IdP sa môže líšiť, napr. Audience alebo Audience Restriction. Záleží na Vašom IdP. Podľa hodnoty, ktorú nastavíte v IdP, nastavte potom zodpovedajúcu hodnotu aj v konfigurácii EGJE AS.

IDP metadáta: Xml dokument s metadátami IdP. Dokument Vám vydá Váš IdP. Pre ADFS v Elanore je tento dokument možné získať z adresy http://fsso.domena.cz/federationmetadata/2007-06/federationmetadata.xml.

IDP metadáta – cesta: URL adresa ku xml dokumentu s metadátami IdP. Z tejto adresy si EGJE AS pri spustení stiahne dokument s metadátami.

Interval pre obnovu metadát v CRON formáte: Interval nastavujúci obnovu súboru s metadátami bez nutnosti reštartu AS. Pri parametri je tlačidlo na kontrolu CRON formátu, či je zadaný správne a aplikácia ho dokáže prečítať.

Pre podpisovanie SAML requestov je potrebné špecifikovať Java Keystore s certifikátmi, ktoré sa použijú na šifrovanie, resp. dešifrovanie SAML Tokenov. Na manipuláciu s keystorom sa používa utilita keytool, ktorá je súčasťou používanej Javy.

Do keystoru je nutné pod nejakým aliasom vygenerovať pár kľúčov, privátny a verejný. Privátny kľúč použije EGJE AS na dešifrovanie tokenu, ktorý je zašifrovaný Vaším IdP, verejný kľúč je nutné odovzdať Vášmu IdP. IdP použije verejný kľúč na zašifrovanie Tokenu pred odoslaním tokenu do EGJE AS. Príklad použitia utility keytool pre vygenerovanie páru kľúčov:

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

Vygenerovaný certifikát v keystore je možné zobraziť príkazom

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

Zobrazený certifikát následne vložte do Vášho IdP.

Dokumentácia k utilite Java Keystore Javy 11 je k nájdeniu tu:

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

Na strane konfigurácie EGJE AS je nutné potom vyplniť nasledujúce položky:

Cesta pre uloženie jks súboru: Zadajte tu cestu k súboru, kde sa nachádza Java Keystore s certifikátmi pre šifrovanie/dešifrovanie SAML Tokenov. Tu zadaný súbor bude potom priamo vložený do konfiguračnej jari. Ak vykonáte akúkoľvek zmenu v keystore, je nutné nahrať súbor do konfigurácie znova a reštartovať AS, aby sa zmena v keystore prejavila v aplikácii. Podobne sa manipuluje napríklad aj so súborom obsahujúcim metadáta IdP.

Alias pre kľúč: Alias, pod ktorým je certifikát v keystore uložený

Heslo ku store: Heslo ku keystore

Heslo ku kľúču: Heslo k privátnemu kľúču, ktorý bude slúžiť na dešifrovanie SAML Tokenu na strane EGJE.

Ak si neželáte šifrovať SAML Tokeny, môžete nechať uvedené konfiguračné položky nevyplnené.

Port pre SSO/SLO: číslo portu, na ktorom lokálny server počúva pre presmerovanie do IdP a späť. Zadaný port musí byť súčasťou URL pre SSO a SLO endpointy.

Ďalšie voliteľné parametre:

NameID formát: Je možné nastaviť formát NameID, ktorý sa bude posielať v SAML AuthnRequest. Je potrebné nastaviť presnú hodnotu. Ak sa nevyplní, použije sa hodnota urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Vytvoriť SP metadáta: Vytvorí endpoint pre generovanie SP Metadat obsahujúci aktuálne nastavenia. Endpoint sa skladá z http://<adresa_as>:<saml_metadata_port>/saml/metadata. Tlačidlo Vytvoriť metadáta zobrazí aktuálne metadáta. Viac o nastavení viď Generovanie SP Metadat.

Port pre generovanie SP metadát: port na ktorom sa spustí server pre generovanie SP metadát.

Názov attributu obsahujúceho logname: Obsahuje názov vlastného atribútu obsiahnutého v elemente „AttributeStatement“ v SAML Assertion pre zistenie logname. Zadáva sa názov obsiahnutý v atribúte „Name“ v elemente „Attribute“.

Vždy pri spustení EGJE vynútiť overenie: Pridá k SAML requestu parameter forceAuthn=true. Pri novom spustení EGJE sa vždy vynúti pri IdP nová autentizácia. IdP musí tento parameter podporovať a musí byť povolený. Názov položky v IdP sa môže líšiť, napr. Honor Force Authnentication.

Pri odhlásení z EGJE odhlásiť aj z IdP: Pri odhlásení z EGJE, sa zároveň odošle request pre Single Logout z IdP. Tým sa užívateľ odhlási z IdP a zároveň zo všetkých aktuálne prihlásených SP, ktoré túto funkciu podporujú. V IdP je potrebné SLO povoliť a nastaviť pre neho URL: http://localhost:<saml_port>/saml/SLO (pozor, je to case sensitive). Ďalej je potrebné nastaviť SP Issuer na rovnakú hodnotu ako je nastavené SP Entity ID. Pre odhlásenie z IdP je potrebné mať vyplnený keystore na podpísanie SAML tokenov.

Podpísať SAML SSO Request: Podpíše SAML request pre prihlásenie. Využíva sa pre IdP, ktoré nepodporujú nastavenie atribútu WantAuthnRequestsSigned v metadátach z IdP. Na podpísanie je potrebné mať vyplnený keystore.

Logovať SAML: Zapne úroveň logovania pre SAML knižnice na úroveň debug. Loguje veľké množstvo dát a log sa tak stáva neprehľadným. Odporúčame zapínať iba pri riešení problémov so SAML autentizáciou.

Generovanie SP metadát:Okrem základného generovania metadát je možné parametricky doplniť dodatočné informácie. Na ich doplnenie je nutné ručne upraviť súbor config_local.properties v archíve config_egje.jar. Pre tieto atribúty možno obvykle nastaviť viac hodnôt napríklad pre každý jazyk vlastnú hodnotu.

Aby sa správne zobrazovala čeština, je potrebné upravovať súbor v kódovaní ISO-8859-1.

Doplniť je možné nasledujúce oblasti:

o UIInfo – Element UIInfo v elemente Extensions

§ Slúži na dodatočné nastavenie informácií o spúšťanej aplikácii.

§ Nastaviť možno tieto elementy: Description, DisplayName, InformationUrl.

§ Pre každý element sa nastaví atribút lang obsahujúci jazyk, pre ktorý sú informácie vyplnené.

§ Príklad nastavenia v properties:

saml_extensions_uiinfo[0].displayname=EGJE CZ

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

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

saml_extensions_uiinfo[0].lang=cs

o Organization

§ Slúži na dodatočné nastavenie informácií o organizácii.

§ Nastaviť možno tieto elementy: name, displayname, url.

§ Pre každý element sa nastaví atribút lang, obsahujúci jazyk, pre ktorý sú informácie vyplnené.

§ Príklad nastavenia 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

§ Slúži na zadanie kontaktnej osoby.

§ Nastaviť možno tieto elementy: company, given_name, sur_name, email_address, telephone_number.

§ E-mailové adresy aj telefónne čísla je možné zadať pre daný kontakt viackrát za pomoci indexov.

§ Pre daný typ kontaktu je možné nastaviť atribút contactType.

§ Príklad nastavenia 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 boli zrušené v e202409 a od e202411 sa pomocou nich nejde do EGJE prihlásiť.

Autentizácie NTLogin2* sú tu iba pre spätnú kompatibilitu. Neodporúčame ich používať.

Autentizácie NTlogin3 však bezpečnostné kritériá spĺňajú a pre OS linux sú vhodné. Tieto autentizácie využívajú novší SMB2 protokol.

SSO autentifikácia (NTLogin3 a NTLogin3Only) nepoužíva zabezpečený secure channel pre NETLOGON komunikáciu s doménovými controllermi. Pre správnu funkčnosť je pre servisný NTLM účet potrebné použiť nezabezpečené Netlogon pripojenie viď. 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 sprevádzkovanie zabezpečenej komunikácie pracujeme a bude podporovaná v ďalšej verzii IS

EGJE.

IP adresy doménových radičov (NT Login)
IP adresa autentizačného servera pre NT login - ak ich je viac, tak sú oddelené čiarkou - použitý je

potom prvý, ktorý je spustený. Ak nie je vyplnený, tak použiť radič, zistený z NT login implicitnej domény.

V praxi je niekedy výhodné zadať iný server ako doménový radič, ktorý volanie sprostredkuje (SSO u Web aplikácie s doménovym radičom Windows 2003)

NT login implicitná doména - predvyplnenie položky doména u NT login

Pro NTlogin2 je potrebné vyplniť parametre:

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

Účet počítača pre pripojenie k DC (NT Login2)

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

Účet počítača pre pripojenie k DC (NT Login2) - Heslo
Password of computer account (NT Login2) (ntlm2ServerPassword)

Viacej technických informácií o NTlogin2 je možné získať na webu u knižnic

jespa-1.1.21 Jespa_Operators_Manual.pdf

Je tu dobre popísané vytvorenie computer account v AD, ktorý je pre NTlogin2 potrebný.

Pozn. Knižnice jespa EGJE nepoužíva, nie je teda potrebná ich licencia.

Stručne je postup vytvorenia computer account nasledujúci:

· vytvorenie účtu nejakou zo štandardných utilít (Active Directory Users and Computers (ADUC) MMC Snap-In.)

Maximálne 15 znakov z A-Z, a-z, 0-9, "-", "_"

· nastavenie hesla - z príkazového riadku scriptom

prvým parametrom je meno účtu nasledované znaky $ a @ DNS doménovým menom a druhým heslo

pr. C: \ tmp> SetComputerPassword elanor1$@firma.corp heslo

Heslo musí byť iné ako meno účtu.

Úspešné prevedenie indikuje hláška "The password was set successfully".

2.1.19 smart_card

Autentizácia je k dispozícii od e201905 pre java klienta, od e201909 aj pre web klienta.

Ide o tzv. 2-faktorovú autentizáciu, kedy klient pre prihlásenie potrebuje vsunúť kartu do čítačky a zadať heslo, ktoré EGJE overí voči certifikátu na karte.

Systém sme vyvinuli a testovali na čítačke a karte predá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 používateľ zaeviduje pomocou formulára Opv51 - Osobný certifikát, pričom vlastný verejný kľúč je uložený do úložiska spoločného s Opv31 (ako uchaz_dok_typ 51 - Osobný certifikát I.).

To slúži pre túto autentizáciu namiesto štandardného Adm10 / Logname, ktoré používajú všetky ostatné autentizácie.

Pro túto autentizáciu sú v sekci Smart Card ďalšie parametre:

- Zdroj certifikátov: combo Čipová karta/Osobný certifikáty užívateľa

- Certifikačná autorita: certifikát autority v binárnom formáte. Ak je vyplnené, je možno pre autentizáciu použiť iba certifikáty touto autoritou vydané.

- Meno v certifikátu sa musí zhodovať s menom v EGJE - checkbox

Kontrola zhody Mena a Priezviska - certifikát, vs. Osb02.

V EGJEWeb je táto autentizácia funkčná pre tomcat + Chrome nebo EDGE.

Vo Firefoxu tieź funguje, ale je potrebné nastaviť PKCS#11 modul v konfigurácii.

Pričom tu je hláška Firefoxu pre zadanie pinu, ktorá je trocha odtažitá: "Please enter the master password for the 9203050100050786."

Príklad konfigurácie tomcatu pre túto autentizáciu:

<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 pre zmenu hesla pomocou LDAP a autentizáciu LDAP:

LDAP - SSL URL á

adresa a port ldap servera, napr. ldaps://xxxx:636

resp. adresa port i koreň, pod ktorým sú používatelia systému (môžu byť i v podriadených uzloch)
napr. ldaps://prgxx1:636/OU=Country.Czech,OU=ElanorUsers,DC=myorg,DC=cz

LDAPSearch - filter

aditívny filter

použije sa typicky s Novell eDirectory resp. s Microsoft AD resp. všade tam kde filter nie je možné písať priamo do prihlasovacieho reťazca LDAP - SSL URL.

napr. uid=%username%

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

LDAP-špeciálny používateľ pre prácu s LDAP (+ heslo)
používateľ použitý pre prihlásenie a prechádzanie LDAP servera resp. pre činnosť v rámci správy používateľov Adm12.

používateľ je tiež použitý pri zmene hesla v AD po jeho expirácii (resp.první prihlásení)

zvyčajne musí byť uvedený aj s doménou

napr. ldapadmin@myorg.cz

LDAP/Web - implicitná doména používateľa

doména, ktorá sa doplňuje pri prihlásení za používateľské meno (typicky pre LDAPOnly), napr. myorg.cz

Web - ldap base s maxPwdAge (zmena hesla)

ldap adresa pre zistenie maximálnej doby platnosti hesla, napr. dc=myorg,dc=cz

Ide o varovanie pred expiráciou hesla.

Zisťovanie sa vykonáva len pre LDAPOnly a pre používateľov, ktorí majú právo na Xpw01.

Pozn. V EGJE implementovaná aj zmena hesla po expirácii, pozri vyššie.

LDAP/Web - doba (počet dní) predstihu pred vypršaním hesla

doba po uplynutí ktorej, systém vyžaduje zmenu hesla

Web - telefón na správcu – je zobrazený v prípade, keď vypršalo heslo

Web - e-mail na správcu – je zobrazený v prípade, keď vypršalo heslo

LDAP/Web - správa – keď heslo nespĺňa pravidlá

správa, ktorou systém odpovie v prípade, že novo zadané heslo (pri zmene hesla) nespĺňa podmienky, ktorým má heslo zodpovedať

Pozn. Ďalšie parametre pre vytváranie používateľa v LDAP repository (form. Adm12) sú v Adm21/Konfiguračné parametre/Vytváranie používateľov LDAP/AD.

Súbor s požiadavkami na reset hesla (úplná cesta):

EGJE Web umožňuje z adresy

http://xxxxxx/egjeweb2/ref/resetpass

generovať textový súbor s požiadavkami na reset hesla. Tento parameter udáva plnú cestu k tomuto súboru (následné premietnutie súboru, napríklad do Active Directory už aplikácia nerieši).

WEB / http adresa - presmerovanie - užív. nemá profil:

je parameter, ktorý použije aplikácia EGJEWEB v prípade, že dôjde síce k overeniu používateľa, ale tomu správca nepriradil žiadny aplikačný profil pre prístup do EGJE. V takomto prípade aplikácia presmeruje prehliadač na túto adresu, kde predpokladáme, že sú uvedené organizačné informácie, ako sa má používateľ ďalej zachovať.

Výpočet profilov povolených pre WEB.

Z tejto konkrétnej inštalácie EGJEWeb2 sa potom pôjde prihlásiť len na uvedené zamestnanecké, manažérske alebo referentské profily. Ide o regulárny výraz. Napr. . MANA.*|ZAME.* znamená profily s kódmi začínajúcimi MANA alebo ZAME.

Nekontrolovať e-mailovú adresu odosielateľa

Nastavenie, či chcete vykonať kontrolu formálnej správnosti adresy odosielateľa mailu (obvykle firemný mail osoby používateľa - Osb02)

2.2 Konfigurácia pre mobilný prístup

Pre prístup z mobilov / tabletov vrátane sprístupnenia mimo intranet či doménu môže byť v organizácii špeciálna inštalácia EGJEWeb2.

Tu môže byť zadané špeciálny overenie "Mobile", ale môže tu byť aj iné overenie, ale pre prehliadače mobilov / tabletov s mobilným user agentom je rovnako vždy používané overenie Mobile.

Ak teda správca u servera zadá overenie Mobile, nie je dovolené žiadne iné overenie. Aj používatelia PC potom podliehajú mobilnému overenie. Čo môže byť využité pre niektoré externé prístupy aj z PC.

Zabezpečenie aplikácie má potom trochu inú štruktúru:

- Tu v Configurator / AS,WEB-režim Web server je možné zadať "Zoznam, profilov povolených pre WEB".

Z tejto konkrétnej inštalácie EGJEWeb2 sa potom pôjde prihlásiť len na uvedené zamestnanecké, manažérske alebo referentské profily. Ide o regulárny výraz. Napr. MANA. * | ZAME. * Znamená profily s kódmi začínajúcimi MANA alebo ZAME.

Pozn. Obmedzenie platí pre celú EGJEWeb2 teda aj pre prístupy z PC tj. cez nejaké iné overenie (napr. Mswin_ntlm i.)

- Adm02 / Povolené pre autentizáciu mobil / tablet - ktorý profil smie dostupný byť z mobilu tj. mobilnou autentizáciou (plošne pre všetky EGJEWeb2)

- Adm10 / Povolenie prístupu z mobilných zariadení - ktorá osoba môže pristupovať do aplikácie z mobilu / tabletu (tj. pomocou mobilného overenia).

- Adm16 - Správca alebo Manažér či iný používateľ so zadaným mobilným profilom a povolením tu (teda z overeného používateľa) vytvorí dočasné heslo pre vytvorenie autentizácie v konkrétnom zariadení a konkrétnom prehliadači v ňom (pozor treba ho mať v režime "mobilný user agent" tzn. nemať napr. v mobilnom Chrome zaškrtnuté "Verzia webu pre PC").

Heslo si môže do mobilného zariadenia (ak má ho práve v ruke) rovnou opísať, alebo ho odoslať na e-mail zadaný personalistom v Osb02 (druh komunikácie 31) - tlačidlo "Pošli heslo e-mailom".

Pozn.: Ak má používateľa viac mobilných zariadení alebo ho menia je vhodné si tieto prístupy evidovať s menom zariadení.

- Pokiaľ má používateľ tento e-mail prístupný v mobilnom zariadení, je sprevádzkovanie najpriamočiarejšie. Otvorí si e-mail a klikne na link v ňom. Ten už jednorazové heslo obsahuje a aplikáciu v konkrétnom mobilnom zariadení sprevádzkujú.

Ak nie, zadá v mobilnom prehliadači adresu aplikácie a do jedinej v tú chvíľu zobrazené položky zadá jednorazové heslo.

Zároveň je v oboch prípadoch vhodné si rovno z mobilného prehliadača odkaz na aplikáciu pridať na plochu a nabudúce ju už spúšťať odtiaľto.

- Jednorazové heslo je dočasné, pri jeho generovaní sa zadáva jeho platnosť (štandardne 10 minút).

- Keď používateľ mobilné zariadenie stratí, je potreba z EGJE čo najrýchlejšie v Adm16 prístup pomocou tohto zariadenia zneplatniť (tlačidlo zneplatní prístup)!

Prípadne, ak má používateľ zariadení viac a nie je jasné, ktoré je ktoré, tak zneplatniť všetky resp. zrušiť v Adm10 používateľovi mobilné povolenie úplne.

- Priamo v mobilnej aplikácii má používateľ voľbu "Zrušenie prístupu z mobilného zariadenia" (nad voľbou Odhlásenie). Po dotazu sa potom prístup z konkrétneho prehliadača konkrétneho mobilného zariadenia zneplatní zhodne ako vyššie uvedenú akciou "zneplatní prístup" z Adm16 resp. zmazaním riadku s evidenciou prístupu tamtiež.

Pozn .: v Adm21 / Parametre komunikácie je parameter "http (s) adresa EGJEWeb2 pre mobilný prístup:" Táto adresa je použitá v Adm16 pri akcii Pošli heslo e-mailom. V e-maile je link zložený z tejto adresy a parametra - jednorazového hesla.

Možnosť vypnutia mobilné autentizácie.

V konfigurácii sprístupňované utilitou Configurator je na záložke AS,WEB-režim Web server parameter (v poradí druhý)

Pre mobilné zariadenia (podľa user agent) použiť vždy autentizáciu Mobile Áno / Nie.

Jeho nastavenie na Nie potom spôsobí, že aj z mobilných zariadení, ktoré sa prehliadači hlási ako

user agent = mobile, sa bude volať tá autentizácia, ktorá je uvedená o riadok vyššie v položke autentizácia.

3 Nastavenia prístupových práv v aplikácii

Priradenie / Vytvorenie používateľa

Ak Osoba používateľa / referenta ešte v db nie je a nemá v nej ako zamestnanec, zakladáme ju pomocou sprievodcu Adm01p. Takto ju vytvoríme ako osobu s PV so statusom 21.Používatelia referenti, zamestnanci, manažéri, ktorí sú v db už evidovaní (obvykle ako zamestnanci), nemusia mať špeciálny používateľský PV. Špecifikáciu atribútov používateľa potom zadáme pomocou formulára Adm01, resp. Adm10.

U používateľa zadáme profil a jazyk, prípadne obmedzenie na Organizáciu a pomocou zadania "Profil - autentizácia" prepojíme autentizáciu s Osobou v db. Autentizačné prihlasovacie meno (mená) zadávame v tomto (týchto) tvaroch:

Autentizácia Windows NT

WinDoména\používateľ napr. MOTOR\jigecz

Autentizácia kerberos, LDAP

uživateľ@doména napr. jigecz@motor.cz

Autentizáciu používateľa buď preberá z operačného systému (SSO) alebo ju interaktívne zadá (meno heslo). Režim sú popísané v predchádzajúcej kapitole Nastavenie - configurator_egje.

U každého priradení profilu vypĺňame jazyk používateľského rozhrania.

Upozornenie: v štátnej správe všetkom vypĺňame jazyk "cs_ST" namiesto štandardného "cs".

Vytvorenie a editácia profilu

Profil vytvárame a editujeme na formulári Adm02.

3.1 V profile na prvej záložke definujeme typ prihlásenia a prístupové práva k riadkom:

· Typ prihlásenia - rozlíšenie medzi personálnym prihlásením sa ku dňu a mzdárskym prihlásením sa k obdobiu.

Zároveň položka definuje ponúkanie dáta pri editácii časovo sledovaných položiek.

K dispozícii sú typy:

1 Prihlásenie k dátumu - zmena časových údajov od 1.tohoto mesiaca

2 Prihlásenie k obdobiu - zmena časových údajov od 1.zvoleného obdobia

3 Prihlásenie k dátumu - zmena časových údajov od ref.data

4 Prihlásenie k dátumu - zmena časových údajov od 1.násl.měsíce

5 Prihlásenie na obdobie - zmena časových údajov od 1.násl. obdobie

· Typ GUI - pre aké UI je profil určený. Hodnoty sú:

1 - Java a Web klient - rozhranie referent

2 - Starý Web klient

3 - Web klient - rozhranie referent

4 - Java klient - rozhranie referent

11 - HR portál - rozhranie zamestnanec samostatne predávaný produkt

12 - HR portál - rozhranie manažér samostatne predávaný produkt

21 - Iba WS - Bez prístupu do UI EGJE, prístup len webovou službou

Práva podľa SO a SJ, použité aj pre obmedzenie práv k osobám a PV

· SJ, resp. SO pre obmedzenie práv - organizácia je (resp. môže byť) rozdelená na spravované jednotky (SJ) a spravované oddiely (SO). SJ je rozdelením navonok - je náprotivkom rôznych inštitúcií typu Zdravotná poisťovňa, Finančný úrad atď.
Skladá sa z minimálne jedného SO (ale môže ich byť i viac).
SO je rozdelením pre spracovanie miezd. Pre SO definujeme výplatný termín, na SO vykonávame hromadné výpočty a uzávierky.
Upozornenie: Pre zrýchlenie spracovania práv k riadkom odporúčame SJ, SO na profile, tam kde je to možné, uvádzať, spracovanie práv je potom rýchlejšie a premietne sa aj do ponukových ComboBox SJ a SO, v ktorých je ponuka SJ alebo SO a nie osoby a PV.

· U zamestnaneckého, manažérskeho ale aj u niektorých referenčných profilov, ktoré idú cez celú organizáciu, by vyplňovanie SJ, SO viedlo k tomu, že by sa profily museli vytvárať pre každý SO zvlášť.

Aby to nutné nebolo, je pre tieto prípady vhodné použiť nastavenie atribútu "Chýbajúce práva na SJ, SO určiť z príst. Osôb / PV:" = Áno.

Pracuje to tak, že sa prejdú všetky PV, na ktoré má používateľ práva a zistí sa ich všetky SO, SJ a Legislatívy. Tieto sa potom zoberú a tvoria obmedzenia používateľa v týchto troch parametroch a tiež potom obmedzujú ponukové comboboxy SJ a SO.

· SJ (SO) sprístupniť i nezaradených - definícia má význam pre tie typy PV, ktoré sa na SO nepriraďujú (používateľ, lektor, uchádzač...). Nastavením na „Áno“ sa takéto osoby (PV) stanú viditeľnými.
(Priradenie PV k SO sa vykonáva na Opv01 záložka „Spravovaný oddiel“).

Pozn.: Pre zostavy, ktoré čerpajú z miezd a riadková práva sa u nich vyhodnocujú z miezd položka nemá význam, pretože vo mzdách sú len osoby / PV zaradené na SO.

Ďalšie podmienky obmedzenia práv k osobám a PV

· PV - režim práv k riadkom - možnosť zadať ďalšiu aditívnu podmienku k obmedzeniu pomocou SJ, SO. Môže nadobúdať tieto hodnoty:

VSE	Všetko (v rámci ďalších podmienok na SO, SJ, statusy, chránené PV)
STRU	Osoby a PV zaradené na štruktúru
STRU_PRIMO_HIST	Osoby a PV zaradené na štruktúru, prístup v celej histórii, ale max do dátumu, do kedy má prístup k osobe
ST_POD	Osoby a PV zaradené na štruktúre a podriadenej štruktúre
VL_OSO	Vlastná osoba
ST_MANA	Osoby a PV zo štruktúr, u ktorých je používateľ označený ako manažér
ST_MANA_POD	Osoby a PV zo štruktúr, u ktorých je používateľ označený ako manažér a podriadené strediská
ST_MANA_PRIMO	Od ST_MANA sa líši tým, že okrem zamestnancov, ktorým je používateľ manažérom (podľa uvedenej štruktúry) má prístup aj k manažérom priamo podriadených jednotiek. Obvykle ide o podriadených vedúcich v organizačnej štruktúre.
ST_MANA_POD_OBD	Od ST_MANA_POD sa líši tým, že vyhodnocuje, či ak zamestnanec pod používateľa patril aspoň jeden deň v období (mesiaci).
ST_MANA_OBD	dtto ale pre režim ST_MANA
ST_POD_OBD	dtto ale pre režim ST_POD
STRU_OBD	dtto ale pre režim STRU
ST_KUMUL, ST_KUMUL_POD	Inštalácia na VŠE umožňuje nastaviť ďalšie 2 režimy. V nasledujúcej Adm02 položke "PV typ štruktúry" správca vyplní 8. PV zoznam prvkov zostáva prázdny. Realizuje sa tým režim zamestnanca pod dvoma manažérmi. Predpokladá sa zadanie viacerých prvkov (stredísk) štruktúry 8 na jedno PM v Pmi01 tzn. PM pracuje pre 2 strediska. Prístup k zamestnancovi na tomto PM tak získavajú 2 manažéri 2 prvkov (stredísk) štruktúry 8.

Pozor: všetky _OBD režimy platí len pre priame priradení štruktúry použitej pre definíciu práva! Priradenie sa vykonáva na PV v Opv01 / Štruktúry.

Pozn.: Na účely práv typu *MANA* manažéra zaniknutého strediska už nepovažujeme za manažéra, ktorému patrí zaradenie a podriadení.

Inými slovami k dátumu zisťovania berieme u týchto režimov do úvahy vznik a zánik prvku (Str01).

· PV - typ štruktúry pre práva k PV
typ štruktúry (Str01)

· PV - zoznam prvkov štruktúry pre práva k PV:
Pre typ STRU, ST_POD a ST_POD_OBD sa tu uvádza kód(y) štruktúr pre obmedzenie právami.
Používa sa kód, resp. kódy oddelené čiarkou. Pre zadanie negatívnej podmienky "všetko okrem" sa pred výpočet napíše znak "!" - pozrite ďalej odsek.
Pokiaľ ponecháme hodnotu nevyplnené, berie sa štruktúra (typicky stredisko), na ktoré je zaradený prihlasujúci sa používateľ, resp. ktoré je manažérom (ST_MANA, ST_MANA_POD, ST_MANA_PRIMO, ST_MANA_OBD, ST_MANA_POD_OBD)
Pre VSE, VL_OSO a , 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žime prístup k celej histórii:

Príznak sa používa u referentov typu mzdová účtovníčka, ktorých práca má ročný charakter. Nastavenie na Áno potom referentovi navyše sprístupňuje zamestnancov, ktoré mal v aktuálnom roku aspoň jeden deň prístupné.

Tento režim je dostupný iba pre ST_MANA*. V ostatných režimoch toto nie je podporované

· PV - sprístupniť i nezaradené PV - definícia má význam pre tie typy PV, ktoré sa na štruktúru nepriraďujú (používateľ, lektor, uchádzač...). Nastavením na „Áno“ sa takéto osoby (PV) stanú viditeľnými
(Priradenie PV na štruktúru sa vykonáva na Opv01 záložka „Zaradenie do štruktúr“).

· PV - zoznam povolených statusov PV - aditívna definícia práv na základe zoznamu položky Opv01/Popis/Status vzťahu osoba org.
Častou hodnotou býva napríklad pre mzdové účtovníčky obmedzenie 1,2 (teda tá počítaná) rešp. 1,2,3.

· PV - zoznam statusov pre práva - aditívna definícia práv na základe zoznamu položky Opv01/Popis/Status - práva. Na rozdiel od minulej položky, kde číselník je v správe Elanor, u tejto položky je číselník vo správe používateľa (Jpc01 / status_prava). Pre zadanie negatívnej podmienky "všetko okrem" sa pred výpočet napíše znak "!" - pozrite ďalej odsek.

· PV - sprístupnenie chránených PV - aditívna definícia práv na základe príznaku, ktorý správca môže osobe/PV nastaviť v Adm11 / PV / Chránená osoba.

Všetky podmienky sú vyhodnocované ako "a zároveň". Nastavenie viacerých podmienok obvykle vedie k väčšej reštrikcii.

Vlastné vyhodnotenie práv k riadkom:

Vo väčšine miest aplikácie sa práva k riadkom vyhodnocujú z priebežných kmeňových dát.

Tzn. z dát formulárov Opv01 (Trvanie, Opis, Štruktúry), Str01 (Hierarchia od-do, Iné štruktúry, Manažér - osoba v EGJE).

V dátach, kde prevažuje pohľad na zúčtované mzdy, však EGJE vychádza z toho ako to bolo v tom mesiaci zúčtované.

Tzn. Vyp02 / Kópia štruktúr (podľa Str01 / Použitie štruktúry = 1-MZDY), Vyp01 (výpočet), Str05.

Ide o tieto zostavy: 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áre Vyp07, Vst01h, Slm05.

Povolenie priradiť

· PV - zoznam typov štruktúry - povolenie priradenia:
ak je prázdne, tak bez obmedzenia, ak je vyplnené zoznamom typov štruktúr (navigácia Str01) tak obmedzujú, ktoré štruktúry smie používateľ zamestnancovi priraďovať (Opv01, Opv04, Opv05)

· Preferovaný navigačný zoznam Pv
Pre profil je možné vybrať implicitný navigačný zoznam pre formuláre s týmto navigačným zoznamom (napr. Osb02, Opv01, Vyp01, Kva01, Dav01 ...)

Práva k riadkom - ďalšie objekty

(systém skupín RP je komplexnejšie popísaný v Adm_uzdoc - kapitola Adm06)

· Obmedzenie číselníkov podľa skupín RP - používateľ uvidí (obvykle v ponukových ComboBoxoch) len tie hodnoty z príslušného číselníka, ktoré sú označené touto skupinou (zoznam oddeľovaný čiarkou alebo intervaly oddelené čiarkou. Napr. 1,7-9,23-26,29, ...atď). Pre zadanie negatívnej podmienky "všetko okrem" sa pred výpočet napíše znak "!" - pozrite ďalej odsek.

· Pridať vlastnú skupinu z Org.str. - pridá ku skupinám v predchádzajúcom riadku ešte tú skupinu, ktorá je uvedená u organizačného strediska, na ktoré je používateľ zaradený.

· Obmedzenie editácie číselníkov podľa skupín ŘP - pre používateľov, ktorí editujú číselníky. Musia tu mať zoznam všetkých skupín, ktorými označené riadky v číselníku majú vidieť a editovať (inak vidia len riadky bez označenia skupinou). Pre zadanie negatívnej podmienky "všetko okrem" sa pred výpočet napíše znak "!" - pozrite ďalej odsek.

· Pridať vlastný sk. z Org.str. - editácia - dtto úvodná dvojica, ale pre účel editácia číselníkov

· Obmedzenie editácie číselníka štruktúr (zoznam typov) - zoznam typov štruktúr (navigácia Str01), ktoré používateľ smie editovať. Napr. 2,3 spôsobí, že používateľ v Str01 uvidí a môže editovať len Organizační štruktúru (2) a Pracovné miesta (3).
To môže byť skombinované s obmedzením editácie len niektorých riadkov (pomocou predchádzajúcich dvoch parametrov)

· PM - práva k PM podľa organizačnej štruktúry
nastavení na Áno spôsobí, že v navigačnom zozname pracovných miest (PM), budú iba tie PM, ktoré sú na organizačných strediskách, ku ktorým má používateľ prístup (predpokladá sa definovanie práv podľa organizačnej štruktúry). Navigačný zoznam je použitý napríklad u Pmi01, Pmi08, Pmi09.
Ak nie je položka vyplnená, obmedzenie nie je uplatňované.

· Typy dokumentov (Opv31, Rea0x) – zoznam

Parameter poskytuje možnosť zadať výpočet typov dokumentov, ktoré môže používateľ u zamestnanca resp. uchádzača vidieť a editovať.
Pre zadanie negatívnej podmienky "všetko okrem" sa pred výpočet napíše znak "!" - pozrite ďalej odsek.

· Typy dokumentov iba pre čítanie (Opv31, Rea0x) – výpočet

Parameter poskytuje možnosť zadať výpočet typov dokumentu, ktoré môže používateľ u zamestnanca, resp. uchádzača vidieť, ale nie zadávať a editovať.
Pre zadanie negatívnej podmienky "všetko okrem" sa pred výpočet napíše znak "!" - pozrite ďalej odsek.

Výpočet druhov komunikačných kontaktov (Pkz01, Osb01/2) - analogicky - zadáva sa výpočet čísel druhov, vrátane záporného výpočtu iniciovaného znakom "!". Práva k uchádzačom - navigácia

· UCHAZ - zoznam statusov - navigácia
možnosť obmedziť zobrazovaný zoznam uchádzačov pomocou zonamu statusov (čiarkami oddeľované číselné hodnoty statusu uchádzača)

Týka sa aj statusov

Práva k uchádzačom - procesné obmedzenia

· UCHAZ - zoznam statusov - smie nastaviť
možnosť zadať zoznam statusov, ktoré môže používateľ u uchádzača nastaviť/priradiť

Dochádzka – definícia verifikačnej úrovne používateľa pre oblasť dochádzky

· Úroveň editácie dochádzky – verifikačná a editačná úroveň profilu pre overenie riadku resp. pre oprávnenie prístupu k riadkom v evidencii dochádzky (DD, DZ, MV, MZ, doklady).
K dispozícií sú úrovne:
3 Zamestnanec; 13 Vedúci I.; 23 Vedúci; 33 Správca resp. mzdová účtovníčka

Zobrazenie protokolov z doch, DAV

1 - Standard (popup) (tj ako doteraz)

2 - Potlačiť zobrazovanie protokolu v dialógu tzn. nezobrazovať vôbec

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

Typické použitie je celoobrazovkový režim terminálov s EGJEWEB.

Chýbajúce práva na SJ, SO určiť z podriadených osôb (ST *, VL_OSO)

Manažérsky / zamestnanecký profil zvyčajne býva prierezový pre celú organizáciu a nevytvárajú sa jeho varianty pre rôzne SJ / SO. Zapnutím tejto voľby je možné výpočty SJ, SO online dopočítavať pri prihlásení podľa SO, SJ zaradených manažérovi prístupných PV.

Tieto práva na SJ / SO sa potom typicky používajú v rôznych ponukových ComboBox a to v zostavách aj formulároch.

Implicitne príznak nie je zapnutý a táto aditívna akcia sa po prihlásení nevykonáva.

Odporúčané a obvyklé profily

Typ	Popis
Zamestnanec	SJ, SO nevyplnené Chýbajúce práva na SJ, SO určiť z podriadených osôb = Áno PV režim práva = VL_OSO
Manažér - osoby zo štruktúr, ktorých je manažérom	SJ, SO nevyplnené, Chýbajúce práva na SJ, SO určiť z podriadených osôb = Áno PV režim práva = ST_MANA PV Typ štruktúry = 2 (zvyčajne org. Štruktúra) Pozn. Pri každom prvku štruktúry 2 musí byť vyplnený manažér (Str01, STR02 / Manažér - Osoba v EGJE Môže aj nemusí mať prístupnú vlastnú osobu (PV - sprístupnenie chránených PV)
Manažér - dtto + manažéri podriadených stredísk	dtto PV režim práva = ST_MANA_PRIMO
Manažér - všetci podriadení	dtto PV režim práva = ST_MANA_POD
Manažér, poverená osoba - osoby zo štruktúry, na ktorú je sám zaradený	SJ, SO nevyplnené, Chýbajúce práva na SJ, SO určiť z podriadených osôb = Áno PV režim práva = STRU (resp. ST_POD pre všetky z podstredisiek) PV Typ štruktúry = 2 (zvyčajne org. Štruktúra ale môže ísť aj o inú) PV výpočet prvkov štruktúry pre STRU, ST_POD = nevyplnené
Referent mzdová účtovníčka - celý SO	SJ, SO vyplnený (môžu byť zoznamy) PV režim práva = VSE
Referent mzdová účtovníčka - priradené PV	SJ, SO pokiaľ konštantná tak vyplnený (môžu byť zoznamy) PV režim práva = ST_MANA PV Typ štruktúry = 14 - Mzdová účtovníčka Pozn. Pri každej mzdové účtovníčky tj. Prvku štruktúry 14 musí byť vyplnená väzba na osobu / používateľa tj.Str01, STR02 / Manažér - Osoba v EGJE. Tým je dosiahnuté, že profil pre viac mzdových účtovníčok môže byť jeden a napriek tomu má každá MÚ svojich zamestnancov. Zamestnanci môžu byť zaradení pod mzdovú účtovníčku (štruktúra 14): na PV v Opv01 / Štruktúry na PM v Pmi01, Str01, STR02 na Org. stredisku v Str01, STR02 U referenta tohto typu je vhodné nastaviť príznak "ST_MANA * práva v režime prístup k celej histórii:" na Áno a sprístupniť tak referentovi aj dáta zverených zamestnancov z obdobia pred vznikom PV referenta.
Iný referent - priradené PV	dtto mzdová účtovníčka, iba číslo štruktúry býva iné typicky 15 - 18 resp. 13

Výhodou použitia profilov ST_MANA pre referentov je to, že sa pre všetky (alebo aspoň skupinu) referentov daného typu môže použiť spoločný profil.

Na tento profil sa potom dajú prehľadne viazať ďalšie konfigurácie:

· Adm06 - všeobecné skupiny, skupiny ZLM, skupiny kalendárov

· Epr02 - Eproposal

· Adm02 - role zaradené na profil

· Mail - možnosť odoslať správu všetkým na profile

Pri vytvorení špeciálneho profilu pre každého pracovníka zvlášť, je potreba uvedené konfigurácie udržiavať pre každý profil samostatne a to môže byť u väčšieho počtu referentov pracné a neprehľadné.

Typicky máva taký referent profil s týmto nastavením:

SJ, SO vyplnený (môžu byť zoznamy)

PV režim práva = STRU

PV Typ štruktúry = niektorá zo štruktúr 13-18

PV zoznam prvkov štruktúry pre STRU, ST_POD

= zoznam používateľských kódov prvkov štruktúry oddelených čiarkou

Ako nakonfigurovať štruktúry, aby boli použiteľné pre prístupové práva podľa štruktúr (tj. režimy ST *).

Na Str01 je potrebné nastaviť:

Väzby medzi štruktúrami:

Ak sa zadáva štruktúra na PM, potom

"Podriadená štruktúra (vyplňam kde)" bude 3 - Pracovné miesto

a "Nadradená (vyplňam čo)" bude napr. 14 - Mzdová účtovný

Ak údaje zadávam už na Organizačným stredisku, potom

"Podriadená" bude 2 - Organizačná štruktúra.

Ak zadávame na PV (Opv01 / Štruktúry), potom v záložke Použitie štruktúry zadávame pre tú konkrétnu štruktúru (napr. 14 - Mzdová účtovníčka) hodnotu 2-KMEŇ-PV.

Pozn.: ak v Opv01 / Štruktúry smie túto štruktúru priraďovať len niekto, je možné ostatným profilom so zápisovými právom na túto záložku nastaviť zoznam Adm02 / PV - zoznam typov štruktúry - povolenie priradenie: taký, aby túto štruktúru neobsahoval.

Na štruktúrach platia zásady nepriameho priradenia. Na organizačnom stredisku teda môžem vyplniť najčastejšie hodnotu (napríklad tú Mzdovú účtovníčku do Str01 / Stru / Manažér osoba v EGJE), odchýlky potom vyplniť na PM alebo až na PV.

Tak je možné výhodne minimalizovať počet miest, kde je údaj vyplňovaný.

Pre práva typu ST_MANA *, použitého pre referentov, je možné riešiť situáciu, keď referentov je pre tú istú skupinu osôb / PV viac a sú rovnocenní. V tom prípade sa zaškrtne checkbox (napr. u tej štruktúry 14) v Str01 / Meno štruktúry a jej hladín / Smie byť paralelne viac manažérov / osôb.

Následne je potom možné v Str01 / Stru / / Manažér osoba v EGJE, zadať viac paralelných referentov.

Tento režim by sa ale nemal používať u štruktúr, použitých pre schvaľovanie (workflow podľa Adm14), preto ho neponúkame pre štruktúru 2, ktorá je takto použitá najčastejšie.

Negatívne vymedzenie prístupu k Osobám a PV

Od e201809 je možné okrem štandardného zadania "všetci, ktorí majú čosi" zadať prístupové práva k riadkom (tj. Osobám a PV) negatívne, teda "všetci, okrem tých, ktorí majú čosi".

Dáva to tak jednoduchú alternatívu k "PV - sprístupnenie chránených PV", ktoré používa atribút Adm11 / PV / "Chránená osoba / PV".

Všetci okrem umožňujeme zadať pre:

• PV - výpočet statusov pre práva

• PV - výpočet prvkov štruktúry pre STRU, ST_POD (práve a len pre tieto 2 režimy)

• Obmedzenie číselníkov podľa skupín VP

• Obmedzenie editácie číselníkov podľa skupín VP

• Typy dokumentov (Opv31, Rea0x) - zoznam: Čítanie aj zápis

• Výpočet druhov komun. kontaktov (Pkz01, Osb01 / 2)

Negatívny výpočet sa zadá tak, že sa do prvého znaku položky pre hodnotu zadá znak "!".

Teda napr. keď do "PV - výpočet statusov pre práva" zadáme napr. hodnotu "!5", potom budú prístupné tie PV, ktoré nemajú v položke Opv01 / Popis / Status práva hodnotu "5".

Znak "!" je funkčný práve a len na mieste prvého znaku a hovorí, že všetko za tým bude vyhodnotené negatívne. Nie je teda možné v rámci jednej položky kombinovať pozitívne a negatívne spracovanie.

Alternatívne vyhodnocovanie práv k osobám a PV (riadková práva offline)

Na väčších databázach je často u manažérskych a referentských prístupov dlhé úvodné otváranie okien, ktoré je spojené s načítaním navigačných zoznamov a zoznamov v combo boxoch.

Od e202109 umožňujeme riešenie, ktoré pracuje čiastočne offline, a ktoré toto načítanie a tým prvý otvorenia okien typu Wflow, Epr01, Kva01, ... výrazne urýchli.

Sprevádzkovanie je voliteľné a má viac krokov, ktoré spolu súvisia:

• na profile sa nastavuje, že profil je v oblasti riadkových práv vyhodnocovaný pomocou offline kópií dát: Adm02 / PV - práva k riadkom cez Elis51: Áno

• offline práva sú generované procesné zostavou Elis51. Jej spúšťanie zaevidujte na Adm53 a spúšťajte ju jedenkrát denne, typicky ráno alebo v noci.

Zostava má parametre:

! Spoločný číselník štruktúr - hierarchický

! Zaradenie PV do štruktúr

! manažérov štruktúr

! Kompetencie na štruktúrach

Na účely offline práv sa vyžaduje potrebné nastaviť prvé dva parametre. Priamo pri Elis51 sa to robí checkboxy, v Adm53 sa u parametrov

r_FillDataCstr, r_FillDataTpvStr nastaví / ponechá "1", ďalšie 2 je možné pre účely práv dať na "0".

Je k zváženie, u ktorých profilov offline vyhodnotenie nastaviť - primárne je to určené pre profily manažérov, resp. referentov s právami cez štruktúry (ST *). Je vhodné všetko odskúšať. Daní je, že práva sú vyhodnocované k času spustenia, resp. dokončenie zostavy Elis51. Jej častejšie spúšťanie ako 1x či dvakrát denne by mohlo pôsobiť výkonové problémy, však principiálne možné je.

Na Adm10 je záložka Štruktúry offline, ktorá dáva nahliadnuť do prvých dvoch offline úložísk, na záložke je tiež online pohľad do záznamov priradenie manažérov štruktúry. Tu sú používané online hodnoty, tj. Tie, ktoré sú tiež z iného pohľadu na Str01, STR02 / "Manažér / Osoba v EGJE".

Adm01 / Dostupná PV potom zobrazuje výsledok, tj. aké osoby / PV bude mať užívateľ na profile prístupné.

Vytvorenie a editácia role

Rolu vytvárame a editujeme na formulári Adm03.

Role s číslami 1- 499 sú v správe Elanor a sú pre používateľa needitovateľné.

Používateľské role majú vyhradený interval 500-999.

Často sa používa, že používateľ má v profile nejakú (nejaké) štandardnú rolu Elanor (1-499) a správca mu naviac priradí nejakú(é) rolu nad 500, v ktorej práva pridáva, resp. uberá oproti právam v štandardnej roli. Uberanie práv sa robí nastavením záporné hodnoty práva v používateľskej roli. Teda napríklad priradenie práva -2 „Odobratie práva zápisu a čítania“ spôsobí, že priradenie práva zápisu a čítania definované v štandardnej roli pre používateľa prestane byť platné.

Práva priraďujeme v záložke „Práva k objektom“. Tu na záložke „Objekt“ nastavujeme súhrnnú hodnotu prístupového práva - pre formuláre dvojstupňové ( 0 nič / 1 čítanie / 2 zápis a čítanie), pre zostavy a procesy jednostupňové (0 nesmie spustiť / 1 smie spustiť). S tým sa obvykle vystačí. Upozorňujeme, že súhrnná hodnota by mala obsahovať maximum z práv priradených prípadne na Podriadené objekty.

V prípade nutnosti je možné u niektorých formulárov v záložke „Podriadené objekty – editácia“ nastaviť práva i detailnejším častiam formulára (záložka, dátový formulár, položka). Práva sa tu nastavujú ako kaskáda. Teda od hrubého k jemnejšiemu. Vyhodnotenie potom pokračuje v tejto hierarchii až pokiaľ je aspoň nejaké právo ( > 0) až k úrovni položka. Pre zistenie kódových označení si správca môže príslušný formulár, ku ktorému nastavuje práva, spustiť z príkazového riadku s parametrom „-edit“ (pr. Opv01 -edit ). Následne vo formulári vidí pomenovanie jednotlivých komponent.

Tento aparát sa používa i pre selektívne priradenie hromadnej zmeny.

Štandardným režimom je, že používateľ má prístupné všetky časti formulára s výnimkou tých, ktoré mu správca zakáže buď pomocou práv (Adm03), alebo pomocou konfigurácie (Adm04)

Systém však od e201303 umožňuje tiež režimy 1 a 2. Ich voľba sa uskutoční v Adm03 položkou "Práva vnútri formulára - režim" s hodnotami

0 - Standard - podľa typu práv

1 - Implicitne žiadne práva na záložky a dátové formuláre

2 - Implicitne žiadne práva na nič vrátane položiek

Kde 0 je implicitná hodnota a indikuje štandardný režim.

Režim 1 znamená, že správca vymenúva prístupné záložky a dátové formuláre, zatiaľ čo položky dátového formulára budú prístupné všetky resp. tie, ktoré nezakáže.

V režime 2 je aj položky potrebné vymenovávať. Upozorňujeme, že ak má mať používateľ prístup aj pre zápis, je potrebné mu prideliť všetky povinné položky (indikované výkričníkom pred nadpisom) a položky, ktoré sú pre interné logiku a prípadnej kontroly nevyhnutné.

Upozorňujeme, že niektoré časti formulárov môžu mať povinné ovládacie prvky, bez ktorých nebude formulár funkčné, popr. nebude zobrazovať dáta.

Nastavenie je teda citlivou vecou. Správcovia môže pomôcť si formulár zobraziť v štandardnom klientovi z príkazového riadku s parametrom -edit, kedy uvidí interné názvy častí formulára a ľahšie sa potom v záložke Podriadené objekty - editácia zorientuje.

Pre uľahčenie sme v nových režimoch urobili automatické sprístupnenie panelov, ktoré sú tiež vo vnútornej štruktúre formulára uložené.

Nastavený režim je teda vždy potrebné vyskúšať. Nemôžeme garantovať, že všetky nastavené režimy práv budú funkčné podľa predstáv.

Používateľ môže mať práva k formuláru sprostredkované viac rolami vrátane podriadených objektov:

Od e201601 sme upravili logiku spracovanie tejto situácie.

Pred e201601 mala explicitne zadané práva na Podriadený objekt prednosť pred právami zdedenými z nadriadeného prvku.

Od e201601 sú oboje práva brána rovnocenne a ai zdedená práva, ak sú vyššie ako tie explicitne zadaná, sa môžu uplatniť.

V praxi išlo zvyčajne o vyhodnotení práv na položky, kedy v jednej úlohe bola napríklad zadaná práva na čítanie priamo na konkrétne položky

(či už to bolo v ktoromkoľvek z režimov "Práva vnútri formulára - režim" pozri vyššie)

a v druhej úlohe bolo právo na zápis na celú záložku.

Pred e201601 teda vyhodnotenie bralo prednostne tie čítacie práva zadané na jednotlivé položky,

Od e201601 zohľadňuje aj zdedené právo, vyhodnotenie berie to vyššia právo z oboch, a tým sú v tomto príklade zapisovať práva definované na celú záložku.

Od e201605 potom riešime situáciu Master tabuľka + viac detailových záložiek, keď jedna z nich je hlavná, cez ktorú sa obsluhujú dáta master tabuľky.

U Master-Detail sa zohľadnia práva aj na túto hlavnú detailovú komponentu. Pokiaľ má používateľ k hlavnému detailu práva len na čítanie, celá Master-Detail bude tiež len na čítanie. Práva z detailu sa ale nededia na ostatné prípadné záložky v detaile, dedí sa len tie práva, ktoré sú nastavené na celý Master-Detail.

Ak teda chcete napríklad nastaviť používateľovi zapisovacie práva na Str01 / Štruktúra hierarchicky / Manažér, nastavíte zapisovacie práva k MasterDetail (ZalStrHier), čítacie práva k Detail (ZalStrHierDetail) a zapisovacie práva k Manažérovi (cecstrmanaPan).

Pozn. MasterDetail (ZalStrHier) môže tiež zdediť zapisovacie práva zo záložky Štruktúra hierarchicky (ZalStrHierPanel).

4 Upozornenie

Zoznam prístupných častí dokumentácie je tu.