Your SlideShare is downloading. ×
0
SSO secure communication flow for web Oracle login
SSO secure communication flow for web Oracle login
SSO secure communication flow for web Oracle login
SSO secure communication flow for web Oracle login
SSO secure communication flow for web Oracle login
SSO secure communication flow for web Oracle login
SSO secure communication flow for web Oracle login
SSO secure communication flow for web Oracle login
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

SSO secure communication flow for web Oracle login

510

Published on

Continuation of outdated (but dear to me) docs - this is also part of six years old solution (it is still working even today) for SSO login into forms and portal integrated with Microsoft AD and smart …

Continuation of outdated (but dear to me) docs - this is also part of six years old solution (it is still working even today) for SSO login into forms and portal integrated with Microsoft AD and smart card login

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
510
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  1. Ток безбедне комуникације кастомизованог web Oracle SSO логина за Хефис Употреба корпоративног стандарда: SSL, smart card login уместо лозинке, Microsoft AD
  2. Дијаграм тока комуникације Oracle Клијент / ASP скрипт / IIS Java Servlet / логин SSO browser сервер сервер сервер Позив Хефис урл-а Oracle 9iAS види да није аутентификована сесија AD SSO логин SSO key (POST) / redirect кастомизован: Win. Integrated логин успева SSL (можда) Припремљен ( Windows domain корисник / SSO key ) Јава логин сервлет, пар у кастомизован: инфраструктури SSO лозинка се SSO key (POST) / redirect рандомизује / ресетује и враћа се SSO-у SSO успева Хефис
  3. Детаљни дијаграм Oracle application Клијент / ASP скрипт / IIS Java Servlet / логин SSO сервер browser сервер сервер сервер инстанца 0 1 2 1 3* 3 2 3 4 4* 4 5 6 9 8 8 7 9 8* 8
  4. Напомена • У дијаграму није директно узет у обзир web cache међуслој који не мења функционалну суштину токова процеса које опсиује овај дијаграм. • Сви протоколи на дијаграму су под SSL протоколом (HTTPS) од тренутка улажења у кастомизовану логин процедуру, и цео даљи рад је предвиђен да буде под SSL (мада и не мора). • Када апликација добије SSO сесију (и тиме на серверу „озваничени“ cookie) даље Oracle 9i Application Server / Oracle SSO води рачуна о сесији механизмима који су за то обезбеђени самим Oracle софтвером. Све кастомизације су рађене по раније поменутим званичним Oracle документима онако како је то наведено у документу о инсталацији продукционог окружења.
  5. легенда • Опис тока дијаграма: Отворена је нова http сесија – нова инстанца клијента (IE browser): • 0 → 1: клијент захтева урлом апликација на некој од инстанци апл. Сервера (кроз load balancing и web cache, редирекцију) – ако SSO сесијапостоји онда се наставља рад са апликацијом одавде. • 1 → 2: апл. сервер препознаје да сесија нема SSO аутентификацију и аутоматски ради редирекцију на SSO сервер и тиме се покреће процес аутентификације • 2 → 3: Oracle SSO генерише свој интерни токен ID (око 512b) и прослеђује га кастомизованом логин урлу (POST, редирекција, са сервера) – ASP страни (одавде почиње зона кастомизованог логина а завршава се успешним логином) • 3 → 3*: ASP страна је у IIS-у подешена да тражи Windows Integrated Аутентификацију – ако то из било ког разлога не успе (када би ту била BASIC аутентификација онда ако се нпр. лоше унесе налог или лозинка) клијент добија поруку од сервера о неуспелој аутентификацији, или ако успе али користи недозвољен домен добија поруку о томе (и мора поново да се покреће цео поступак).
  6. легенда • 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 који опет консултује налог из базе, и ту МОЖЕ да га обрише, али остаје као неки аудит тренутно)
  7. легенда • 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 сесије. Овај корак је опцион и тренутно није имплементиран.
  8. логови • 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 HEMONETz.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] quot;GET / HTTP/1.0quot; 200 18352 192.168.131.6 - - [24/Nov/2004:17:28:44 +0100] quot;HEAD / HTTP/1.1quot; 200 0 romeo.group.hemofarm.com - - [24/Nov/2004:17:28:44 +0100] quot;GET /dmsoc4j/Spy? recurse=all&format=xml&operation=get&value=false&units=true&des cription=true&name=%2F HTTP/1.1quot; 200 42404 …

×