Jednoduché řešení (nasazení 4/2009)

Z důvodu použití Apache + Tomcat na beta.kiv.zcu.cz, kde:

• probíhá překlad adres - není vidět /opencms/
• Tomcat nepozná, jestli je připojení HTTPS nebo HTTP - nefunguje request.isSecure()
• všechny cookie se odesílají jako non-secure
• zabezpečení stránek se nastavuje v Apache - jestli bude vynuceno HTTPS,

nelze použít řešení s validací.

Nasazeno bylo pouze:

• Kerberos - celé řešení
• pomocí Apache byla zabezpečena přihlašovací stránka do workplace
• upravené příhlašovací JSP z modulu welcome pro frontend - url login_element_secure.jsp bylo zabezpečeno Apachem.

Instalace na ManualModulLogin - Jednoduché řešení.

Kompletní řešení

5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

Cíl: Zabezpečení přihlášení a lepší kontrolu uživatele než přes kontrolu IP (OpenCms interně).

Viz též původní náčrty: Attach:kiv-secure-auth-proces.jpg obrázek - červeně jsou označeny stránky-cookies které jsou secure čili na HTTPS. Attach:opencms-zabezpeceni-frontend.jpg - jak má fungovat zabezpečení při přístupu k frontend obsahu, včetně periodického ověřování autenticity uživatele

1. dojde k přešměrování na HTTPS zabezpečenou stránku (url kde je umístěn login_element_secure.jsp)

• nastane-li chyba při validaci, je uložen příznak do session pro informování skutečného uživatele; útočníkovi je posláno 403 Forbidden a cookie s výsledkem validace - zpracuje login_element.jsp, pokud by se znovu snažil přistoupit s ukradenou session cookie - vyběhne ihned hlášení
• validace úspěšná, ale zjištěn útok (příznak v session); poslána cookie s příznakem útoku - zpracuje login_element.jsp - hlášení o ukradené session; uložení času validace; přechod zpět na HTTP

Instalace na ManualModulLogin - Kompletní řešení.

Instalace na ManualModulLogin - Jednoduché řešení.

Jednoduché řešení (nasazení 4/2009)

Ověření pravosti uživatele se bude dít přes servlet filtr ValidateAuthFilter. Filtr se nastaví, viz ManualModulLogin tak, aby kontroloval veškerou komunikaci.\\

Filtr se chová několika způsoby:

Po přihlášení na zebezpečené stránce by byla session cookie poslána jako secure. Tento stav je nežádoucí kvůlí sdílení session s HTTP. Nutný je tedy zásah do CmsJspLoginBean OpenCms, která je zodpovědná za přihlašování.

1. zabezpečená přihlašovací stránka do worklace (HTTPS)
2. zabezpečená práce ve workplace
3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)
4. login form pro frontend
5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

Cíl: Zabezpečení přihlášení a lepší kontrolu uživatele než přes kontrolu IP (OpenCms interně).

Cíl: Zabezpečení přihlášení a lepší kontrolu uživatele než přes kontrolu IP (OpenCms interně).

K celému se přidá Kerberos autentizace.

1. zabezpečená přihlašovací stránka do worklace (HTTPS)
2. zabezpečená práce ve workplace
3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)
4. login form pro frontend
5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

Body 3. a 4. potřebují pro správnou funkčnost sdílení session mezi HTTPS a HTTP.

nelze použít řešení s validací.

''' Filtr se chová několika způsoby:'''

A.

B.

• nastane-li chyba při validaci, je uložen příznak do session pro informování skutečného uživatele; útočníkovi je posláno 403 Forbidden a cookie s výsledkem validace
• validace úspěšná, ale zjištěn útok (příznak v session); poslána cookie s příznakem útoku - zpracuje login_element.jsp; uložení času validace; přechod zpět na HTTP
• validace úspěšná; uložení času validace; přechod zpět na HTTP

C.

Nasazeno bylo pouze:

• zloděj, útočník = ten který nějak ukradl session ID (ale nemá secure token)
• validace = ověření, zda má přihlášený uživatel secure token

• login_element_secure.jsp - přihlašovací formulář na HTTPS - přesměrování zařídí sám, nebo je možno nastavit ve web.xml stejně jako zabezpečení workplace

Po přihlášení na zebezpečené stránce by byla session cookie poslána jako secure. Tento stav je nežádoucí kvůlí sdílení session s HTTP. Nutný je tedy zásah do [=CmsJspLoginBean=] OpenCms, která je zodpovědná za přihlašování.

Ověření pravosti uživatele se bude dít přes servlet filtr [=ValidateAuthFilter=]. Filtr se nastaví, viz ManualModulLogin tak, aby kontroloval veškerou komunikaci. Parametry filtru jsou:

Termíny:

• zloděj, útočník = ten který nějak ukradl session ID (ale nemá secure token)
• validace = ověření, zda má přihlášený uživatel secure token

Problém je následující:

• vyrobíme secure token cookie, která bude obsahovat hashMD5(session id + sůl)
  • pošleme jako zabezpečenou cookie - máme označeného uživatele, který se skutečně přihlásil; nikdo jiný tuto cookie nebude mít
  • uložíme ho také do session (pro validaci)
• do session uložíme čas přihlášení pro časovou kontrolu uživatele

1. uloží se url požadavku
2. do session se uloží příznak, že validujeme (nutné pro přechod zpět na HTTP)
3. dojde k přešměrování na HTTPS zabezpečenou stránku (url kde je umístěn login_element_secure.jsp)
4. ověří se přitomnost secure token a jeho správnost, několik možností:

1. zabezpečená přihlašovací stránka do worklace (HTTPS)
2. zabezpečená práce ve workplace
3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)
4. login form pro frontend
5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

1. zabezpečená přihlašovací stránka do worklace (HTTPS) 2. zabezpečená práce ve workplace 3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené) 4. login form pro frontend 5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

• zpracovává cookie s výsledekem validace - zobrazuje zprávy pomocí javascriptu - ukradená session

Pokud potřebuji zabezpečit nějakou operaci (formulář atd.) musí se přejít na HTTPS.

1.

zabezpečená přihlašovací stránka do worklace (HTTPS)

2.

zabezpečená práce ve workplace

3.

zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)

4.

login form pro frontend

5.

ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

1. zabezpečená přihlašovací stránka do worklace (HTTPS)

1. zabezpečená přihlašovací stránka do worklace (HTTPS)

2. zabezpečená práce ve workplace

3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)

4. login form pro frontend

5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

1. zabezpečená přihlašovací stránka do worklace (HTTPS)
!!!2. zabezpečená práce ve workplace
!!!3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)
!!!4. login form pro frontend
!!!5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

1.

zabezpečená přihlašovací stránka do worklace (HTTPS)
!!!2. zabezpečená práce ve workplace
!!!3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)
!!!4. login form pro frontend
!!!5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

1. zabezpečená přihlašovací stránka do worklace (HTTPS)
!!!2. zabezpečená práce ve workplace

3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)
!!!4. login form pro frontend

5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

ad 3. + 4.

ad 1. + 2.

vad 3. + 4.

Sdílení session HTTPS + HTTP

ad 5.

• zabezpečení stránek se nastavuje v Apache - jestli bude vynuceno HTTPS,

nelze použít řešení s validací.

Nasazeno bylo pouze:

Instalace na ManualModulLogin - Dočasné řešení.

Požadavky

3. zabezpečená přihlašovací stránka na frontendu (odhlášení nebude zabezpečené)\\

Analýza a řešení

• umožňuje odhlášení

Nasazení (4/2009)

• probíhá překlad adres - není vidět /opencms/

• upravené příhlašovací JSP z modulu welcome pro frontend - url login_element_secure.jsp bylo zabezpečeno Apachem.

Cíl: Zabezpečení přihlášení a lepší kontrolu uživatele než přes kontrolu IP (OpenCms interně).

Ověření pravosti uživatele se bude dít přes servlet filtr ValidateAuthFilter. Filtr se nastaví, viz ManualModulLogin tak, aby kontroloval veškerou komunikaci. Parametry filtru jsou:

Nasazení (4/2009)

Z důvodu použití Apache + Tomcat na beta.kiv.zcu.cz, kde:

• probíhá překlad adres - není vidět /opencms/
• Tomcat nepozná, jestli je připojení HTTPS nebo HTTP - nefunguje request.isSecure()
• všechny cookie se odesílají jako non-secure
• zabezpečení stránek se nastavuje v Apache - jestli bude vynuceno HTTPS

Z tohoto důvodu nelze použít řešení s validací.

Použito bylo pouze:

• Kerberos - celé řešení
• pomocí Apache byla zabezpečena přihlašovací stránka do workplace
• upravené příhlašovací JSP z modulu welcome pro frontend - url login_element_secure.jsp bylo zabezpečeno Apachem.

Instalace na ManualModulLogin.

1. zabezpečená přihlašovací stránka do worklace (HTTPS)
2. zabezpečená práce ve workplace (HTTPS)

5. ověření pravosti přihlášeného uživatele pracujícího přes HTTP (rozpoznání zloděje session)

Cílem je: Zabezpečení přihlášení a lepší kontrolu uživatele než přes kontrolu IP (OpenCms interně).

Dojde k vynucení HTTPS u stránek ležících v /opencms/system/* a podadresářích. Zabezpečí se tedy přihlašovací formulář do workplace (/opencms/system/login) a samotné stránky workplace (/opencms/system/wrkplace).

• login_element.jsp se umístí do template (na HTTP)

• login_element_secure.jsp - přihlašovací formulář na HTTPS - přesměrování zařídí sám, nebo je možno nastavit ve web.xml stejně jako zabezpečení workplace

Body 3. a 4. potřebují pro správnou funkčnost sdílení session mezi HTTPS a HTTP.

• pokud se přihlásíme na stránce s HTTPS, je session cookie odeslána jako secure, což působí problémy při přechodu na HTTP (session cookie není poslána a my figurujeme jako nepřihlášeni)
• pokud bychom se přihlásili na HTTP (což nebudeme dělat, ale uvedu jej pro úplnost), je session cookie vyslána jako nezabezpečená, tím je umožněn bezproblémový přechod na HTTPS, aniž bychom ztratili session. Problém je ovšem v tom, že máme vyzrazený identifikátor session.

Sdílení session HTTPS + HTTP

Po přihlášení na zebezpečené stránce by byla session cookie poslána jako secure. Tento stav je nežádoucí kvůlí sdílení session s HTTP. Nutný je tedy zásah do CmsJspLoginBean OpenCms, která je zodpovědná za přihlašování.

• znemožníme přihlášení nezabezpečeným způsobem (HTTP)

Takto je zaručeno sdílení session po přihlášení na HTTPS a případném přechodu na HTTP. Máme taktéž označeného pravého uživatele

Pokud jsme na nezabezpečeném HTTP, počítá při každém požadavku čas od přihlášení. Uplyne-li doba delší než delta t a je-li náš požadavek GET, začne validační smyčka:

• do session se uloží příznak, že validujeme (nutné pro přechod zpět na HTTP)
• dojde k přešměrování na HTTPS zabezpečenou stránku (url kde je umístěn login_element_secure.jsp)

• validace úspěšná, ale zjištěn útok (příznak v session), poslána cookie s příznakem útoku, uložení času validace, přechod zpět na HTTP
• validace úspěšná, uložení času validace, přechod zpět na HTTP

Pokud sami přejdeme na HTTPS, je validován každý náš požadavek (GET, POST). Zůstáváme na HTTPS. Neukládá se čas validace pro případ krádeže session cookie a přístup útočníka na HTTP (bude zachycen filtrem - vyprší čas, na HTTPS by byl zachycen okamžitě). Při neúspěšné validaci se posílá 403 Forbidden.

• zabezp.přihl do workplace (/system/login/) -- bude přes std opencms-system.xml (viz http://opencms-wiki.org/Enforcing_SSL_Encryption_for_the_Opencms_workplace)

• zabezp.přihl na frontendu tj. možnost dát login form a zpracování do template.jsp (http://localhost:8080/opencms/opencms/release/installation.html na URI, *a /system/modules/org.opencms.welcome/templates/welcome.jsp + /system/modules/org.opencms.welcome/elements/login_element.jsp ve VFS)

K celému se přidá Kerberos autentizace.

Dojde k vynucení https u stránek ležících v /opencms/system/* a podadresářích. Zabezpečí se tedy přihlašovací formulář do workplace (/opencms/system/login) a samotné stránky workplace (/opencms/system/wrkplace).

• přihlášení (odkaz na zebezpečený formulář, nutno nastavit odkaz manuálně)

• zpracovává cookie s výsledekem validace - zobrazuje zprávy pomocí javascriptu

• umožňuje také odhlášení

Provedeme několik úprav:

• po přihlášení cookie pošleme cookie se session id jako nezbezpečenou (přemažeme původní zabezpečenou)

• do session uložíme čas přihlášení pro další kontrolu uživatele

Takto je zaručeno sdílení session po přihlášení na https a případném přechodu na http. Máme taktéž označeného pravého uživatele

Ověření pravosti uživatele se bude dít přes filtr ValidateAuthFilter. Filtr se nastaví, viz ManualModulLogin tak, aby kontroloval veškerou komunikaci. Parametry filtru jsou:

• url na zabezpečenou validační stránku
• timeout pro validaci (po uplynutí tohoto času se provede validační smyčka, pouze pro HTTP)

Jsme-li nepřihlášeni, propouští komunikaci dále.

• do session se uloží příznak, že validujeme (nutné pro přechod zpět na http)
• dojde k přešměrování na https zabezpečenou stránku (url kde je umístěn login_element_secure.jsp)

• nastane-li chyba při validaci, je uložen příznak do session pro informování skutečného uživatele, útočníkovi je posláno 403 Forbidden a cookie s výsledkem validace
• validace úspěšná, ale zjištěn útok (příznak v session), poslána cookie s příznakem útoku, uložení času validace, přechod zpět na http

Pokud sami přejdeme na HTTPS, je validován každý náš požadavek (GET, POST). Zůstáváme na HTTPS. Neukládá se čas validace pro případ krádeže session cookie a přístup útočníka na http (bude zachycen filtrem - vyprší čas, na https by byl zachycen okamžitě). Při neúspěšné validaci se posílá 403 Forbidden.

1. zabezpečená přihlašovací stránka do worklace (https)\\

3. zabezpečená přihlašovací stránka na frontendu\\

ad 3. + 4.

ad 5.

Současný stav (4/2009)

• validace úspěšná, uložení času validace, přechod zpět na http
• validace úspěšná, ale zjištěn útok, poslána cookie s příznakem útoku, uložení času validace, přechod zpět na http

Pokud sami přejdeme na HTTPS, je validován každý náš požadavek (GET, POST). Zůstáváme na HTTPS. Neukládá se čas validace pro případ krádeže session cookie a přístup útočníka na http (bude zachycen filtrem, na https by byl zachycen okamžitě). Při neúspěšné validace se posílá 403 Forbidden.

Současný stav (4/2009) Apache + Tomcat Nelze zjistit, zda jsme na http nebo https. Stránky se zabezpečí na Apache. Nasazen pouze Kerberos a zabezpečené příhlašovací stránky (workplace + 2 jsp pro frontend).

TODO

• uložíme ho také do session

• do session uložíme čas přihlášení pro kontrolu uživatele

Ověření pravosti uživatele se bude dít přes filtr ValidateAuthFilter. Filtr se nastaví, viz ManualModulLogin.

Filtr se chová několika způsoby:

A. Jsme-li nepřihlášeni, propouští komunikaci.

B. Pokud jsme na nezabezpečeném http, počítá při každém požadavku čas od přihlášení. Uplyne-li doba delší než delta t a je-li náš požadavek GET, začne validační smyčka:

• uloží se url požadavku
• do session se uloží příznak, že validujeme (pro přechod zpět na http)
• dojde k přešměrování na zabezpečenou stránku (login_element_secure.jsp)
• ověří se přitomnost secure token a jeho správnost, několik možností:
  • nastane-li chyba, je uložen příznak do session pro informování skutečného uživatele, útočníkovi je posláno 403 Forbidden
  • validace úspěšná,
  • validace úspěšná, ale zjištěn útok, přechod zpět na http, poslána cookie s příznakem útoku
    • přechod zpět na http

C. Pokud sami přejdeme

Obsahuje v adresáři /elements soubory login_element.jsp a login_element_secure.jsp.

• login_element.jsp se umístí do template (na http)

• login_element_secure.jsp - přihlašovací formulář na https - přesměrování zařídí sám, nebo je možno nastavit ve web.xml stejně jako zabezpečení workplace
  • na něm se bude také provádět ověření přihlášeného uživatele

• pokud bychom se přihlásili na http (což nebudeme dělat, ale uvedu jej pro úplnost), je session cookie vyslána jako nezabezpečená, tím je umožněn bezproblémový přechod na https, aniž bychom ztratili session. Problém je ovšem v tom, že máme vyzrazený identifikátor session.

Po analýze problému se nabízí řešení, které pomáhá i k řešení bodu 5.

Sdílení session https + http Po přihlášení na zebezpečené stránce by byla session cookie poslána jako secure. Tento stav je nežádoucí kvůlí sdílení session s http. Nutný je tedy zásah do CmsJspLoginBean OpenCms, která je zodpovědná za přihlašování.

Úpravy:

• znemožníme přihlášení nezabezpečeným způsobem (http)
• cookie se session id pošleme jako nezbezpečenou (přemažeme původní zabezpečenou)
• vyrobíme secure token cookie, která bude obsahovat hashMD5(session id + sůl), a pošleme jako zabezpečenou cookie
  • máme označeného uživatele, který se skutečně přihlásil, nikdo jiný tuto cookie nebude mít

Takto je zaručena sdílení session po přihlášení na https a případném přechodu na http.

Body 3. a 4. potřebují pro správnou funkčnost sdílení session mezi https a http.

Problém je následující:

• pokud se přihlásíme na stránce s https, je session cookie odeslána jako secure, což působí problémy při přechodu na http (session cookie není poslána a my figurujeme jako nepřihlášeni)
• pokud bychom se přihlásili na http (což nebudeme dělat, ale uvedu jej pro úplnost), je session cookie vyslána jako nezabezpečená, což umožňuje bezproblémový přechod na https, aniž bychom ztratili session. Problém je ovšem v tom, že máme vyzra

ad 5.

ad 1. + 2.

ad 3. + 4.

• login_element.jsp se umístí do template (na https)

Obsahuje v adresáři /elements soubory login_element.jsp a login_element_secure.jsp.

• login_element.jsp se umístí do template
• umožňuje:
  • přihlášení (odkaz na zebezpečený formulář)
  • odhlášení

Pro účely zabezpečeného přihlášení byl upraven modul org.opencms.welcome z OpenCms 6.2.3. Obsahuje v adresáři /elements soubory login_element.jsp a login_element_secure.jsp.

Požadavky

Analýza a řešení

ad 1. + ad 2.

ad 3. Pro účely zabezpečeného přihlášení byl upraven modul Welcome z OpenCms 6.2.3

1. zabezpečená přihlašovací stránka do worklace (https) 2. zabezpečená práce ve workplace (https)

3. zabezpečená přihlašovací stránka na frontendu 4. login form pro frontend

5. ověření pravosti přihlášeného uživatele pracujícího přes http (rozpoznání zloděje session)

Analýza a řešení

ad 1. + ad 2. Pro zabezpečení práce ve workplace včetně přihlášení je třeba nastavit v %OPENCMS%/WEB-INF/web.xml:

<security-constraint>

   <web-resource-collection>
      <web-resource-name>SecureWorkplace</web-resource-name>
      <url-pattern>/opencms/system/*</url-pattern>
   </web-resource-collection>
   <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>

</security-constraint> 

• zabezpečená přihlašovací stránka do worklace + zabezpečená práce
• zabezpečená přihlašovací stránka na frontendu
• ověření pravosti přihlášeného uživatele (rozpoznání zloděje session)

NEW

Požadavky

• zabezpečená přihlašovací stránka (frontend + backend)
• zabezpečená práce na backend
• ověření autenticity přihlášeného uživatele (rozpoznání zloděje session)

• zabezp.přihl do workplace (/system/login/) -- bude přes std opencms-system.xml (viz http://opencms-wiki.org/Enforcing_SSL_Encryption_for_the_Opencms_workplace)

Princip: uživatel dostane jako secure cookie token, který se ověřuje při odhlášení nebo verifikaci session; přihlášení, odhlášení a verifikace se děje na HTTPS přímo nebo přes servlet filter redirect.

• dostane 403 Forbidden a cookie "invalid user"

• nastaví se cookie "valid user" s příznakem problému

Attach:opencms-zabezpeceni-frontend.jpg - jak má fungovat zabezpečení při přístupu k frontend obsahu, včetně periodického ověřování autenticity uživatele

Jak to funguje

Cíl: zabezpečení přihlášení lepší než přes kontrolu IP.

Princip: uživatel dostane jako secure cookie token, který se ověřuje při odhlášení nebo verifikaci session; přihlášení, odhlášení a verifikace se děje na HTTPS přímo nebo přes javascript redirect.

Jak to funguje!!!

• zlodějovi se zobrazí javascriptová výhrůžka a "zruší se" obsah stránky => zloděj se bude točit pořád dokola na stránce s výhrůžkou dokud si nepřepíše URL v Location prohlížeče.

Výhrůžka se zobrazuje přes:

• frontend - typicky v login elementu šablony, např. /system/modules/org.opencms.welcome/elements/login_element.jsp

Když toto nastane, tak se

• zloději znemožní odhlášení, viz výše, aby nemohl zrušit session uživatele;
• uživateli při nejbližší validaci zobrazí varování "bacha někdo asi ukradl session, ihned se odhlašte" -- jakmile se hodný odhlásí, zruší se session i pro zloděje.

Odhlášení, průběžná validace a řešení zlodějů

Termíny: uživatel = ten který se původně přihlásil, zloděj = ten který nějak ukradl session ID (ale nemá secure token).

Když zloděj přijde na stránku, kde je přes šablonu vynuceno logout nebo verify, tak

Když zloděj (= ukradl session ID) přijde na stránku, kde je logout nebo verify, tak

• ho server nechá na HTTPS (tj. bude znova ověřovat secure token)
• do session se uloží příznak "ukradená session"
• zlodějovi se zobrazí javascriptová výhrůžka => zloděj se bude točit pořád dokola na stránce s výhrůžkou dokud si nepřepíše URL v Location prohlížeče.

Když toto nastane, tak tomu "hodnému" se při nejbližší validaci zobrazí varování "bacha někdo asi ukradl session, ihned se odhlašte" -- jakmile se hodný odhlásí, zruší se session i pro zloděje.

Jak a kde se zobrazuje výhrůžka:

• frontend - v login elementu šablony
• backend - v /system/workplace/views/explorer/explorer_files.jsp

• možnost nejen přihlásit, ale i kdykoli ověřit, např. při přechodu textová stránka -> nějaký formulář
• vše přes CmsJspLoginBean?

Mělo by ve finále dělat

• zabezp.přihl do workplace (/system/login/)
• zabezp.přihl na frontendu tj. možnost dát login form a zpracování do template.jsp (http://localhost:8080/opencms/opencms/release/installation.html na URI, a /system/modules/org.opencms.welcome/templates/welcome.jsp + /system/modules/org.opencms.welcome/elements/login_element.jsp ve VFS)
• možnost nejen přihlásit, ale i kdykoli ověřit, a samosebou taky odhlásit, vše přes CmsJspLoginBean?
• pokud možno, možnost naštelovat v config/system.xml která je login page v http-authentication > form-based elementu

Odhlášení a řešení zlodějů

Když zloděj (= ukradl session ID) přijde na stránku, kde je logout nebo verify, tak ho server nechá na HTTPS (tj. bude znova ověřovat secure token) a ještě mu zobrazíme javascriptovou výhrůžku => zloděj se bude točit pořád dokola na stránce s výhrůžkou dokud si nepřepíše URL v Location prohlížeče.

Attach:kiv-secure-auth-proces.jpg obrázek - červeně jsou označeny stránky-cookies které jsou secure čili na HTTPS.

Design pro zabezpečené přihlášení do OpenCms s ověřením proti Kerberos ZČU:

Attach:kiv-secure-auth-proces.jpg

• vezme se Boháčovo krb auth beze změn
• před/okolo něj se v CmsJspLoginBean.displayDialog() doplní generování https stránek, přesměrování přes 302, atd dle obrázku

Je třeba ještě dořešit následné zobrazování frontendu a odhlášení - viz jak to funguje v distro instalaci OpenCms.

Zpět na RedSys

-vložit obr-

vezme se Boháčovo krb auth beze změn před/okolo něj se v CmsJspLoginBean? displayDialog() se doplní generování https stránek, přesměrování přes 302, atd dle obrázku

dořešit následné zobrazování frontendu a odhlášení - viz distro instralace OpenCms