Od prvního přidání přihlašovací stránky do webové aplikace bylo zabezpečení vždy jednou z klíčových komponent důležitých pro úspěch aplikací na webu. Historicky bylo všechno kódováno ručně. Každá webová aplikace měla vlastní metodu autentizace a následného autorizace uživatelů. Vývojáři také integrovali komponenty pro registraci, správu a další potřebné funkce. I když to bylo docela dost, tento přístup umožňoval velkou flexibilitu.
S příchodem JAAS, služby Java Authentication and Authorization Service, aplikace získaly sadu rozhraní a konfiguraci, které mohly využít ke standardizaci těchto úkolů. I po přidání JAAS do specifikace má J2EE stále několik problémů k vyřešení, než vývojáři aplikací mohou přestat vytvářet vlastní API. Volba mezi používáním standardů J2EE nebo vytvořením vlastního řešení vyžaduje znalost kompromisů každého z nich a samozřejmě požadavky vaší aplikace.
Tento článek si klade za cíl poskytnout všechny informace potřebné k rozhodování mezi vlastním zabezpečením nebo zabezpečením kontejneru. Diskutuji o nejběžnějších funkcích zabezpečení aplikací, abych poskytl nezbytné pozadí zabezpečení. Po této diskusi následuje podrobné vysvětlení implementací zabezpečení J2EE poskytovaných specifikacemi a také nejběžnější metody implementace vlastního zabezpečení. Poté, co lépe porozumíte každé z metod, měli byste mít dostatek informací k výběru metody, která nejlépe vyhovuje požadavkům vaší aplikace.
Co je to kontejner?
Předtím, než probereme různé typy zabezpečení a problémy s implementací zabezpečení, pojďme se podívat, co a kontejner je. Kontejner je prostředí, ve kterém je spuštěna aplikace. Je také synonymem aplikačního serveru J2EE. Pokud jde o kontejnery J2EE, aplikace J2EE běží uvnitř kontejneru, který má specifické povinnosti s ohledem na aplikaci. Existuje mnoho různých typů kontejnerů J2EE a různé úrovně podpory J2EE. Tomcat od Apache je webový kontejner, který implementuje pouze části servletu (webové aplikace) specifikace J2EE. WebLogic společnosti BEA je plně kompatibilní aplikační server J2EE, což znamená, že podporuje všechny aspekty specifikace J2EE a prošel certifikačními testy Sun J2EE. Pokud si nejste jisti podporou, kterou váš aplikační server poskytuje, požádejte o další informace prodejce.
Zabezpečení aplikací
Dalším tématem, kterému se musíme věnovat, než začneme, je rozdíl mezi nimi zabezpečení aplikace a další typy zabezpečení. Zabezpečení aplikace je zabezpečení prováděné přímo aplikací nebo nepřímo rozhraním nebo kontejnerem pro aplikaci s ohledem na uživatele této aplikace. Příkladem uživatele aplikace je někdo, kdo se přihlásí do online knihkupectví a zakoupí několik knih Java. Existují i jiné typy zabezpečení, například zabezpečení sítě a zabezpečení JVM. Jedním z příkladů těchto typů zabezpečení je uživatel, který spouští proces Java na počítači. Ve zbytku tohoto článku, kdykoli budu diskutovat o zabezpečení, mám na mysli zabezpečení aplikací. Ostatní typy zabezpečení přesahují rámec této diskuse.
Zde se zaměřujeme konkrétně na zabezpečení J2EE, což je typ zabezpečení aplikace, protože se zabývá uživateli aplikace J2EE (tj. Volajícími). Uživatelem může být někdo, kdo používá online knihkupectví, nebo jiná aplikace, která využívá nákupní služby aplikace pro knihkupectví, například jiný online prodejce.
Bezpečnostní funkce aplikací
Při zvažování zabezpečení aplikace existuje pět hlavních funkcí: autentizace, autorizace, registrace, údržba účtu (aktualizace) a mazání / deaktivace účtu. I když existuje jen malá podmnožina všech možných funkcí, které aplikace může mít, jedná se o nejzásadnější a nejstandardnější pro všechny aplikace. Méně formálně jsou tyto funkce znát uživatele (ověřování), vědět, co může uživatel dělat (autorizace), vytvářet nové uživatele (registrace), aktualizovat informace o uživateli (údržba účtu) a odstraňovat uživatele nebo mu bránit v přístupu k aplikaci (smazání účtu).
Většina aplikací umožňuje provádění těchto funkcí uživateli nebo administrátorovi. Když uživatelé tyto funkce provádějí, dělají to pro sebe. Správci tyto funkce vždy provádějí jménem ostatních uživatelů.
Jak bude ilustrováno, všechny tyto funkce nelze dosáhnout bez vlastního řešení, dokonce ani pro ověřování. Krátce projdeme každou z nich, abychom dále ilustrovali koncepty a to, co J2EE postrádá, které musí být vytvořeny na míru.
Ověření
Ověřování je proces identifikace uživatele při interakci s aplikací. V době psaní tohoto článku bylo možné autentizaci J2EE implementovat pomocí různých řešení, z nichž každé bylo definováno jako součást specifikace J2EE (verze 1.0-1.4). Autentizace je hlavním konceptem této diskuse a bude podrobněji popsána později. Je důležité si uvědomit, že autentizace je bezpečnostní funkce, která má největší podporu ve specifikaci J2EE, ale pro implementaci autentizace J2EE (aka autentizace kontejneru) je obvykle vyžadován vlastní kód nebo konfigurace.
Povolení
Autorizace je proces ověřování, zda má uživatel oprávnění k provedení konkrétní akce. J2EE pokrývá toto téma, ale je omezeno na autorizaci na základě rolí, což znamená, že aktivita může být omezena na základě rolí, které uživatel dostal. Například uživatelé v roli správce mohou být schopni odstranit inventář, zatímco uživatelé v roli zaměstnance nemusí.
Aplikace mohou navíc uvažovat o dvou různých typech autorizace: Java Runtime Environment (JRE) / kontejner a autorizace aplikace. Autorizace JRE / kontejneru je proces určování, zda má uživatel vytvářející požadavek oprávnění. JRE / kontejner to určuje před provedením jakéhokoli kódu. Příkladem je kontejner J2EE, který musí před spuštěním servletu nejprve zkontrolovat, zda má aktuální uživatel oprávnění ke spuštění servletu (prostřednictvím omezení adresy URL prostředku). Tento typ povolení je také známý jako deklarativní bezpečnost protože je deklarován v konfiguračních souborech pro webovou aplikaci. Deklarativní zabezpečení nelze za běhu upravit, pokud to kontejner nepodporuje. Deklarativní zabezpečení lze použít mnoha způsoby k autorizaci uživatelů aplikace J2EE, ale toto téma přesahuje rámec této diskuse. (Viz specifikace Servlet 2.3, kapitola 12. Oddíl 2 popisuje deklarativní zabezpečení a 8 je dobrým výchozím bodem pro bezpečnostní omezení.)
Jak již bylo zmíněno dříve, uživatelem může být jiná aplikace nebo jednoduše uživatel aplikace. V každém případě se autorizace JRE / kontejneru provádí během každého požadavku. Těmito požadavky mohou být požadavky HTTP z prohlížeče na webovou aplikaci nebo vzdálená volání EJB (Enterprise JavaBeans). V obou případech, za předpokladu, že JRE / kontejner zná uživatele, může provést autorizaci na základě informací o tomto uživateli.
Autorizace aplikace je proces autorizace při provádění aplikace. Autorizaci aplikace lze dále rozdělit na autorizaci na základě rolí a segmentů. Příkladem autorizace aplikace založené na rolích je, když aplikace aplikuje různé úrovně značek na základě toho, zda je uživatel zaměstnancem nebo návštěvníkem (tj. Zaměstnanecká sleva). J2EE poskytuje API s názvem programové zabezpečení k provedení autorizace na základě rolí (další informace viz specifikace Servlet 2.3, kapitola 12, část 3).
Segmentová autorizace je autorizace založená na dalších atributech uživatele, jako je věk nebo koníčky. Segmentová autorizace se nazývá taková, protože seskupuje uživatele do segmentů na základě konkrétních atributů. J2EE nemá žádný způsob implementace segmentové autorizace. Příkladem segmentové autorizace je, zda je tlačítko na formuláři viditelné pro uživatele starší 40 let. Někteří prodejci mohou nabízet tento typ autorizace, ale to by ve všech případech zaručilo uzamčení dodavatele.
Registrace
Registrace je proces přidání nového uživatele do aplikace. Uživatelé aplikace si mohou sami vytvářet nové účty nebo se aplikace může rozhodnout omezit tuto aktivitu na správce aplikací. Specifikace J2EE nemá API nebo konfiguraci, která umožňuje aplikacím přidávat nové uživatele; proto je tento typ zabezpečení vždy vytvořen na zakázku. J2EE postrádá schopnost sdělit kontejneru, že se nový uživatel zaregistroval, a že její informace musí být během relace trvalé a udržované.
Údržba
Údržba účtu je proces změny informací o účtu, například kontaktních údajů, přihlašovacích údajů nebo hesel. Většina aplikací umožňuje uživatelům aplikace i správcům provádět údržbu. Specifikace J2EE také postrádá API nebo konfiguraci pro údržbu účtu. Chybí mechanismus pro informování kontejneru, že se informace o uživateli změnily.
Vymazání
Odstranění účtu je obvykle omezeno pouze na administrativní uživatele. Ve výjimečných případech mohou některé aplikace uživatelům umožnit mazání jejich vlastních účtů. Většina aplikací ve skutečnosti nikdy neodstraní uživatele; jednoduše deaktivují účet, aby se uživatel již nemohl přihlásit. Důkladné a rychlé mazání je obvykle zamračeno, protože v případě potřeby je mnohem obtížnější vzkřísit data účtu. J2EE neposkytuje žádný způsob odebrání nebo deaktivace uživatelů z aplikací. Postrádá mechanismus pro sdělení kontejneru, že konkrétní uživatel byl deaktivován nebo odstraněn. J2EE také postrádá mechanismus pro okamžité odhlášení uživatele z aplikace, když byl odstraněn její účet.
Co je ověření kontejneru?
Ověření kontejneru je proces informování kontejneru o totožnosti uživatele, který provádí aktuální požadavek. U většiny kontejnerů tento proces zahrnuje přidružení aktuálního ServletRequest objekt, aktuální podproces spuštění a interní relace s identitou uživatele. Přiřazením relace k identitě může kontejner zaručit, že aktuální požadavek a všechny následné požadavky stejného uživatele lze přidružit ke stejné relaci, dokud nevyprší relace daného uživatele. Tento objekt relace obvykle není stejný jako objekt relace HttpSession objekt, ačkoli první se používá k vytvoření a údržbě druhého. Každý následující požadavek stejného uživatele je přidružen k relaci pomocí přepsání URL nebo pomocí cookie relace, podle specifikace Servlet 2.3, kapitola 7.
Jak bylo uvedeno výše v naší diskusi o autorizaci, všechny akce, které kontejner provede, a všechny akce, které JRE provede jménem tohoto uživatele, jsou pečlivě zkontrolovány, aby bylo zajištěno, že uživatel má oprávnění k provedení akce. Chcete-li znovu zopakovat náš předchozí příklad, když kontejner provede servlet jménem uživatele, ověří, že uživatel patří do sady rolí, která mají oprávnění k provádění tohoto servletu. JRE 1.4 také provádí tyto kontroly mnoha akcí, včetně otevření souboru nebo soketu. Ověřování JRE je silný koncept a může zajistit, že každý požadavek na kontejner je v podstatě bezpečný.
V současné době J2EE poskytuje několik různých mechanismů pro implementaci autentizace uživatelů. Patří mezi ně ověřování na základě formuláře, ověřování klientů HTTPS a základní ověřování HTTP. JAAS je zahrnut jako požadovaná metoda ověřování, kterou musí kontejnery podporovat. Specifikace však není striktní ohledně toho, jak by měl kontejner tuto funkci poskytovat; proto každý kontejner poskytuje JAASu jinou podporu. Samotný JAAS je navíc samostatný rámec autentizace a lze jej použít k implementaci autentizace kontejneru bez ohledu na to, zda to specifikace podporuje. Tento koncept vysvětlím podrobněji později.
Každý z mechanismů ověřování poskytuje standardní způsob poskytování informací o kontejneru o uživateli. Nazývám to jako realizace pověření. Kontejner stále musí použít tyto informace k ověření, že uživatel existuje a má dostatečná oprávnění k provedení požadavku. Nazývám to jako ověřování pověření. Některé kontejnery poskytují konfiguraci pro nastavení ověřování pověření a jiné poskytují rozhraní, která musí být implementována.
Metody ověřování J2EE
Podívejme se stručně na některé z nejběžnějších metod implementace a konfigurace autentizace kontejneru.
Ověřování na základě formuláře
Ověřování na základě formuláře umožňuje identifikaci a ověření uživatelů pomocí aplikačního serveru J2EE pomocí libovolného formuláře HTML. Akce formuláře musí být j_security_check a dva parametry požadavku HTTP (vstupní pole formuláře) musí být vždy v požadavku, jeden volaný j_username a ostatní, j_heslo. Pomocí ověřování založeného na formuláři dojde k realizaci pověření při odeslání formuláře a odeslání uživatelského jména a hesla na server.
Zde je příklad stránky JSP (JavaServer Pages), která používá ověřování na základě formuláře:
Přihlášení Zadejte své uživatelské jméno:Zadejte heslo:
