Bezpecnost informacn

1
Bezpecnost informacných systémov

• Bezpecnost Java a J2EE aplikácii

2
Obsah

• Bezpecnost Java 2 aplikácii
• Sandbox
• Security Manager
• Policy file
• Bezpecnost J2EE aplikácii
• Úvod
• Autentifikácia
• Autorizácia
• Security pattern

3
Bezpecnost Java 2 aplikácie

• Sandbox
• SecurityManager
• Policy File
• Príklad

4
Sandbox

• Bezpecnostný model prístupu aplikácii k zdrojom
• Základnou myšlienkou je poskytnút aplikácii
  priestor, aby mohla bežat a zároven tento
  priestor obmedzit nejakými hranicami
• Java sandbox je zodpovedný za ochranu mnoho
  zdrojov a to na rôznych úrovniach.

5
Rôzne úrovne obmedzenia

• minimálny sandbox - obsahuje len zdroje potrebné
  na beh programu. Dovoluje prístup k CPU,
  obrazovke, klávesnici, myške a jeho pridelenej
  pamäti.
• Sandbox, ktorý okrem predchádzajúceho obsahuje aj
  prístup k web servru, z ktorého bol stiahnutý
  štandardný typ.
• Sandbox, ktorý okrem predchádzajúceho obsahuje
  možnost prístupu k množine programovo
  špecifických zdrojov (lokálne súbory, lokálny
  pocítac atd)
• Otvorený sandbox, v ktorom programy majú prístup
  k lubovolným zdrojom.

6
Vývoj modelu sandbox JDK 1.0

• pôvodný model
• ponúkal velmi obmedzené prostredie pre
  vykonávanie nedôveryhodného kódu (untrusted code)
  získaného z otvorenej siete
• Kontrolu prístupu vykonáva security manager

7
Vývoj modelu sandbox JDK 1.1

• JDK 1.1 poskytlo novú koncepciu podpisovania
  apletov
• Ak bol aplet digitálne podpísaný a ak verejný
  klúc urcený na overenie podpisu bol rozpoznaný
  ako pravdivý, s apletom sa pracovalo ako
  s dôveryhodným (trusted) lokálnym kódom a bol mu
  poskytnutý plný prístup k systémovým zdrojom.
• Podpísané aplety sa dorucovali spolu s podpisom
  v oznacenom JAR súbore.

8
Vývoj modelu sandbox JDK 1.2

• Aj lokálny a aj vzdialený kód sa stáva predmetom
  bezpecnostných zásad, ktoré definujú množinu práv
• Oprávnenia sú pridelené zdrojom kódu
• Konfigurácia sa vykonáva v súbore bezpecnostných
  pravidiel (security policy)
• Runtime systém organizuje kód do individuálnych
  domén
• Každá doména sa zaoberá množinou tried, ktoré
  majú tie isté práva

9
Security Manager

• Môžeme si predstavit štyri úrovne útoku na
  prostredie Java
• Modifikácie systému, ak program má práva na
  cítanie a zápis a spraví nejaké zmeny v systéme
• Porušenie súkromia, ak program má právo cítat
  a kradne súkromné údaje zo systému
• Odopretie služby, ak program používa systémové
  prostriedky bez požiadania v takom rozsahu, že
  systém nedokáže vykonávat svoju cinnost (cas
  procesora a pod. cycle stealing)
• Falošná prezentácia, ak sa program tvári ako
  skutocný užívatel systému, môže posielat maily vo
  vašom mene a pod.
• Security manager dokáže zabránit prvým dvom
  z týchto útokov.

10
Security Manager

• Security manager je hlavným prvkom pri riadení
  prístupu aplikácii k systémovým zdrojom.
• Je súcastou bežiaceho JVM a riadi prístup
  k vonkajším zdrojom.
• Definuje vonkajšie hranice sandboxu a pretože je
  nastavitelný, definuje aj rôznu bezpecnostnú
  politiku pre aplikáciu.
• Java API podporuje rôznu bezpecnostnú politiku
  tým, že požiada security manager o povolenie ešte
  pred tým, než sa vykoná nejaká akcia. Toto
  požiadanie vykonávajú check- metódy, napr.
  checkWrite().
• Pred Java verziou 1.2 bol java.lang.SecurityManger
  abstraktnou triedou a musel byt implementovaný.
  To bola velmi nárocná práca a obsahovala mnoho
  citlivých miest, ktoré mohli viest k vzniku dier
• Verzia 1.2 predstavila konkrétnu implementáciu
  triedy a dovolila definovat vlastnú bezpecnostnú
  politiku v ASCI súbore, nie v kóde programu.
• Namiesto check-metód uviedla jednu metódu
  checkPermission().

11
Security Manager

• Vo všeobecnosti aplikácia nemá pridelený security
  manager. To znamená, že JVM nevytvorí automaticky
  security manager pre každú Java aplikáciu a teda
  aplikácia môže vykonávat lubovolné operácie bez
  nejakých bezpecnostných obmedzení.
• V aplikácii môžeme získat aktuálny security
  manager použitím triedy System

SecurityManager appsm System.getSecurityManager
() if (security ! null)
security.checkExit(status)
12
Security Manager
13
Security Manager
14
Policy file

• Policy file je ASCI textový súbor, ktorý môže byt
  vytvorený textovým editorom alebo pomocou
  grafického nástroja Policy Tool
• Obsahuje bezpecnostné pravidlá pre security
  manager
• Je to vlastne zoznam povolený pre jednotlivé kódy
• Policy Tool sa nachádza v adresári
  JRE/bin/policytool.exe
• Štandardný súbor sa nachádza v JRE/lib/security/ja
  va.policy

15
Štandardný súbor java.policy
/ AUTOMATICALLY GENERATED ON Wed Apr 07 091340
CEST 2004/ / DO NOT EDIT / grant codeBase
"filejava.home/lib/ext/" permission
java.security.AllPermission grant
permission java.lang.RuntimePermission
"stopThread" permission java.net.SocketPermissi
on "localhost1024-", "listen" permission
java.util.PropertyPermission "java.version",
"read" permission java.util.PropertyPermission
"java.vendor", "read" permission
java.util.PropertyPermission "java.vendor.url",
"read" permission java.util.PropertyPermission
"java.class.version", "read" permission
java.util.PropertyPermission "os.name", "read"
permission java.util.PropertyPermission
"os.version", "read" permission
java.util.PropertyPermission "os.arch", "read"
permission java.util.PropertyPermission
"file.separator", "read" permission
java.util.PropertyPermission "path.separator",
"read" permission java.util.PropertyPermission
"line.separator", "read" permission
java.util.PropertyPermission "java.specification.v
ersion", "read" permission java.util.PropertyPe
rmission "java.specification.vendor", "read"
permission java.util.PropertyPermission
"java.specification.name", "read" permission
java.util.PropertyPermission "java.vm.specificatio
n.version", "read" permission
java.util.PropertyPermission "java.vm.specificatio
n.vendor", "read" permission
java.util.PropertyPermission "java.vm.specificatio
n.name", "read" permission java.util.PropertyPe
rmission "java.vm.version", "read" permission
java.util.PropertyPermission "java.vm.vendor",
"read" permission java.util.PropertyPermission
"java.vm.name", "read"
16
Všetky existujúce povolenia

• java.security.AllPermission
• java.secuity.BasicPermission
• javax.sound.sampled.AudioPermission
• javax.security.auth.AuthPermission
• java.awt.AWTPermission
• javax.security.auth.kerberos.DelegationPermission
• java.util.logging.LoggingPermission
• java.net.NetPermission
• java.util.PropertyPermission
• java.lang.reflect.ReflectPermission
• java.lang.RuntimePermission
• java.security.SecurityPermission
• java.io.SerializablePermission
• java.sql.SQLPermission
• javax.net.ssl.SSLPermission
• java.io.FilePermission javax.security.auth.kerbero
  s.ServicePermission
• java.security.UnresolvedPermission
• javax.security.auth.PrivateCredentialPermission
• java.net.SocketPermission

17
Skúmanie obmedzení apletu

• Prehliadace pred spustením apletu inštalujú
  security manager, teda aplety bežia pod kontrolou
  tohto manažéra. Apletu nie je umožnené
  pristopovat k zdrojom, pokial nemá explicitne
  definované oprávnenie.
• Majme Aplet, ktorý sa snaží vykonat tieto akcie
• Získat user.home
• Vytvorit, resp. otvorit súbor writetest
  a zapísat don nieco
• Otvorit dialógové okno pre tlac
• Aplet nájdete na stránke www.intrak.sk/bolibruch/
  BIS/priklad1

18
Skúmanie obmedzení apletu
19
Pridanie práv apletu

• získanie user.home - aby sme mohli získat túto
  Property, je nutné pridat PropertyPermission pre
  náš aplet
• postup
• spustíme  JRE/bin/policytool.exe
• otvoríme java.policy súbor, ktorý sa nachádza
  v JRE/lib/security
• klikneme na AddPolicyEntry
• CodeBase reprezentuje URL, pre ktorú sú urcené
  dané povolenia
• codeBase http//w3.intrak.tuke.sk/bolibruch/BI
  S/priklad1/
• Ak chceme, aby povolenia boli aj pre podadresáre,
  zadáme http//w3.intrak.tuke.sk/bolibruch/BIS/-
• stlacte AddPermission
• vyberte PropertyPermission
• do polícka target name napíšeme user.home ako
  názov Property
• z polícka Actions vyberieme read
• Uložíme súbor a apletu sme umožnili získat
  user.home

20
Pridanie práv apletu
21
Pridanie práv apletu

• pre zápis do súboru nastavíme FilePermission pre
  súbor writetest a pridelíme právo write
• pre tlacenie RuntimePermission, queuePrintJob

22
Pridanie práv apletu
23
Pridanie práv podpisom kódu

• Ukážeme si použitie týchto bezpecnostných
  nástrojov
• keytool
• jarsigner
• Policytool
• a samozrejme nástroj na vytvorenie jar súboru,
  aby sme mohli podpísat tento jar súbor.

24
Postup pre odosielatela kódu
25
Postup pre odosielatela kódu

• Odosielatel kódu musí vykonat tieto kroky
• Vytvorenie aplikácie.
• Vytvorenie JAR súboru pomocou nástroja jartool.
• Generovanie klúcov (ak neexistujú) pomocou
  keytool genkey príkazu.
• Volitelný krok Generovanie CSR (Certificate
  signing request) pre certifikát verejného klúca
  a importovat odpoved certifikacnej autority.
• Podpísanie JAR súboru pomocou jarsigner
  a privátneho klúca.
• Exportovanie certifikátu verejného klúca pomocou
  keytool export príkazu

26
Vytvorenie aplikácie

• import java.io.
• public class Count
• public static void countChars(InputStream in)
  throws IOException
• int count 0
• while (in.read() ! -1)
• count
• System.out.println("Counted " count "
  chars.")
• public static void main(String args) throws
  Exception
• if (args.length gt 1)
• countChars(new FileInputStream(args0
  ))
• else
• System.err.println("Usage Count
  filename")

27
Vytvorenie JAR súboru
JAR súbor, ktorý bude obsahovat Count.class súbor
vytvoríme takto jar cvf Count.jar Count.class
28
Generovanie klúcov

• Ak ešte nemáme vhodný privátny klúc na podpísanie
  kódu, musíme ho vygenerovat spolu s odpovedajúcim
  verejným klúcom, ktorý sa použije na overenie
  podpisu.
• Vytvoríme súbor pre uloženie klúcov s názvom BIS.
• keytool -genkey -alias signFiles -keypass kpi135
  -keystore BIS -storepass ab987c

29
Generovanie klúcov

• Príkaz na generovanie klúca je -genkey
• Cast alias signFiles indikuje alias, ktorý sa
  použije na odkázanie sa na miesto obsahujúce
  klúce
• Cast keypass kpi135 špecifikuje heslo pre
  generovaný privátny klúc. Je vždy potrebné pre
  prístup ku klúcu
• Cast keystore BIS indikuje miesto, kde sa majú
  uložit klúce
• Cast storepass ab987c urcuje heslo miesta
  uloženia klúcov

30
Generovanie klúcov
31
Podpísanie JAR súboru

• Teraz môžeme podpísat JAR súbor. Na podpísanie
  JAR súboru Count.jar použijeme privátny klúc, ku
  ktorému pristúpime pomocou aliasu signFile.
  Výsledkom bude podpísaný JAR súbor sCount.jar.
• jarsigner -keystore susanstore -signedjar
  sCount.jar Count.jar signFiles
• Musíme zadat aj heslo uloženia (ab987c) a heslo
  privátneho klúca (kpi135).
• Nástroj jarsigner získa certifikát z miesta,
  ktorého alias je signFiles a priloží ho ku
  generovanému podpisu podpísaného JAR súboru.

32
Export certifikátu verejného klúca

• Runtime systém príjemcu kódu musí autentifikovat
  podpis pri snahe aplikácie podpísanom JAR súbore
  o cítanie súboru.
• Aby sme autentifikovali podpis, potrebujeme mat
  verejný klúc, ktorý tvorí pár s privátnym klúcom
  použitým na generovanie podpisu. Príjemcovi
  pošleme kópiu certifikátu, ktorý autentifikuje
  verejný klúc. Certifikát z miesta uloženia (BIS)
  skopírujeme do súboru BIS.cer takto
• keytool -export -keystore BIS -alias signFiles
  -file BIS.cer
• Vyžiada si to heslo pre prístup k miestu uloženia
  (ab987c).

33
Kroky príjemcu kódu
34
Kroky príjemcu

• Teraz je úloha na príjemcovi, ktorý prijal
  podpísaný JAR súbor a certifikát. My vykonáme
  tieto kroky
• Vyskúšanie obmedzení
• Importovat certifikát ako dôveryhodný, pomocou
  nástroja keytool -import
• Nastavit súbor s bezpecnostnou politikou, aby
  mali podpísané triedy právo cítat daný súbor
• Overit výsledok zmeny bezpecnosti

35
Vyskúšanie obmedzení aplikácie

• Aplikáciu spustíme spolu so manažérom
  bezpecnosti.
• java -cp sCount.jar Count data.txt
• Tento príkaz vráti takúto výnimku
• Exception in thread "main" java.security.AccessCo
  ntrolExceptionaccess denied (java.io.FilePermissi
  on C\TestData\data read) at
  java.security.AccessControlContext.checkPermission
  (Compiled Code) at java.security.AccessControll
  er.checkPermission(Compiled Code) at
  java.lang.SecurityManager.checkPermission(Compiled
  Code) at java.lang.SecurityManager.checkRead(C
  ompiled Code) at java.io.FileInputStream.(Compi
  led Code) at Count.main(Compiled Code)

36
Importovanie certifikátu

• Predtým, než povolíte podpísanému kódu cítat
  špecifikovaný súbor, potrebujeme importovat
  certifikát BIS ako dôveryhodný certifikát do
  priestoru klúcov.
• Chodte do adresára, ktorý obsahuje certifikát
  BIS.cer a vykonjte takýto príkaz
• keytool -import -alias susan -file
  SusanJones.cer keystore raystore
• Ak si chceme overit platnost tohto certifikátu,
  zadajte
• keytool -printcert -file SusanJones.cer

37
Nastavenie súboru s bezpecnostou

• Po otvorení súboru s bezpecnostou pomocou
  nástroja policytool musíme špecifikovat tzv.
  keystore, miesto, kde sa nachádza klúc. Aby sme
  ho definovali, vyberme príkaz Change Keystore
  z menu Edit.
• Miesto raystore v adresári c/Test urcíme pomocou
  URL takto
• file/C/Test/raystore
• Teraz pridáme práva pre takto podpísaný kód už
  známym spôsobom s tým, že do kolonky SignedBy
  uvedieme susan (alias pre importovaný certifíkát).

38
Bezpecnost J2EE aplikácii

• J2EE architektúra
• Úvod do bezpecnosti
• Autentifikácia
• Autorizácia
• J2EE Security pattern

39
Co je to J2EE ?

• Java 2 Enterprise Edition (J2EE) je viacvrstvová
  architektúra pre implementovanie enterprise
  aplikácii a web aplikácii
• J2EE je platforma pre vývoj distribuovaných
  enterprise aplikácii
• Hlavným cielom J2EE technológie je vytvorit
  jednoduchý vývojový model pre enterprise
  aplikácie pomocou aplikacného modelu založeného
  na komponentach. Tieto komponenty využívajú
  služby poskytované kontajnerom

40
Komponenty J2EE

• Aplikacné komponenty
• Aplet
• Java Servlet a JavaServer Pages
• Enterprise JavaBeans

41
Štandardné služby J2EE

• Java Database Connectivity (JDBC)
• Java Transaction API (JTA)
• Java Transaction Service (JTS)
• Java Messaging Service (JMS)
• Java Naming and Directory Interface (JNDI)
• Java Activation Framework (JAF)
• Remote Method Invocation (RMI)
• JavaMail API (JMA)
• Java Interface Definition Language (JavaIDL)

42
N-vrstvová J2EE architektúra

43
Architektúra J2EE
44
Vrstvy J2EE architektúry

• Klientská vrstva (Client tier)- HTML klient,
  aplet, Java aplikácia
• Web vrstva (Web tier) Java servlets, Java
  Server Page (umiestnenie - web kontajner)
• Obchodná vrstva (business tier) Java Entity
  Beans
• Niekedy sa tu pridáva tzv. Integracná vrstva
  (Integration tier)
• EIS vrstva (Enterprise Information System (EIS)
  tier) databázy, zdroje...

45
Úvod do bezpecnosti

• J2EE aplikácie a Web services aplikácie sú
  vytvárané z komponentov, ktoré môžu byt
  umiestnené v rôznych kontajneroch. Tieto
  komponenty sú používané na budovanie
  viacvrstvovej obchodnej aplikácie. Bezpecnost
  komponentov zabezpecuje kontajner, ktorý ponúka
  dva druhy bezpecnosti
• Deklataracná vyjadruje bezpecnostnú štruktúru
  aplikácii, obsahuje bezpecnostné role, kontrola
  prístupu, požiadavky autentifikácia vo forme
  externej vzhladom na aplikáciu (definuje sa v
  deployment descriptor-e komponentu.)
• Programová je vložená do aplikácie a používa sa
  na rozhodovanie o bezpecnosti. Je vhodná, ak
  deklaracná bezpecnost nie je dostacujúca na
  vyjadrenie bezpecnostného modelu aplikácie.

46
Úvod do bezpecnosti

• J2EE aplikácia sa skladá z komponentov, ktoré
  obsahujú chránené a nechránené zdroje. Casto je
  potrebné chránit zdroje a zabezpecit, aby k nim
  mali prístup iba autorizovaný používatelia.
  Kontrola prístupu zahrnuje dva kroky
• Autentifikácia musí preukázat svoju identitu
  pomocou autentifikácie. Obvykle sa to vykonáva
  poskytnutím autentifikacných údajov (ako napr.
  meno a heslo). Entita, ktokrá môže byt
  autentifikovaná, sa nazýva principal. Principal
  môže byt používatel ale aj program. Používatelia
  sa zvycajne autentifikujú pomocou prihlásenia.
• Autorizácia - Ak sa autentifikovaný principal
  snaží pristúpit k zdrojom, system rozhodne, ci
  tento principal je autorizovaný tak spravit.
• Autorizácia poskytuje kontrolu prístupu k
  chráneným zdrojom. Je založená na identifikácii a
  autentifikácii. Identifikácia je process, ktorý
  umožní rozpoznanie každej entity systému a
  autentifikácia je process, ktorí overí identitu
  užívatela, zariadenia alebo inej entity systému.
• Authorizácia a autentifikácia sa nevyžadujú k
  prístupu k nechráneným zdrojom. Prístup k zdrojom
  bez autentifikácie sa oznacuje ako anonymný
  (anonymous access, unauthenticated access).

47
Oblasti, používatelia, skupiny a role

• Autentifikacná služba J2EE servra zahrna
  a spolupracuje s týmito komponentami
• Oblast (Realm) Súbor užívatelov a skupín, ktoré
  sú kontrolované tým istým autentifikacným
  spôsobom
• Používatel (User) Individuálna identita (alebo
  aplikacný program), ktorá bola definovaná v Sun
  Java System Application Server Platform Edition
  8.0. Môže byt pridelený do skupiny.
• Skupina (Group) Množina autentifikovaných
  používatelov, ktorých spájajú spolocné znaky
• Rola (Role) Abstraktné meno pre povolenie
  prístupu k jednotlivým množinám zdrojov
  v aplikácii. Rola môže byt prirovnaná ku klúcu,
  ktorým sa otvorí zámok. Mnoho ludí môže mat kópiu
  tohto klúca a zámok sa nestará o to, kto ste, iba
  o to, ci máte správny klúc

48
Oblasti, používatelia, skupiny a role
49
Login autentifikácia

• J2EE platforma dovoluje tvorcovi aplikacných
  komponentov vybrat si spôsob autentifikácie. Ak
  sa snažíme pristúpit ku chráneným Web zdrojom,
  Web kontajner aktivuje autentifikacný
  mechanizmus. Môžeme špecifikovat tieto
  autentifikacné mechanizmy
• HTTP základná autentifikácia
• Login autentifikácia založená na formulári
• Autentifikácia certifikátom klienta
• Obojstranná (vzájomná) autentifikácia
• Zjednodušená autentifikácia (digest
  authentification)

50
Použitie HTTP základnej autentifikácie

• Vykonajú sa tieto kroky
• Klient požiada o prístup k chráneným zdrojom.
• Web server vráti dialógové okno, ktoré žiada
  meno a heslo používatela.
• Klient zadá a odošle meno a heslo servru.
• Server overí platnost došlých údajov a ak sú
  správne, vráti zdroj.

51
Použitie HTTP základnej autentifikácie

• Avšak http autentifikácia nie je celkom bezpecná,
  pretože posiela tieto údaje cez internet ako
  text, ktorý je kódovaný kodom uu (Unix-to-Unix),
  resp. base64, ale nie je šifrovaný.
• Tento mechanizmus by sme nakonfigurovali v súbore
  deployment descriptor Web komponentu takto
• ltweb-appgt
• ltlogin-configgt
• ltauth-methodgtBASICDIGESTlt/auth-methodgt ltrea
  lm-namegtjpetslt/realm-namegt
• lt/login-configgt
• lt/web-appgt

52
Použitie autentifikácie založenej na formulári

• Vykonajú sa tieto kroky
• Klient požiada o prístup k chráneným zdrojom.
• Ak nie je autentifikovaný, server presmeruje
  klienta ja stránku pre prihlásenie
• Klient vyplní a odošle pirhlasovací formulár na
  server.
• Ak je prihlásenie úspešné, klient bude
  presmerovaný na požadovaný zdroj,
• inak na chybovú stránku

53
Použitie autentifikácie založenej na formulári

• Ani táto autentifikácia nie je celkom bezpecná,
  ak sa informácie posielajú ako text a kým sa
  nepoužije SSL.
• Konfigurácia
• ltweb-appgt
• ltlogin-configgt
• ltauth-methodgtFORMlt/auth-methodgt ltform-login
  -configgt
• ltform-login-pagegtlogin.jsplt/form-login-pagegt
  ltform-error-pagegterror.jsplt/form-error-pagegt lt
  /form-login-configgt
• lt/login-configgt
• lt/web-appgt

54
Použitie autentifikácie certifikátom klienta

• Táto forma autentifikácie predstavuje
  bezpecnejšiu metódu, než dve predchádzajúce.
  Server a klient sa autentifikujú pomocou
  verejných klúcov certifikátu. Secure Socket Layer
  (SSL) poskytuje šifrovanie dát, autentifikáciu
  servra, integritu správ volitelnú autentifikáciu
  klienta pre TCP/IP spojenie

55
Použitie obojstrannej autentifikácie

• Pri vzájomnej autentifikácii sa autentifikujú
  navzájom server a aj klient. Sú dva typy tejto
  autentifikácie
• Založená na certifikátoch
• Založená na mene a hesle

56
Autentifikácia založená na certifikátoch
57
Autentifikácia založená na certifikátoch

• Vyskytnú sa tieto kroky
• Klient požiadá o prístup k chráneným zdrojom.
• Web server dorucí svoj certifikát klientovi
• Klient overí certifikát zo servra
• Ak je správny, klient posiela certifikát na
  server
• Server kontroluje údaje klienta
• Ak sú správne, server poskytne prístup ku
  chráneným zdrojom

58
Autentifikácia založená na mene a hesle
59
Autentifikácia založená na mene a hesle

• Kroky
• Klient požiada o prístup k chráneným zdrojom.
• Web server dorucí svoj certifikát klientovi.
• Klient overí došlý certifikát.
• Ak je správny, odošle na server meno a heslo,
  ktorý overí ich platnost
• Ak overenie úspešne prebehlo, server zarucí
  prístup ku chráneným zdrojom.
• ltweb-appgt
• ltlogin-configgt
• ltauth-methodgtCLIENT-CERTlt/auth-methodgt
• lt/login-configgt
• lt/web-appgt

60
Autorizácia

• Autorizácia J2EE platformy je založená na
  koncepte bezpecnostných rol. Bezpecnostná rola
  (security role) je logická skupina používatelov.
  Každá bezpecnostná rola je mapovaná na principal
  v prostredí umiestnenia. Bezpecnostná rola môže
  byt použitá s deklarovanou bezpecnostou alebo
  programovanou bezpecnostou.
• Tento mechanizmus môže kontrolovat prístup na
  základe URL alebo na základe podpisu volajúceho
  kódu.
• Volaný komponent má k dispozícii tzv. credential,
  ktorý obsahuje informácie popisujúce volajúceho.
  Tieto atribúty identifikujú volajúceho v danom
  kontexte jedinecne a nazývajú sa bezpecnostné
  atribúty.

61
Deklaracná autorizácia

• Pri kontrole prístupu založenej na kontajneri je
  táto kontrola zabezpecená pomocou nástrojov na
  umiestnenie, ktoré mapujú aplikacný model
  povolení do bezpecnostných pravidiel, ktoré sa
  umiestnia do súboru deployment descriptor.
• Tento súbor definuje logické práva, security
  roles, a asociuje ich s komponentami
• Deklarácia rolí
• ltsecurity-rolegt
• ltdescriptiongtYour description lt/descriptiongt
• ltrole-namegtPayroll-Chieflt/role-namegt
• lt/security-rolegt

62
Deklarácia metód

• Pri deklaracná bezpecnosti môžeme definovat
  kontrolu prístupu k EJB metódam špecifikovaním
  elementu method-permission v jeho deployment
  descriptore.
• Element method-permission obsahuje zoznam metód,
  ktoré môže volat daná bezpecnostná rola.
• Ak principal v danej bezpecnostnej role má
  umožnený prístup k metóde, potom môže vykonat
  túto metódu.

63
Deklarácia metód

• ltmethod-permissiongt
• ltrole-namegtadminlt/role-namegt
• ltmethodgt
• ltejb-namegtTheOrderlt/ejb-namegt ltmethod-namegt
  lt/method-namegt lt/methodgt
• lt/method-permissiongt
• ltmethod-permissiongt
• ltrole-namegtcustomerlt/role-namegt
• ltmethodgt
• ltejb-namegtTheOrderlt/ejb-namegt
  ltmethod-namegtgetDetailslt/method-namegt
  lt/methodgt
• ltmethodgt
• ...
• lt/method-permission

64
Programovaná bezpecnost

• Pri programovanej bezpecnosti sa kontrola
  prístupu riadi pomocou metód EJBContext.isCallerIn
  Role alebo HttpServletRequest.isRemoteUserInRole.
• Použitie metódy getCallerPrincipal()
• Použitie metódy getCallerPrincipal()umožnuje
  hlavne beanu verifikovat principal
• Principal p ctx.getCallerPrincipal()
• if (p.getName().equalsIgnoreCase("payroll-admin"
  ))
• // return the row for "payroll-admin"
• else // unrecognized name
• throw new MyApplicationException(p.getName()
  " invalid")
• Bean vie získat indentitu volajúce pomocou
  EJBContext. Payroll-Admin je principal.

65
Použitie metódy isCallerInRole()

• Táto metóda umožnuje rozpoznanie role bez toho,
  aby bean sa pokúsil identifikovat principal.
• if (ctx.isCallerInRole("payroll-admin"))
• // then allow editing of payroll info
• else // you're not an administrator
• // allow viewing of data only
• Bean môže teda overit, ci je caller clenom
  nejakej role. Payroll-Admin je deklarovaný ako
  referencia.

66
Java Patterns

• Pattern je pravidlo, ktoré vyjadruje vztah medzi
  istým kontextom, problémom a riešením.
  Jednoducho povedané, patterny umožnujú nájdenie
  známeho opakujúceho sa problému a jeho riešenia.
• Security Patterns poskytujú overené techniky pre
  riešené známych problémov pri programovaní.
• Tieto šablóny pracujú spolocne a vytvárajú
  množinu najlepších praktík, ktorých hlavným
  cielom je podporit bezpecnostnú politiku
  organizácie.

67
Výhody použitia patternov

• Môžu byt použité a implementované kedykolvek na
  zlepšenie návrhu systému
• Málo skúsený programátor môže cerpat zo
  skúsenosti omnoho skusenejších programátorov
  a návrhárov
• Použitie overených riešení
• Poskytujú všeobecný jazyk pre návrh, testovanie
  a vývoj
• Môžu byt lahko kategorizované, vyhladané
  a použité
• Poskytujú znovupoužitelné, opakovatelné
  a zdokumentované bezpecnostné praktiky

68
Katalóg šablón
69
Security pattern

• Existuje niekolko bezpecnostných vzorov pre
  tvorbu J2EE aplikácie
• Single Access Point Pattern
• Check Point Pattern
• Role Pattern

70
Single Access Point Pattern

• Táto šablóna popisuje system iba s jedným bodom
  vstupu, vstupom, ktorý je spolocný pre všetky
  prichádzajúce žiadosti a je jedinou bránou
  prístupu do systému. Každý používatel musí prejst
  základnou autentifikáciou. Ak by prišla
  neutorizovaná žiadost o chránený zdroj, táto
  žiadost môže byt automaticky presmerovaná na
  prístupový bod kvôli overeniu.
• Je zvycajne reprezentovaná jednou žiadostou
  o login do siete organizácie alebo na
  individuálny server. Iným príkladom môže byt
  aplikácia poskytujúca jednu login stránku
  namiesto rôznych pre každú službu.
• Implementácia je jednoduchá deklaracne sa vo
  web vrstve špecifikuje, ktoré web zdroje ( URL,
  http metódy...) majú chránit. Ak sa anonymný
  používatel snaží pristúpit k týmto zdrojom, web
  kontajner si vyžiada autentifikáciu.

71
Check Point Pattern

• Táto šablóna centralizuje a vynucuje
  autentifikáciu a autorizáciu. Úlohou tohto
  mechanizmu je rozhodnút, ci má používatel
  dostatocné privilégia na prístup k zdrojom. Tým,
  že sa centralizuje táto logika, sa zabezpecí
  jednoduchšia správa akplikacných práv
  a obchodných pravidiel. Môže byt použitá napr pri
  systéme s viacerými bezpecnostnými úrovniami
  Check Point garantuje prístup ku všetkým zdrojom
  na danej úrovni.
• Väcšina tejto šablóny môže byt riešená pomocou
  Java Authentication and Authorization Service
  (JAAS).

72
Role Pattern

• Táto šablóna popisuje priradenie k jednej alebo
  viacerým rolám, kde každá rola má nejaké pravidlá
  (nie používatel). Tento prístup má dve výhody
• ak sa zmení rola alebo priradenia používatela
  k roliam, nie je potrebná zmena základných
  objektov pre kontrolu prístupu
• povolenia sa riadia a pridelujú intuitívne,
  pretože rola reprezentuje cast organizacnej
  štruktúry
• Implementácia v J2EE platforme je pomocou
  deklaracného bezpecnostného modelu definovaním
  rolí v súboroch ejb-jar.xml a web.xml.

73
Zoznam literatúry

• java.sun.com/security/
• Enterprise JavaBeans Programing, Sun
  Microsystems, 2000
• Stephanie Bodoff, Dale Green, Eric Jendrock,
  Monica Pawlan, Beth Stearns The J2EE Tutorial
• Deepak Alur, John Crupi, Dan Malks Core J2EE
  Patterns Best Practices and Design Strategies
• Craig A. Berry, John Carnell, Matjaz B. Juric,
  Nadia Nashi J2EE Design Patterns Applied, Wrox
  Press