SSO secure communication flow for web Oracle login

Ток безбедне комуникације кастомизованог web Oracle SSO логина за Хефис Употреба корпоративног стандарда: SSL, smart card login уместо лозинке , Microsoft AD

Дијаграм тока комуникације Клијент / browser ASP скрипт / IIS сервер Java Servlet / логин сервер Oracle SSO сервер Позив Хефис урл-а Oracle 9iAS види да није аутентификована сесија SSO логин кастомизован: Win. Integrated логин успева (можда) Јава логин сервлет, кастомизован: SSO лозинка се рандомизује / ресетује и враћа се SSO- у SSO key (POST) / redirect SSO key (POST) / redirect Хефис SSO успева Припремљен ( Windows domain корисник / SSO key ) пар у инфраструктури AD SSL

Детаљни дијаграм Клијент / browser ASP скрипт / IIS сервер Java Servlet / логин сервер Oracle SSO сервер 0 2 3 2 3 4 application сервер инстанца 1 3* 5 8 6 8 7 8 9 8* 9 4 4* 1

Напомена У дијаграму није директно узет у обзир web cache међуслој који не мења функционалну суштину токова процеса које опсиује овај дијаграм. Сви протоколи на дијаграму су под SSL протоколом ( HTTPS) од тренутка улажења у кастомизовану логин процедуру, и цео даљи рад је предвиђен да буде под SSL (мада и не мора). Када апликација добије SSO сесију (и тиме на серверу „озваничени“ cookie) даље Oracle 9i Application Server / Oracle SSO води рачуна о сесији механизмима који су за то обезбеђени самим Oracle софтвером. Све кастомизације су рађене по раније поменутим званичним Oracle документима онако како је то наведено у документу о инсталацији продукционог окружења.

легенда Опис тока дијаграма: Отворена је нова http сесија – нова инстанца клијента ( IE browser): 0 -> 1: клијент захтева урлом апликација на некој од инстанци апл. Сервера (кроз load balancing и web cache, редирекцију) – ако SSO сесијапостоји онда се наставља рад са апликацијом одавде. 1 -> 2 : апл. сервер препознаје да сесија нема SSO аутентификацију и аутоматски ради редирекцију на SSO сервер и тиме се покреће процес аутентификације 2 -> 3: Oracle SSO генерише свој интерни токен ID ( око 512 b ) и прослеђује га кастомизованом логин урлу ( POST, редирекција, са сервера) – ASP страни (одавде почиње зона кастомизованог логина а завршава се успешним логином) 3 -> 3*: ASP страна је у IIS- у подешена да тражи Windows Integrated Аутентификацију – ако то из било ког разлога не успе (када би ту била BASIC аутентификација онда ако се нпр. лоше унесе налог или лозинка) клијент добија поруку од сервера о неуспелој аутентификацији, или ако успе али користи недозвољен домен добија поруку о томе (и мора поново да се покреће цео поступак).

легенда 3 -> 4: ако у претходном кораку ипак успе аутентфикација, онда се прелази ( login.java ) сервлет и ПРЕ ТОГА, ASP скрипт ради: из REMOTE_USER Session променљиве се преузима корисничко име (проверава се да ли припада HEMONET домену) и прослеђује га инфраструктури (бази на Ромео / Паралакс серверу) заједно са добијеним SSO токеном преко ODBC конекције, а тиме преко мреже путем Oracle TNS secure (SSL) протокола или иза firewall -a 4 -> 5: овде нема комуникације - само промена стања: логин сервлет добија редирекцијом (са клијента) POST методом од ASP стране SSO токен, на основу кога покуша логин против Oracle OID налога = SSO налога, ако пару токен – корисник није истекло време (20 минута тренутно) од тренутка уписа на ASP страни. То се реализује на основу случајно генерисане лозинке (настале у бази) тако што се LDAP Java API позивом промени лозинка налогу према добијеној и онда се уради редирекција на SSO сервер. 4 -> 4*: ако претходно из неког разлога не успе ( SSO токен не постоји и сл. или је прекорачен timeout=20 минута) добија се порука о фаталној грешци приликом логина ( javaLang.error или нешто друго). 5 -> 6: редирекција (са сервера од стране сервлета) ка SSO серверу уз прослеђивање само SSO токена (кастомизован web PL/SQL логин WWSSO_APP_ADMIN_2 који опет консултује налог из базе, и ту МОЖЕ да га обрише, али остаје као неки аудит тренутно )

легенда 6, 7 -> 9: ако претходно успе, SSO сервер креира успешну SSO сесију (и cookie за клијента одговарајући) и редирекција са SSO сервера иде на апликацију (Хефис нпр.) 6, 7 -> 8: ако претходно не успе из неког разлога (нпр. не постоји импортовани или креирани OID корисник који мапира Windows домен / Active Directory корисника прослеђеног из базе) онда сервлет оставља форму за директни логин против SSO / OID корисника налогом и лозинком, и то POST методом (са клијента) шаље SSO серверу 8 -> 7: форма постује налог и лозинку SSO серверу без промене лозинке 7 -> 9: ако претходни логин успе, SSO сервер ради редирекцију на циљану аплкацију. 8 -> 8*: ако корисник у претходном покушају изабере да одустаје од логина враћа му се страна у без аутентификоване SSO сесије. Овај корак је опцион и тренутно није имплементиран.

логови IIS log: #Software: Microsoft Internet Information Services 5.0 #Version: 1.0 #Date: 2004-11-24 15:58:22 #Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status cs(User-Agent) 2004-11-24 15:58:22 194.106.160.233 - 194.106.160.84 443 POST /login.asp - 401 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.0.3705) 2004-11-24 15:58:22 194.106.160.233 HEMONET\z.popovic 194.106.160.84 443 POST /login.asp |11|80004005|[Oracle][ODBC][Ora]ORA-12638:_Credential_retrieval_failed_ 500 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.0.3705) Apache log: 192.168.131.6 - - [24/Nov/2004:17:28:41 +0100] "GET / HTTP/1.0" 200 18352 192.168.131.6 - - [24/Nov/2004:17:28:44 +0100] "HEAD / HTTP/1.1" 200 0 romeo.group.hemofarm.com - - [24/Nov/2004:17:28:44 +0100] "GET /dmsoc4j/Spy?recurse=all&format=xml&operation=get&value=false&units=true&description=true&name=%2F HTTP/1.1" 200 42404 …

SSO secure communication flow for web Oracle login

More Related Content

Featured (20)

SSO secure communication flow for web Oracle login