Ce probleme de relații B2B am în minte? Imaginați-vă că compania producătoare de biciclete și a numit Fabrikam, vrea să creeze o aplicație web care va permite dealeri autorizați să achiziționeze biciclete și piese de schimb la prețuri en-gros. În acest caz, compania are mai mult de două sute de organizații de distribuitori, fiecare dintre ele având mai multe persoane care vor avea nevoie de această cerere. Fabrikam are nevoie de un mecanism sigur de conectare.
Soluția evidentă este crearea unei baze de date care conține nume de utilizator și parole, dar această soluție poate fi foarte costisitoare și consumatoare de timp. Dacă cineva îl numește pe Fabrikam, spunând că este angajat al unui anumit dealer, cum va verifica compania această afirmație? Probabil că va trebui să contacteze un agent din cadrul organizației de distribuitori pentru a verifica statutul angajatului înainte de ai da un nou cont. Acum, imaginați-vă costul menținerii unui astfel de cont: oamenii uită uneori nume, parole și au alte probleme. Și ce se întâmplă dacă angajatul este demis din organizația dealer? Va reaminti tuturor că trebuie să informați Fabrikam în timp despre ștergerea contului acestui utilizator? Dacă nu, un astfel de utilizator poate veni acasă și poate plasa comenzi false în numele dealerului.
Rețineți că factorul de încredere aici joacă, de asemenea, un rol. Fabrikam are încredere fiecărui comerciant că îi va oferi o listă exactă a angajaților cărora li se permite să facă comenzi prin intermediul aplicației web Fabrikam.
Soluție utilizând ADFS
ADFS vă ajută să stabiliți relații de încredere și să reduceți nevoia de conturi de utilizator. De ce să creați o bază de date de conturi de utilizator pentru aplicația dvs. atunci când dealerii au deja software pentru autentificarea utilizatorilor?
Arhitectura ADFS
Acum vă voi arăta diferitele părți ale ADFS și veți explica o anumită terminologie. În orice relație federativă, o parte oferă utilizatorilor (conturi), iar cealaltă - aplicații (resurse). După instalarea programului ADFS, configurați politica de încredere prin modulul de administrare ADFS (este situat în folderul Instrumente administrative) și compuneți o listă de parteneri cu care doriți să stabiliți relații federalizate (creați o federație). Utilizatorii organizației partenere vor accesa aplicațiile ADFS activate de partenerul de resurse utilizând conturile existente. În Fig. Figura 1 prezintă arborele de politică de încredere ADFS al ambelor părți care au format federația.
Fig. 1. Politica pentru doi parteneri
Autentificare federalizată
Amintiți-vă agentul web din aplicația care căuta un cookie pentru a vă conecta? A început toată secvența de evenimente. Acum, când există cookie-ul, agentul web o deschide și citește revendicările din jetonul SAML emis de Serviciul Federației Fabrikam. După aceasta, agentul web permite descărcarea paginii web a aplicației. Dacă aplicația trebuie să cunoască numele utilizatorului conectat, este suficient să verificați locul obișnuit: HttpContext.User.Identity.Name.
IIdentity, folosit pentru a transmite aceste informații, puse în aplicare în SingleSignOnIdentity tip, care oferă, de asemenea, o serie de caracteristici utile, inclusiv metoda de autentificare utilizată de către partenerul de cont pentru a autentifica utilizatorul în cadrul organizației lor. Din această clasă, aplicația poate învăța și întregul set de aplicații trimise de serviciul de federație.
Protejarea conectării federalizate
Acum, să aruncăm o privire mai atentă la cât de sigură este login-ul. Un vector de atac poate fi să citească jetoanele SAML și apoi să le joace, înlocuind un utilizator legitim. Pentru a preveni acest lucru, toată comunicarea are loc prin intermediul protocolului HTTPS. Acest lucru este foarte important; dacă încercați să instalați ADFS fără a instala un certificat SSL pentru site-ul Web implicit în IIS, programul de instalare ADFS vă avertizează și iese din modul de instalare înainte de a începe.
Și cum rămâne cu modulele cookie care conțin aplicații utilizate la intrarea în sistem? Dacă utilizatorul dorea să-și ridice privilegiile la accesarea aplicației, el putea să adauge aplicațiile la simbolul SAML în cookie-ul său! Dar acest tip de falsificare a datelor poate fi detectat, deoarece fiecare simbol SAML este semnat cu o cheie privată cunoscută numai de serviciul de federație care a emis-o. Toate acestea contează atunci când implementați ADFS. Dacă sunteți partener de resurse, fiecare dintre partenerii dvs. de cont trebuie să furnizeze certificate pentru serviciile lor de federație. Serviciul dvs. de federație a resurselor va utiliza certificatul partener de cont pentru a verifica semnăturile în jetoanele SAML. Agentul web ar trebui să facă ceva similar, verificând că fiecare jeton SAML pe care îl primește prin intermediul modulului cookie pentru a vă conecta este semnat de către Serviciul federal al partenerului de resurse.
Prăjiturile ADFS, marcate întotdeauna pavilion biți Secure care indică faptul că browser-ul ar trebui să trimită cookie-ul peste HTTPS, nu HTTP. Prin urmare, în cazul în care orice parte a aplicației dvs. utilizează protocolul HTTP, un cookie pentru conectare va fi omisă aici, și, prin urmare, nu va avea acces la informațiile privind identitatea utilizatorului. Se pare că utilizatorul este anonim. Mi-ar recomanda pentru a efectua întreaga aplicație utilizând SSL, pentru a le face viața mai ușoară și pentru a reduce șansa de a obține date sensibile la atacator.
Erori asociate cu scriptingul între site-uri (XSS) pot avea consecințe grave pentru o aplicație web bazată pe ADFS, ca în orice sistem care utilizează module cookie pentru a reprezenta sesiunile de conectare. Cookie-ul este ușor de furat de la o aplicație cu o astfel de vulnerabilitate și dacă reușiți să obțineți un cookie, veți putea să vă conectați. Ca măsură de protecție cu straturi, data de expirare a modulului cookie ADFS expiră la sfârșitul zilei de lucru, iar acest interval poate fi configurat în politica de încredere ADFS. Dacă sunteți nou în XSS și cum să le evitați, petreceți o jumătate de oră pe lucrarea de laborator interactivă pe XSS, scrisă de mine.
De unde vă aflați, utilizator?
Unul dintre scopurile creării unei aplicații ADFS nu este acela de a ciocni capul utilizatorului cu astfel de detalii. Magazin Northwind, vinde biciclete poate sări peste acest pas, oferind accesul utilizatorilor la site-ul Web Fabrikam printr-o legătură cu parametrul de magie în șirul de interogare - WHR. Agentul web caută acest parametru în șirul de interogare și, dacă este găsit, îl încarcă din șirul de interogare în timpul procesării prealabile. Valoarea acestui parametru este URI-ul Federației Partner (fiecare serviciu de federație are propriul URI). Prin urmare, angajații din magazinul Northwind pot obține ceva de genul:
Aceasta va oferi ADFS suficiente informații pentru a nu afișa utilizatorului o pagină interactivă cu o listă de dealeri, în care ar trebui să indice organizația sa.
Declarații și transformare
Am vorbit deja mult despre pretențiile din acest articol. Reprezentând un nou și tot mai important concept legat de conceptul de protecție pe platforma Windows, aplicațiile reprezintă un mod universal de a genera afirmații despre o entitate cum ar fi un utilizator. Luați în considerare un bilet Kerberos care conține ID-urile de utilizator și de domeniu pentru utilizatorul conectat. De fapt, este doar un set de aplicații semnate de un controlor de domeniu care a generat un bilet. ID-ul de utilizator este o cerere de identificare. Deși o astfel de declarație poate fi utilizată pentru audit sau personalizare, aceasta nu este de obicei aplicată pentru controlul accesului. Este mai probabil ca grupurile specificate în bilet să fie folosite pentru a verifica drepturile de acces. De exemplu, dacă sunteți membru al grupului de administratori, vi se poate permite să aprobați achiziții scumpe.
Fiecare companie definește un set de aplicații pentru organizarea sa; este ca și cum ai crea un dicționar care să fie ușor de înțeles de ea. Astfel, Fabrikam poate defini declarația unui grup numit "Proprietar", care reprezintă proprietarul unui magazin de comercianți, care vinde biciclete. Dar magazinul Northwind poate prezenta același rol în declarația "Manager". Acest lucru este normal dacă aceste declarații au aceeași valoare, deoarece proprietarul Northwind poate folosi politica de încredere federală a resurselor sale pentru a compara declarația sa "Manager" cu declarația "Proprietar" pe care Fabrikam o înțelege. Administratorii pot configura astfel de mapări pe ambele părți ale relațiilor federalizate. În Fig. 3 oferă un exemplu de potrivire a cererilor în politica de încredere a resurselor partenerului.
Fig. 3. Compararea declarațiilor
Unele comparații sunt prea volatile pentru a fi reprezentate ca o comparație statică într-o politică de încredere. Să presupunem că partenerul de resurse are nevoie de o declarație numită "IsOfLegalVotingAge" pentru a vă asigura că cineva are deja 18 ani, dar cunoașteți doar data de naștere a utilizatorului ca o aplicație non-standard din Active Directory. Deci, aveți nevoie de modulul de transformare a aplicațiilor, care este ansamblul unde este implementată clasa gestionată IClaimTransform. Puteți să o legați de politica de încredere în fereastra de proprietăți a politicii de încredere (Figura 4). Acest modul este sunat de două ori: o dată înainte de apariția hărții politicii de încredere obișnuite și o dată după aceea, ceea ce permite o prelucrare pre- sau postprocesare. Fiecare politică de încredere a ADFS face posibilă instalarea unui astfel de modul, ceea ce înseamnă că puteți efectua conversia dinamică a aplicațiilor atât pe partea partenerului de cont, cât și pe partea partenerului de resurse.
Fig. 4. Modulul de conversie a aplicațiilor
De unde provin cererile?
Dacă nu scrie modulul aplicații de conversie, generând dinamic aplicație, toate aplicațiile vor veni de la magazinele de cont, care poate fi fie Active Directory, sau ADAM (Active Directory Application Mode) - Server director „light“, pe baza codului de bază activă Director. Lucrul cu contul de stocare Active Directory, puteți afișa grupurile de aplicații de pe una sau mai multe grupuri în Active Directory; ADAM seif, trebuie să furnizați numele atribut al obiectului utilizator și valoarea la care va fi posibil să se determine dacă să trimită grupul de cerere este necesară pentru utilizator. Fiecare declarație non-standard sau o declarație de identificare este afișat direct pe un atribut al obiectului utilizator în directorul.
Frumusețea unei astfel de scheme este aceea că pentru integrarea cu partenerii, administratorul poate folosi datele de identificare deja disponibile în directorul companiei și în multe cazuri nu este necesar să scrieți codul.
anonimat
În sistemele bazate pe aplicații, există un lucru foarte interesant - adesea nu este nevoie să trimiteți un nume de utilizator. Poate că singurul lucru care interesează un partener este dacă utilizatorul este într-adevăr autorizat la această cerere. Dar pentru un partener este adesea foarte convenabil să existe cel puțin un anumit descriptor de identificare din care să poată primi date de personalizare sau alt statut pentru utilizator.
Pentru a susține acest mod de operare anonim, există o conversie specială încorporată pentru aplicațiile de identitate - confidențialitate îmbunătățită a identității. Dacă sunteți partenerul de cont și doriți ca utilizatorii să fie anonime atunci când se ocupă cu un anumit partener de resurse, trebuie doar să activați această caracteristică pentru partenerul de încredere în politica, și, în locul numelui de utilizator văd:
Pentru a genera acest descriptor (mâner), Federația Serviciul creează o valoare hash a aplicării efective de identificare, URI-ul partenerului de resurse și o anumită valoare, cunoscută numai la serviciul Federației (ADFS terminologie se numește „cheia de confidențialitate“). Prin incorporarea partener descriptori URI sunt diferite pentru fiecare partener de resurse, care împiedică posibilitatea unui dosar privind un anumit utilizator. Se adaugă cheia de confidențialitate pentru a face dificilă atacarea dicționarului.
În ciuda protecției identificării de la un partener de resurse, acesta poate fi urmărit. Dacă aveți nevoie pentru a determina identitatea cuiva, acesta poate fi găsit în fișierul jurnal de utilizare a resurselor și de a da administratorului partenerului de cont, care pot folosi conturile jurnalele de evenimente pentru a determina care utilizator are această identificare.
Proxy Federației
Motivul pentru această separare este că interfața client (intrare de serviciu) poate fi plasat pe perimetrul rețelei (adesea menționată ca DMZ, zona demilitarizată) și vzaimodeystovat cu serverul printr-o federație de servicii web un serviciu ASMX, care rulează pe rețeaua internă. În această configurație, interfața client este denumită Proxy Federației.
Dacă administratorul dvs. va împărți serviciul de federație utilizând un proxy pe o mașină separată, nu contează prea mult, dar în orice caz este util să știți că ADFS este capabil să lucreze în DMZ.
Activarea suportului ADFS în aplicațiile Web
Dacă vă confruntați cu sarcina de a crea o aplicație web care acceptă autentificarea prin ADFS, trebuie să faceți câteva lucruri. Va trebui să configurați fișierul web.config pentru a încărca și a configura agentul Web ADFS. Lista 1 arată fișierul web.config pe care l-am folosit pentru a pregăti aplicația de probă pentru acest articol.
Listing 1. Exemplu de web.config
După configurarea fișierului web.config, veți putea primi date de conectare de la partenerii contului dvs. ADFS. Următorul pas este de a lua decizii de securitate pe baza declarațiilor.
Dacă doriți să lucreze la schema de federație, trebuie să creați o aplicație care înțelege cererea, și în același timp, nu se poate baza pe mecanismul de uzurpare a identității (personificare), din moment ce nu va avea un cont de domeniu Windows, care reprezintă utilizatorii partenerilor din cont. Vei face cu agentul web care nu face comparații cu conturi Windows și vă trimite o declarație primită de proprietate HttpContext.User. Am aplicat această abordare în exemplul meu.
Scrierea unui cod pentru a verifica aplicațiile nu este dificilă. De fapt, dacă vă bazați foarte mult pe declarațiile de grup, nu trebuie să vă gândiți deloc la declarații. Continuați să utilizați HttpContext.User.IsInRole pentru a verifica prezența sau absența unor astfel de instrucțiuni, tratați-le ca roluri pentru aplicații. Asta este, puteți utiliza controalele ASP.NET, cum ar fi LoginView, care funcționează pe baza rolurilor obținute prin proprietatea HttpContext.User.
Dacă doriți să primiți valori pentru aplicații non-standard, veți avea nevoie de un cod. Acest fragment de cod caută titlul:
O altă proprietate interesantă este AuthenticatingAuthority, URI-ul partenerului de cont care a autentificat acest client. Este întotdeauna util să aveți un buton Deconectare, iar aici este utilă proprietatea SignOutUrl.
Aplicația de probă pentru acest articol formează un tabel bazat pe valorile tuturor proprietăților deschise ale SingleSignOnIdentity, așa cum se arată în Fig. 5. De asemenea, primește un set de proprietăți referitoare la protecția care arată toate declarațiile trimise în forma lor originală. Dar, înainte de a rula această aplicație, trebuie să instalați ADFS.
Lucrează cu ADFS
Există, de asemenea, o aplicație de exemplu, care include un fișier de configurare care poate fi folosit pentru testare. Copiați doar fișierele default.aspx și web.config în directorul virtual din imaginea partenerului de resurse; apoi puteți să vă conectați de la computerul client și să specificați în browser-ul dvs. aplicația web a partenerului de resurse pe care doriți să vă conectați.
Afișare: Mijlocit protejat
Articole similare
Trimiteți-le prietenilor: