Java Servlets – autorizovaný prístup k aplikácii 3.

Pokračujeme tematikou zabezpečenia našich aplikácií pred neautorizovaným prístupom. V tomto článku si povieme niečo málo o možnostiach digitálnych certifikátov a ukážeme si, ako aktivovať a nastaviť autentifikáciu a autorizáciu na serveri Tomcat 5.x.

Digitálne certifikáty

Reálne aplikácie si často vyžadujú vysokú úroveň zabezpečenia, väčšiu ako im môže BASIC alebo FORM autorizácia poskytnúť. Vyžadujú si tiež garantovanú dôveryhodnosť a integritu. Toto im môžu zabezpečiť práve digitálne certifikáty. Keďže táto problematika je veľmi rozsiahla a na túto tému už boli napísané celé knihy, nie je v mojich silách venovať sa jej v tomto seriály. Preto to chápte len ako stručný úvod do problematiky.

Kľúčovú úlohu tu zohráva kryptografia využívajúca systém verejného a súkromného kľúča. Každý, kto chce využívať tento systém, musí vlastniť tieto dva kľúče. Verejný kľúč je k dispozícii voľne a súkromný kľúč naopak musí byť dobre chránený. Kľúče sú navzájom previazané, ale nie je možné odvodiť jeden od druhého. Inými slovami, ak vlastním niekoho verejný kľúč, nie je možné, aby som z neho odvodil jeho privátny kľúč. Tento systém môžem využiť napríklad na šifrovanie správ. Ak chcem niekomu poslať takúto správu, použijem jeho verejný kľúč a ním danú správu zašifrujem. Adresát danej správy potom použije svoj privátny kľúč na dešifrovanie tejto správy.

Systém šifrovania pomocou verejného kľúča je vo väčšine prípadov založený na patentovanom RSA algoritme vyvinutom pánmi Ronom Rivestom, Adi Shamirom a Leonardom Adelmannom. RSA využíva veľmi vysoké prvočísla na vygenerovanie dvojice asymetrických kľúčov. Dĺžka jednotlivých kľúčov sa udáva v bitoch, obvykle sa používajú 1024 alebo 2048 bitové kľúče. Je možné samozrejme použiť aj menšie, ale pravdepodobnosť prelomenia šifry sa zvyšuje. Keďže šifrovacie kľúče sú veľmi dlhé, bolo by veľmi nepraktické, keby sa zadávali pri každej požiadavke na chránený zdroj. Preto sú obvykle uložené na disku vo forme digitálnych certifikátov. Tieto certifikáty môžu byť generované softvérom ako je napríklad PGP alebo vystavené tretími stranami.

Kryptografia rieši problém s dôveryhodnosťou údajov, keďže prenášané údaje sú šifrované. Podobne rieši aj problém s integritou prenášaných informácií, pretože adresát môže mať istotu, že nikto okrem neho danú správu nečítal. Digitálne certifikáty však neriešia problém autentifikácie. Čiže nevieme, či správa naozaj prišla od toho odosielateľa, od ktorého prísť mala. Tu nastupuje na scénu digitálny podpis. Na to sa znova využíva verejný a privátny kľúč. Odosielateľ najprv zakóduje správu svojim privátnym kľúčom a potom ešte použije verejný kľúč adresáta a znova ním zakóduje správu. Keď adresát obdrží správu, ako prvé použije svoj privátny kľúč na dekódovanie správy a následne použije verejný kľúč odosielateľa na druhé dekódovanie. Keďže iba odosielateľ môže zakódovať správy svojím privátnym kľúčom (teda iba on môže vytvoriť správy, ktoré sú dekódovateľné jeho verejným kľúčom), adresát má istotu, že správa bola naozaj poslaná konkrétnym odosielateľom.

Problematika šifrovania, digitálnych podpisov a certifikátov je veľmi rozsiahla a komplexná. Ja som chcel iba naznačiť, že aj servlety môžu využívať túto technológiu. Aby to však bolo možné, musí programátor zvládnuť základné Java technológie týkajúce sa bezpečnosti. Konkrétne ide o tieto:

1. Java Authentication and Authorization Service (JAAS)
   JAAS je skupina programových rozhraní, ktorá môže byť použitá na dva účely – na autentifikáciu alebo na autorizáciu užívateľov a spoľahlivé zistenie toho, kto práve vykonáva java kód, bez ohľadu na to či ide o aplikáciu, aplet, java bean, servlet či JSP.
2. Java Cryptography Extension (JCE)
   JCE je balík rozhraní vytvárajúci framework pre implementáciu kryptovania, generovania kľúčov, overovania kľúčov a takzvaných Message Authentication Code (MAC) algoritmov. Podpora kryptovania zahŕňa aj symetrické a asymetrické šifrovanie.
3. Java Secure Socket Extension (JSSE)
   JSSE je skupina balíčkov umožňujúcich realizovať zabezpečenú internetovú komunikáciu. Technológia obsahuje podporu protokolov Secure Sockets Layer (SSL) a Transport Layer Security (TLS). Obsahuje funkcionalitu pre podporu kryptovania dát, server autentifikáciu, integritu dát a voliteľne tiež podporu klientskej autentifikácie.
4. Java Certification Path (JCP)
   JCP je technológia pozostávajúca z tried a rozhraní na obsluhu digitálnych certifikátov. Využíva takzvanú certifikačnú cestu, čo je zoradený zoznam certifikátov. Pri využití overovacích pravidiel môže byť použitá na priradenie verejného kľúča ku konkrétnemu subjektu.

Autentifikácia a autorizácia – Tomcat 5.x

Tak ako som sľúbil v úvode, pozrieme sa na to, ako rozbehať BASIC autentifikáciu na serveri Tomcat. Systém zabezpečenia web aplikácií na serveri Tomcat je postavený okrem iného na používaní takzvaných Realms. Čo to vlastne realm je? Je to niečo ako databáza užívateľov a ich hesiel, oprávnených používať web aplikácie a k tomu navyše ešte skupina „rolí“, priradených k jednotlivým užívateľom. Rola je v podstate skupina, ktorá má určité oprávnenia, a každý, kto vlastní určitú rolu, vlastní aj jej oprávnenia. Každý užívateľ môže spadať pod ľubovoľný počet rolí.

Napriek tomu, že špecifikácia servletov definuje mechanizmus na deklaráciu požiadaviek na bezpečnosť z pohľadu aplikácií, neexistuje portabilné API definujúce štandardné rozhranie medzi servlet kontajnerom a informáciami o užívateľoch a ich roliach. Preto Tomcat definuje štyri rozhrania (org.apache.catalina.Realm), ktoré je možné použiť na prepojenie s existujúcou databázou užívateľov (nemusí ísť nutne o relačnú databázu). Sú to tieto :

1. org.apache.catalina.realm.DataSourceRealm
   – tento typ realmu sprístupňuje autentifikačné informácie uložené v relačnej databáze dostupnej cez JNDI dátový zdroj
2. org.apache.catalina.realm.JDBCRealm
   – rovnako ako predchádzajúci typ, ale dostupnej cez JDBC driver
3. org.apache.catalina.realm.JNDIRealm
   – sprístupňuje informácie uložené v LDAP dostupné cez JNDI
4. org.apache.catalina.realm.MemoryRealm
   – používa sa v prípade, že autentifikačné údaje sú uložené vo forme objektu v pamäti, pričom ten je inicializovaný z XML súboru (conf/tomcat-users.xml).

Predtým ako si vyberieme konkrétny typ realmu, treba si ešte niečo povedať. Záleží len na vás, ktorý použijete, ale pre produkčné prostredie sa neodporúča používať posledný typ. Na druhej strane ho môžeme využiť na rýchle vyskúšanie možností zabezpečenia aplikácie. Jednotlivé typy realmov sa nastavujú v súbore (conf/server.xml). Na vytvorenie realmu stačí pridať nasledujúci element:

<Realm className=“…názov triedy realmu…“
  …ďalšie atribúty…/>

Element <Realm> môže byť vnorený v niektorom z troch rôznych elementov, čo má potom priamy vplyv na „dosah“ daného realmu. Inými slovami to znamená, že umiestnením elementu <Realm> určíme, ktoré web aplikácie budú zdieľať tie isté autentifikačné informácie. Element <Realm> môžeme umiestniť do vnútra elementu:

• <Engine>
  – v tomto prípade bude daný realm dostupný pre všetky aplikácie na všetkých virtuálnych hosťoch, môže však byť prekrytý niektorým z elementov <Host> alebo <Context>
• <Host>
  – realm bude dostupný pre všetky web aplikácie na konkrétnom virtuálnom hosťovi, opäť však môže byť prekrytý nasledujúcim elementom <Context>
• <Context>
  – takýto realm je určený pre konkrétnu aplikáciu definovanú v elemente <Context>

Ukážme si teda, čo treba urobiť, aby nám fungovala autentifikácia a autorizácia pre konkrétnu web aplikáciu. V tomto článku použijeme org.apache.catalina.realm.MemoryRealm. Na začiatku treba vložiť daný realm do súboru server.xml.

Súbor server.xml:

<Context path=“/secureapp“ docBase=“secureapp“ debug=“0″>
  <Realm className=“org.apache.catalina.realm.MemoryRealm“/>
</Context>

Nasleduje definícia užívateľov a rolí.

Súbor tomcat-users.xml:

<?xml version=’1.0′ encoding=’utf-8′?>
<tomcat-users>
  <user username=“boss“ password=“big“ roles=“manager“/>
</tomcat-users>

Posledným krokom je editácia súboru web.xml aplikácie secureapp.

Súbor web.xml:

<security-constraint>
 <web-resource-collection>
  <web-resource-name>
    Secureapp Site
  </web-resource-name>
  <!– budeme chrániť celú aplikáciu –>
  <url-pattern> /secureapp/* </url-pattern>
  <!– iba tieto http metódy budú chránené –>
  <http-method> DELETE </http-method>
  <http-method> GET </http-method>
  <http-method> POST </http-method>
  <http-method> PUT </http-method>
 </web-resource-collection>
 <auth-constraint>
 <!– roly ktoré majú prístup –>
  <role-name> manager </role-name>
 </auth-constraint>
</security-constraint>
<!– BASIC autentifikácia –>
<login-config>
 <auth-method> BASIC </auth-method>
 <realm-name> Secure Authentication </realm-name>
</login-config>
<!– alebo FORM autentifikácia –>
<login-config>
 <auth-method> FORM </auth-method>
 <realm-name> Secure Authentication </realm-name>
 <form-login-config>
  <form-login-page> /secureapp/login.jsp </form-login-page>
  <form-error-page> /secureapp/error.jsp </form-error-page>
 </form-login-config>
</login-config>
<!– roly používané touto aplikáciou –>
<security-role>
 <description> Manager role </description>
 <role-name> manager </role-name>
</security-role>

Tak toto by malo stačiť, aby vám začala fungovať kontrola prístupu k aplikácii využívajúca MemoryRealm. Ako si môžete všimnúť, v súbore web.xml sú súčasne uvedené dve varianty autentifikácie BASIC a FORM. Samozrejme je nutné si medzi nimi vybrať podľa vašich potrieb. Čo sa týka použitého realmu, ešte som vám niečo dlžný. Preto v budúcom článku poskytnem ďalšie informácie a tiež sa bližšie pozrieme na ostatné typy realmov. Na úplný záver dnešnej časti vám ponúkam odkaz na stránky venované bezpečnosti a jazyku Java.