Izgradnja AD FS uključuje rad na različitim scenarijima za izgradnju uključujući B2B, B2E i B2C Federation scenarija. Ključni aspekti su: identifikovanje kako AD FS saobraćaj prolazi kroz svaki federation scenario i odlučiti se za jedan od nekoliko mogućih izgradnji AD FS-a.

AD FS opcije izgradnje (Deployment Options)

Uspeh AD FS dizajna zavisi od tačne identifikacije AD FS ciljeva izgradnje. Jednom kada odredimo ciljeve koji se odnose na izgradnju, možemo da implementiramo specifični AD FS dizajn koji u potpunosti ispunjava ciljeve izgradnje AD FS-a. Postoje tri primarna AD FS dizajna. Ipak, administratori takođe mogu da kreiraju hibridni ili prilagođeni dizajn da bi ispunili potrebe organizacije. Administrator može da koristi bilo koju kombinaciju AD FS ciljeva izgradnje (Deployment Goals) da bi kreirao potrebne dizajne.

Imamo sledeće opcije prilikom izgradnje:

  • Federated Web SSO: u ovoj opciji, mogu da postoje dve organizacije ili sigurnosno područje u jednoj organizaciji koje želi da pruži pristup aplikacijama u organizaciji.

  • Federated Web SSO with Forest Trust: u ovoj opciji, mada organizacije koriste više šuma da bi upravljali korisničkim nalozima, oni ipak koriste AD FS da bi pružili SSO karakteristike.

  • Web SSO: U ovoj opciji, jedna organizacija izgrađuje jednu ili više veb aplikacija kojoj korisnici mogu da pristupe unutar organizacije ili između organizacija. Uz pomoć AD FS, korisnici mogu da pristupe ovim aplikacijama nakon jedne autentifikacije.


Kako AD FS saobraćaj protiče u B2B Federation scenariju

 

 Slika 18.1

Administrator može da izgradi AD FS da bi podržao B2B scenarija i saradnju poslovnih jedinica sa nezavisnim šumama. Ovaj tip izgradnje pomaže organizaciji da kreira odnos kao Federation poverenje za korisnike u jednoj organizaciji (Account Partner) da bi pristupili veb aplikacijama u drugoj organizaciji (Resource Partner). Sledeći koraci ilustruju AD FS protok saobraćaja u B2B:

  1. Korisnik u organizaciji A pravi zahtev koristeći HTTPS (Hypertext Transfer Protocol Secure). Ovaj zahtev je za pristupanje aplikaciji koja radi na veb serveru u kompaniji B.

  2. AD FS veb agent presreće zahtev i proverava sa veb servera da bi video da li je klijent prezentovao Cookie da bi legitimizovao svoj zahtev.

  3. Klijent šalje HTTPS zahtev ka Federation Server-u Account Partner-a da bi odredio lokaciju naloga za tog korisnika. Ovaj proces je poznat kao Home Realm Discovery.

  4. Klijent je preusmeren ka Federation Server-u Account Partner-a u kompaniji A.

  5. Klijent isporučuje HTTPS zahtev ka Federation Service-u Account Partner-a.

  6. AD DS koristi Windows Integrated Authentication da bi autentifikovao korisnika. Korisnik takođe može da bude autentifikovan kada on ili ona ponudi svoje podatke (Credentials), kada to zatraži Federation Server.

  7. AD DS autentifikuje korisnika i vraća Success poruku ka Federation serveru.

  8. Klijent prima autentifikacioni Cookie sa traženim podacima koji su smešteni u digitalno potpisani sigurnosni token. Dalje, dešava se preusmeravanje nazad ka Federation servisu Resource partnera. 

  9. Klijent šalje sigurnosni token ka Federation Servisu Resource partnera za validaciju sigurnosnog tokena.

  10. Federation server kreira, potpisuje i izdaje novi token klijentu, nakon uspešne validacije sigurnosog tokena.

  11. Veb agent prima zahtev i odrađuje proces validacije potpisanog tokena. Ako je uspešno, agent iznajmljuje Cookie i upućuje zahtev ka Web Server procesu.


Kako AD FS saobraćaj protiče u B2E Federation scenariju

 Slika 18.2

Sledeći koraci ilustruju AD FS protok saobraćaja u B2E Federation scenariju:

  1. Zaposleni u kompaniji B putuje u koristi svoj veb pretraživač da bi keirao zahtev preko HTTPS protokola kako bi omogućio pristup aplikaciji koja radi na veb serveru u Perimeter mreži.

  2. AD FS veb agent presreće zahtev i vrši proveru sa veb servera da bi video da li je klijent prezentovao Cookie i njime legitimizovao zahtev. Ako klijent nema potreban Cookie, AD FS veb agent preusmerava klijenta ka Federation serveru u mreži gde se nalazi resurs.

  3. Klijent šalje HTTPS zahtev ka Federation serveru u mreži resursa.

  4. Resource Federation server preusmerava klijenta ka Proxy serveru Account Federation-a.

  5. Proxy Server Account Federation-a zahteva korisničke podatke (Credentials), i nakon toga prosleđuje zahtev ka Account Federation serveru.

  6. Account Federation server prosleđuje zahtev za autentifikacijom ka AD DS domenskom kontroleru.

  7. Ako aktivni direktorijum autentifikuje korisnika, ona šalje Success poruku nazad ka Account Federation serveru zajedno sa drugim informacijama koje se odnose na korisnika (Directory-attributes & Group Memberships).

  8. Ako je autentifikacija uspešna, autentifikacione i druge informacije se šalju ka klijentu koristeći Proxy, sa preusmerenom porukom koja kaže klijentu da predstavi sigurnosni token Resource Federation servisu.

  9. Veb pretraživač prezentuje sigurnosni token Resource Federation serveru. Resource Federation server izgrađuje sigurnost AD FS autentifikacione tokene za veb aplikaciju.

  10. Resource Federation server pruža token ka veb pretraživaču i preusmerava klijenta da se konektuje na AD FS veb aplikaciju.

  11. Veb agent prima zahteve i AD FS Autentifikational Cookie. Aplikacija je Windows NT token-based aplikacija i nije Claims-aware aplikacija. Iz tog razloga, aplikacija mora da izgradi kopiju Windows NT tokena iz sigurnosnog tokena. Aplikacija nakon toga koristi taj Windows NT token da bi prikazao korisnički nalog i pružio odgovarajući nivo pristupa.


Kako AD FS saobraćaj protiče kroz B2C Federation scenario

Organizacija može da individualnim korisnicima, koji nisu zaposleni u organizaciji ili možda nemaju Partner User Accounts (korisničke naloge) ponudi resurse kroz Internet. Organizacija prvo kreira korisničke naloge za te kupce u AD LDS. Odrađuje se jedan proces autentifikacije i nakon njega dozvoljava pristup svim aplikacijama.

Sledeća lista ilustruje AD FS protok saobraćaja u B2C Federation scenariju:

  1. Kupac preduzeća B koristi veb pretraživač da bi kreirao zahtev preko HTTPS za pristup aplikaciji koja radi na veb serveru na Perimeter mreži u kompaniji B.

  2. AD FS veb agent presreće zahtev i vrši proveru sa veb servera da bi video da li je klijent prezentovao Cookie i njime legitimozovao zahtev. Ako klijent nema potreban Cookie, klijentski zahtev se odbija i klijent se preusmerava ka Proxy serveru u federaciji.

  3. Klijent šalje HTTPS zahtev ka Proxy serveru federacije. Klijent se preusmerava ka autentifikacionoj stranici Proxy servera i od njega se traži da upiše Logon informacije.

  4. Federation Proxy server prihvata logon informacije, i zahtev se šalje ka Federation servisu resursa.

  5. Federation server ide direktno ka Local Account Store-u koji se naziva AD LDS da bi zahtevao autentifikaciju za korisnika.

  6. AD LDS proverava autentifikaciju korisnika. Resource Federation Server dolazi do atributa od AD LDS koristeći LDAP. Nakon toga on izgrađuje sigurnost i AD FS autentifikacione tokene za AD FS-enabled veb server aplikaciju.

  7. Autentifikacione informacije i druge informacije se smeštaju u Claim i šalju nazad ka klijentu kroz Proxy koristeći preusmerenu poruku, koja obaveštava klijenta da mora da prezentuje sigurnosni token u origianlno URL-u.

  8. AD FS veb agent prima zahtev, odrađuje proces validacije potpisanog tokena, i ako je validacija uspešna, iznajmljuje drugi AD FS autentifikacioni Cookie. Dalje, forvarduje zahtev ka veb servis procesu, koji pruža pristup aplikaciji na osnovu Claim-a.


AD FS Deployment Considerations (mišljenja u vezi sa izgradnjom AD FS)

Potrebno je obratiti pažnju na sledeće tačke prilikom dizajniranja AD FS izgradnje:

  • Izgradnja AD FS scenarija: Scenario koji želimo da izgradimo će odrediti zahteve za našu AD FS soluciju. Na primer, ako pružimo saradnju između organizacija, izgradićemo Federated Web SSO Scenario. Sa druge strane, ako pružimo pristup Web-based aplikaciji, našim zaposlenima ili našim kupcima, možemo da izgradimo ili Web SSO ili Federated Web SSO Alonside Forest Trust scenario.
     
  • Upravljanje sertifikatima: Moramo da odredimo da li ćemo koristiti druge proizvođače (Third-party) za sertifikate servera ili ćemo da izgradimo Microsoft Certificate Services. Možemo da koristimo sertifikate za potpisivanje tokena i korišćenje SSL ili TLS protokola. Takođe možemo da izgradimo self.signed sertifikate za Federation Service. Self-signed sertifikati ne zahtevaju CA. Moramo da konfigurišemo ove sertifikate eksplicitno u određenim lokacijama na serveru kao poverljive (Trusted) sertifikate. Sa Self-signed sertifikatima, teško je uspostaviti infrastrukturu za upravljanje sertifiktima, obnavljanje i ukidanje sertifikata.

  • Directory Store zahtevi: Moramo da odredimo lokaciju gde ćemo smeštati korisničke naloge. Odgovarajuće Storage lokacije bi mogle da uključuju AD DS & AD LDS. Takođe možemo da implementiramo odvojeni Directory Store od našeg internog okruženja.

  • Tip aplikacija: Na osnovu tipa aplikacije koju želimo da izgradimo sa AD FS, moramo da odredimo da li je potreban Forest Trust između Directory Stores koje hostuju naloge i Resource Federation servere. Na primer, Token-based aplikacija će možda zahtevati specifičnu konfiguraciju, dok to Claims-aware aplikacija neće zahtevati.
Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

  • AD FS scenarija za izgradnju 1
  • AD FS scenarija za izgradnju 2
  • AD FS scenarija za izgradnju 3