TITLU: ______ DRUMUL CATRE CLOUD _______________________________________ [625249]

UNIVERSITATEA “TITU MAIORESCU” DIN BUCUREȘTI
FACULTATEA DE INFORMATICĂ

LUCRARE DE LICENȚĂ/DISERTAȚIE

COORDONATOR ȘTIINȚIFIC:
Conf.univ.dr.ing. I USTIN PRIESCU

ABSOLVENT: [anonimizat] /IULIE
2018
UNIVERSITATEA “TITU MAIORESCU” DIN BUCUREȘTI

FACULTATEA DE INFORMATICĂ

LUCRARE DE LICENȚĂ/DISERTAȚIE
Drumul către Cloud

COORDONATOR ȘTIINȚIFIC:
Conf.univ.dr.ing. I USTIN PRIESCU

ABSOLVENT: [anonimizat] /IULIE
2018

UNIVERSITATEA TITU MAIORESCU
FACULTATEA DE INFORMATICĂ
DEPARTAMENTUL DE INFORMATICĂ

REFERAT
DE APRECIERE A L UCRĂRII DE LICENȚĂ/DISERTAȚIE
TITLU: ______ DRUMUL CATRE CLOUD _______________________________________
___________________________________________________________________________
ABSOLVENT/ MASTERAND: ________ OVIDIU MARIAN BEN ____ _________
PROFESOR COORDONATOR: ___Conf.univ.dr.ing. I USTIN PRIESCU _______

Referitor la conținutul lucrării, fac următoarele aprecieri:
A. Conținutul științific al lucr ării 1 2 3 4 5 6 7 8 9 10
B. Documentarea din literatura de speciali tate 1 2 3 4 5 6 7 8 9 10
C. Contribuția proprie 1 2 3 4 5 6 7 8 9 10
D. Calitatea exprimării scrise și a redactării lucrării 1 2 3 4 5 6 7 8 9 10
E. Conlucrarea cu coordonatorul științific 1 2 3 4 5 6 7 8 9 10
F. Realizarea aplicației practice 1 2 3 4 5 6 7 8 9 10
Punctaj total = (A+B+C+D+E+2F)/7

În concluzie, consider că lucrarea de licență/disertație întrunește/ nu întrunește condițiile pentru a
fi susținută în fața comisiei pentru examenul de licență/disertație din sesiunea
__________________________ și o apreciez cu nota___________________.
CONDUCĂTOR ȘTIINȚIFIC,
______________________________

UNIVERSITATEA TITU MAIORESCU
FACULTATEA DE INFORMATICĂ
DEPARTAMENTUL DE INFORMATI CĂ

FIȘĂ DE EVIDENȚĂ A LUCRĂRII DE LICENȚĂ /DISERTAȚIE

TITLU: DRUMUL CATRE CLOUD
ABSOLVENT/ MASTERAND: [anonimizat]: Conf.univ.dr.ing. I USTIN PRIESCU

CALENDARUL ELABORĂRII LUCRĂRII DE LICENȚĂ/DISERTAȚIE
ACTIVITATE TERMEN DE
FINALIZARE DATA
FINALIZĂRII SEMNATURĂ PROFESOR
Schematizare 02.04.2018 02.04.2018
Pregătire teorie AD
Connect 29.04.2018 29.04.2018
Pregătire teorie
protocoal e 15.05.2018 15.05.2018
Creare laborator 01.06.2018 01.06.2018
Documentarea
parții practice 19.06.2018 19.06.2018

Se va completa de către student/masterand: [anonimizat]/absolvent: [anonimizat], respectiv masterand: [anonimizat], va trebui să aibă cel puțin trei întâlniri cu profesorul
coordonator în vederea finalizării lucrării.
Studenții/absolven ții, respectiv masteranzii, care nu vor avea completată această fișă nu se vor
putea înscrie la examenul de licență, respectiv disertație.

1

Drumul către Cloud

Cuprins
1. AR TREBUI SA MIGREZ CĂTRE CLOUD? ………………………….. ………………………….. ………………………. 2
2. AZURE AD CONNECT SAU POARTA CĂTRE CLOUD ………………………….. ………………………….. ……….. 3
2.1 DEFIN IRE ………………………….. ………………………….. ………………………….. ………………………….. ……………………. 3
2.2 ARHITECTURA ………………………….. ………………………….. ………………………….. ………………………….. ………….. 4
3. VARIANTE DE SECURITA TE IN INFRASTRUCTURI HIBRIDE ………………………….. ………………….. 20
3.1 ADFS ………………………….. ………………………….. ………………………….. ………………………….. ………………………. 20
3.2 OpenID ………………………….. ………………………….. ………………………….. ………………………….. ……………………. 23
3.3 OAuth 2 ………………………….. ………………………….. ………………………….. ………………………….. …………………….. 32
4. LABORATOR HYBRID (IN TEGRARE ORI CAREI APLICATII CU AUTENTIFICARE
PRIN AZURE FOLOSIND UTILIZATORI SINCRO NIZAȚI DIN ON -PREM) ………………………….. 51
4.1 PREGĂTIREA INFRASTRUC TUR II AZURE ………………………….. ………………………….. ………………………….. ………… 57
4.2 INSTALARE AZURE AD CONNECT ȘI CONFIGURAR E AD FS ȘI WEB APPLICATION PROXY ………………………….. …. 63
4.3 CONFIGUARE A SI TESTARE AUTENTIFICARII IN APLICATII ………………………….. …………………………. 64

2

1. Ar trebui sa migrez către cloud?

De ce să treci către Cloud ? Probabil pentru a beneficia de o mai mar e versatilitate în infrastructura
existent. In momentul în care utilizator ii tăi vor fi sincronizați în Cloud aceștia vor putea să
acceseze una din sutele de mii de aplicații existente în momentul de față . Cu toate acestea în multe
din companii de mari dimensiunii, sunt temătoare în fața schimbării . Marea t emere constă în
conceptul de securitate . Multe companii își doresc să controleze în continuare utilizator i si parolele
din o n-prem cu toate acestea a să fie sincronizați în Cloud și să beneficieze de at uurile pe care
acest lucru le poate aduce licențiere , aplicații etc . Tocmai din acest motiv exista în momentul de
față soluții hibride de trecere treptată a securității către Cloud.
Una din cele mai des întâlnite infrastructuri hibrid despre care vom discu ta și în această lucrare
este cea care implică securizarea prin federalizare . Federalizarea se face prin conectarea unui
domeniu on -prem folosind un IDP provider cu o soluție de cloud. In exemplu de fata vom folosi
soluția Microsoft: server de ADFS ca IDP si Microsoft Azure ca platforma cloud.
Platforma Microsoft Azure reprezintă unul dintre cele mai importante elemente din viziunea
Microsoft Cloud OS, element ce are ca scop înlocuirea mediului tradițional de datacenter. Astfel
permite organizațiilor busine ss sa stocheze datele oriunde pe glob, permite dezvoltarea unei game
largi de aplicații modern pe care utilizatorii sa lucreze de pe orice dispozitiv de oriunde, platforma
fiind capabila sa gestioneze într-un mod sigur si coerent toate dispozitivele.
Pentru a discuta despre soluția de Cloud oferită de Microsoft Trebuie mai întâi de toate să
discutăm despre A zure AD Connect principalul utilitar care va sincroniza toate regulile ,
utilizatorii , parolele și alte tipuri de obiecte din o n-prem către Cloud .

3

2. Azure AD Connect sau poarta către cloud
2.1. Definire
Azure AD Connect va integra directoarele dvs. locale cu Azure Active Directory. Aceasta vă
permite să furnizați o identitate comună utilizatorilor dvs. pentru aplicațiile Office 365, Azure și
SaaS integrate cu Azure AD. Acest subiect vă va ghida prin etapele de planificare, implementare
și operare. Este o colecție de linkuri către subiectele legate de acest domeniu.
Azure AD Connect este cea mai bună modalitate de a vă conecta directorul local cu Azure AD și
Office 365. Este un moment excelent să faceți upgrade la Azure AD Connect din Windows Azure
Active Directory Sync (DirSync) sau Azure AD Sync, deoarece aceste instrumente sunt acum
respinși nu mai sunt susținute la data de 13 aprilie 2017. De asemenea:
Sincronizarea utilizatorilor cu Azure AD este o caracteristică gratuită și nu necesită ca clienții să
aibă abonament plătit.
Utilizatorii sincronizați nu primesc automat nicio licență. Administratorii au încă un control total
asupra alocării licenței.
Recoma ndarea Microsoft este ca administratorii IT să sincronizeze toți utilizatorii lor. Acest lucru
nu numai că deblochează utilizatorii pentru a accesa orice resursă integrată Azure AD, dar oferă,
de asemenea, o vedere mult mai largă pentru administratorii IT pentru a vedea ce aplicații sunt
accesate de utilizatorii lor.
Azure Active Directory Connect este alcătuită din trei componente principale: serviciile de
sincronizare, componenta opțională Active Directory Federation Services și componenta de
monitorizare denumită Azure AD Connect Health.
Sincronizare – această componentă este responsabilă pentru crearea de utilizatori, grupuri și alte
obiecte. Este, de asemenea, responsabil pentru a vă asigura că informațiile de identitate pentru
utilizatorii și grupurile dvs. locale se potrivesc cu nor.
AD FS – Federația este o parte opțională a Azure AD Connect și poate fi utilizată pentru a configura
un mediu hibrid folosind o infrastructură AD FS locală. Acest lucru poate fi folosit de organizații

4
pentru a aborda imple mentări complexe, cum ar fi conectarea la domenii a SSO, aplicarea politicii
de conectare la AD, a cartelei inteligente sau a MAE terțe părți.
Monitorizarea sănătății – Azure AD Connect Health poate oferi o monitorizare robustă și oferă o
locație centrală în portalul Azure pentru a vedea această activitate. Pentru informații suplimentare,
consultați Azure Active Directory Connect Health.

2.2. Arhitectură
Motorul de sincronizare creează o vizualizare integrată a obiectelor stocate în mai multe surse de
date con ectate și gestionează informațiile de identitate din acele surse de date. Această vizualizare
integrată este determinată de informațiile de identitate preluate din sursele de date conectate și de
un set de reguli care determină modul de procesare a acestor informații.
Surse de date conectate și conectori
Motorul de sincronizare procesează informații de identitate din diferite depozite de date, cum ar fi
Active Directory sau o bază de date SQL Server. Fiecare depozit de date care își organizează datele
într-un format asemănător bazei de date și care oferă metode standard de acces la date este un
potențial candidat pentru sursa de date pentru motorul de sincronizare. Depozitele de date care
sunt sincronizate prin motorul de sincronizare se numesc surse de date conectate sau directoare
conectate (CD).
Motorul de sincronizare încorporează interacțiunea cu o sursă de date conectată într -un modul
numit Conector. Fiecare tip de sursă de date conectată are un conector specific. Conectorul traduce
o operație necesară în formatul pe care îl înțelege sursa de date conectată.
Conectorii fac apeluri API pentru a schimba informații de identitate (citite și scrise) cu o sursă de
date conectată. Este, de asemenea, posibil să adăugați un conector personalizat utilizând cadrul
extensibil de conectivitate. Următoarea ilustrație arată modul în care un conector conectează o
sursă de date conectată la motorul de sincronizare.

5

Datele pot curge în ambele direcții, dar nu pot circula simultan în ambele direcții. Cu alte cuvinte,
un conector poate fi configurat pentru a permite ca datele să circule de la sursa de date conectată
pentru sincronizarea motorului sau de la sincronizarea motorului cu sursa de date conectată, dar
numai una dintre acele operații poate apărea la un moment dat pentru un obiect și un atribut.
Direcția poate fi diferită pentru diferite obiecte și pentru diferite atribute.
Pentru a configura un conector, specificați tipurile de obiecte pe care doriți să le sincronizați.
Specificarea tipurilor de obiecte definește d omeniul obiectelor care sunt incluse în procesul de
sincronizare. Următorul pas este selectarea atributelor de sincronizare, care este cunoscută ca o
listă de includere a atributelor. Aceste setări pot fi modificate în orice moment ca răspuns la
modificări le aduse regulilor dvs. de afaceri. Când utilizați expertul de instalare Azure AD Connect,
aceste setări sunt configurate pentru dvs.
Pentru a exporta obiecte la o sursă de date conectată, lista de includere a atributelor trebuie să
includă cel puțin atrib utele minime necesare pentru a crea un anumit tip de obiect într -o sursă de
date conectată. De exemplu, atributul sAMAccountName trebuie inclus în lista de includere a
atributelor pentru a exporta un obiect utilizator în Active Directory, deoarece toate ob iectele
utilizator din Active Directory trebuie să aibă un atribut sAMAccountName definit. Din nou,
expertul de instalare face această configurație pentru dvs.
Dacă sursa de date conectată utilizează componente structurale, cum ar fi partițiile sau contain erele
pentru a organiza obiecte, puteți să limitați zonele din sursa de date conectate care sunt utilizate
pentru o anumită soluție.
Structura internă a spațiului de nume al motorului de sincronizare
Întregul spațiu de nume al motorului de sincronizare con stă din două spații de nume care stochează
informațiile de identitate. Cele două spații de nume sunt:

6
Spațiul conector (CS)
Metaversa (MV)
Spațiul conectorului este o zonă de așteptare care conține reprezentări ale obiectelor desemnate
dintr -o sursă de da te conectată și atributele specificate în lista de includere a atributelor. Motorul
de sincronizare utilizează spațiul conector pentru a determina ce s -a schimbat în sursa de date
conectată și pentru a modifica modificările primite. Motorul de sincronizare utilizează, de
asemenea, spațiul pentru conectori pentru a modifica modificările efectuate pentru a fi exportat la
sursa de date conectată. Motorul de sincronizare menține un spațiu distinct al conectorilor ca zonă
de așteptare pentru fiecare conector.
Utilizând o zonă de așteptare, motorul de sincronizare rămâne independent de sursele de date
conectate și nu este afectat de disponibilitatea și accesibilitatea acestora. Prin urmare, puteți
procesa informațiile de identitate în orice moment utilizând datele din zona de așteptare. Motorul
de sincronizare poate solicita numai modificările efectuate în interiorul sursei de date conectate de
la încheierea ultimei sesiuni de comunicare sau împingerea numai a modificărilor aduse
informațiilor de identitate pe care sursa de date conectate nu le -a primit încă, ceea ce reduce traficul
de rețea între motorul de sincronizare și sursă de date conectată.
În plus, motorul de sincronizare stochează informații despre starea tuturor obiectelor care se află
în spațiul conector ului. Atunci când se primesc date noi, motorul de sincronizare întotdeauna
evaluează dacă datele au fost deja sincronizate.
Metaversa este o zonă de stocare care conține informațiile de identitate agregate din mai multe
surse de date conectate, oferind o v izualizare globală și integrată a tuturor obiectelor combinate.
Obiectele Metaverse sunt create pe baza informațiilor de identitate care sunt preluate din sursele
de date conectate și a unui set de reguli care vă permit să personalizați procesul de sincron izare.
Următoarea ilustrație prezintă spațiul de nume al spațiului conectorilor și spațiul de nume
metaverse din cadrul motorului de sincronizare.

7

Sincronizați obiectele de identitate ale motorului
Obiectele din motorul de sincronizare sunt reprezentăr i ale fiecărui obiect din sursa de date
conectată sau din vizualizarea integrată pe care o are sincronizarea motorului cu acele
obiecte. Fiecare obiect de motor de sincronizare trebuie să aibă un identificator unic global
(GUID). GUID -urile furnizează inte gritatea datelor și exprimă relațiile dintre obiecte.
Conector obiecte spațiu
Când motorul de sincronizare comunică cu o sursă de date conectată, citește informațiile de
identitate din sursa de date conectată și utilizează aceste informații pentru a crea o reprezentare a
obiectului de identitate în spațiul conectorului. Nu puteți crea sau șterge aceste obiecte în mod
individual. Cu toate acestea, puteți șterge manual toate obiectele dintr -un spațiu de conectare.
Toate obiectele din spațiul conectorului au două atribute:
Un identificator unic global (GUID)
Un nume distins (cunoscut și ca DN)
Dacă sursa de date conectată atribuie un atribut unic obiectului, atunci obiectele din spațiul
conectorului pot avea și un atribut de ancorare. Atributul de ancorare ide ntifică în mod unic un
obiect din sursa de date conectată. Motorul de sincronizare utilizează ancora pentru a localiza
reprezentarea corespunzătoare a acestui obiect în sursa de date conectată. Motorul de sincronizare
presupune că ancora unui obiect nu se schimbă niciodată pe întreaga durată de viață a obiectului.
Multe dintre conectori utilizează un identificator unic cunoscut pentru a genera automat o ancorare
pentru fiecare obiect atunci când este importat. De exemplu, conectorul Active Directory utilize ază

8
atributul objectGUID pentru o ancoră. Pentru sursele de date conectate care nu oferă un
identificator unic clar definit, puteți specifica generarea ancorării ca parte a configurației
conectorului.
În acest caz, ancora este construită din unul sau mai m ulte atribute unice ale unui tip de obiect, nici
una dintre ele nu se modifică și identifică în mod unic obiectul în spațiul conector (de exemplu, un
număr de angajat sau un ID de utilizator).
Un obiect spațiu conector poate fi unul dintre următoarele:
Un obiect de staționare
Un substituent
Obiectele de staționare
Un obiect de staționare reprezintă o instanță a tipurilor de obiecte desemnate din sursa de date
conectată. Pe lângă GUID și numele distins, un obiect de staționare are întotdeauna o valoare care
indică tipul de obiect.
Stabilirea obiectelor importate are întotdeauna o valoare pentru atributul de ancorare. Punerea în
scenă a obiectelor care au fost recent furnizate de motorul de sincronizare și care sunt în curs de
creare în sursa de date conectat ă nu au o valoare pentru atributul de ancorare.
Obiectele de staționare au, de asemenea, valori actuale ale atributelor de afaceri și informațiile
operaționale necesare pentru sincronizarea motorului pentru a efectua procesul de
sincronizare. Informațiile operaționale includ steaguri care indică tipul de actualizări care sunt
introduse pe obiectul de staționare. Dacă un obiect de staționare a primit informații noi de
identitate din sursa de date conectată care nu a fost încă procesată, obiectul este marcat ca import
în așteptare . Dacă un obiect de așteptare are noi informații de identitate care nu au fost încă
exportate către sursa de date conectată, este marcată ca export în așteptare .
Un obiect de staționare poate fi un obiect de import sau un obiect de export. Motorul de
sincronizare creează un obiect de import utilizând informațiile obiect primite de la sursa de date
conectată. Când motorul de sincronizare primește informații despre existența unui obiect nou care
se potrivește cu unul dintre tipurile de obiecte selectate în conector, acesta creează un obiect de
import în spațiul conector ca reprezentare a obiectului din sursa de date conectată.

9
Următoarea imagine prezintă un obiect de import care reprezintă un obiect din sursa de date
conectată.

Motoru l de sincronizare creează un obiect de export utilizând informații de obiect în
metaverse. Elementele de export sunt exportate la sursa de date conectată în timpul următoarei
sesiuni de comunicare. Din perspectiva motorului de sincronizare, obiectele de ex port nu există
încă în sursa de date conectată. Prin urmare, atributul atribut pentru un obiect de export nu este
disponibil. După ce primește obiectul din motorul de sincronizare, sursa de date conectată creează
o valoare unică pentru atributul de ancorar e a obiectului.
Următoarea ilustrație arată modul în care este creat un obiect de export utilizând informațiile de
identitate din metaverse.

10
Motorul de sincronizare confirmă exportul obiectului prin reimportarea obiectului din sursa de
date conectată. Elementele de export devin obiecte de import când sincronizarea motorului le
primește în timpul următoarei import ării din sursa de date conectată.
substituenților
Motorul de sincronizare utilizează un spațiu de nume plat pentru a stoca obiecte. Cu toate ac estea,
unele surse de date conectate, cum ar fi Active Directory, utilizează un spațiu de nume
ierarhic. Pentru a transforma informațiile dintr -un spațiu de nume ierarhic într -un spațiu de nume
plat, motorul de sincronizare folosește locașuri pentru păstra rea ierarhiei.
Fiecare substituent reprezintă o componentă (de exemplu, o unitate organizațională) a unui nume
ierarhic al unui obiect care nu a fost importat în motorul de sincronizare, dar este necesar să se
construiască numele ierarhic. Acestea umple go lurile create de referințe în sursa de date conectată
la obiecte care nu staționează obiecte în spațiul conector.
Motorul de sincronizare utilizează, de asemenea, substituenți pentru a stoca obiecte de referință
care nu au fost încă importate. De exemplu, dacă sincronizarea este configurată să includă atributul
manager pentru obiectul Abbie Spencer și valoarea primită este un obiect care nu a fost încă
importat, cum ar fi CN = Lee Sperry, CN = Utilizatori, DC = fabrikam, DC = com , informațiile
despre manag er sunt stocate ca locașuri în spațiul conectorului. Dacă obiectul managerului este
importat mai târziu, obiectul substituentului este suprascris de obiectul de staționare care reprezintă
managerul.
Obiecte metaverse
Un obiect metaverse conține viziunea a gregată pe care motorul de sincronizare o are asupra
obiectelor de staționare din spațiul conectorilor. Motorul de sincronizare creează obiecte
metaverse utilizând informațiile din obiectele de import. Mai multe obiecte de spațiu de conectare
pot fi conect ate la un singur obiect metaverse, dar un obiect spațiu conector nu poate fi legat la
mai mult de un obiect metaverse.
Obiectele Metaverse nu pot fi create sau șterse manual. Motorul de sincronizare șterge automat
obiectele metaverse care nu au o legătură cu niciun obiect spațiu conector în spațiul conectorului.

11
Pentru a cartografia obiecte dintr -o sursă de date conectată la un tip de obiect corespunzător în
metaverse, motorul de sincronizare oferă o schemă extensibilă cu un set predefinit de tipuri de
obiecte și atribute asociate. Puteți crea noi tipuri de obiecte și atribute pentru obiectele
metaverse. Atributele pot fi unice sau multival oare, iar tipurile de atribute pot fi șiruri de caractere,
referințe, numere și valori booleene.
Relațiile dintre obiect ele staționare și obiectele metaverse
În spațiul de nume al motorului de sincronizare, fluxul de date este activat de relația de legătură
dintre obiectele de staționare și obiectele metaverse. Un obiect de staționare care este legat de un
obiect metaverse se numește obiect în comun (sau obiect conector ). Un obiect de staționare care
nu este conectat la un obiect metaverse se numește obiect separat (sau obiect
deconectat ). Termenii alăturați și separați sunt preferați să nu confunde cu conectorii responsa bili
pentru importul și exportul de date dintr -un director conectat.
Placeholderii nu sunt niciodată conectați la un obiect metaverse
Un obiect alăturat cuprinde un obiect de staționare și relația sa legată cu un obiect metaverse
unic. Obiectele asociate s unt utilizate pentru a sincroniza valorile atributelor dintre un obiect
spațial al unui conector și un obiect metaverse.
Atunci când un obiect de stadiu devine obiect în timpul sincronizării, atributele pot circula între
obiectul de stadializare și obiectu l metaverse. Fluxul atributului este bidirecțional și este configurat
prin utilizarea regulilor de atribut de import și a regulilor de atribut de export.
Un singur obiect spațial al conectorului poate fi asociat unui singur obiect metaverse. Cu toate
acest ea, fiecare obiect metaverse poate fi conectat la mai multe obiecte spațiu conector în același
spațiu sau în diferite conectori, după cum se arată în ilustrația următoare.

12

Relația legată dintre obiectul de staționare și un obiect metaverse este persiste ntă și poate fi
eliminată numai de regulile pe care le specificați.
Un obiect separat este un obiect de staționare care nu este legat de niciun obiect
metaverse. Valorile atributelor unui obiect separat nu sunt prelucrate în metaverse. Valorile
atributelor obiectului corespunzător din sursa de date conectată nu sunt actualizate de motorul de
sincronizare.
Prin utilizarea obiectelor separate, puteți stoca informațiile de identitate în motorul de sincronizare
și puteți procesa mai târziu. Păstrarea unui obiec t de staționare ca obiect separat în spațiul
conectorului are multe avantaje. Deoarece sistemul a introdus deja informațiile necesare despre
acest obiect, nu este necesar să se creeze din nou o reprezentare a acestui obiect în timpul
următorului import din sursa de date conectată. În acest fel, motorul de sincronizare are
întotdeauna un instantaneu complet al sursei de date conectate, chiar dacă nu există nicio
conexiune curentă cu sursa de date conectată. Obiectele detașate pot fi convertite în obiecte
înrudite și invers, în funcție de regulile pe care le specificați.
Un obiect de import este creat ca un obiect separat. Un obiect de export trebuie să fie un obiect în
comun. Logica sistemului impune această regulă și șterge fiecare obiect de export care nu e ste un
obiect în comun.
Sincronizați procesul de gestionare a identității motorului
Procesul de gestionare a identității controlează modul în care informațiile de identitate sunt
actualizate între diferitele surse de date conectate. Gestionarea identități i are loc în trei procese:

13
Import
Sincronizare
Export
În timpul procesului de import, motorul de sincronizare evaluează informațiile de identitate primite
de la o sursă de date conectată. Când se detectează modificări, fie creează noi obiecte de staționare ,
fie actualizează obiecte de stadializare existente în spațiul conector pentru sincronizare.
În timpul procesului de sincronizare, motorul de sincronizare actualizează metaversa pentru a
reflecta modificările care au avut loc în spațiul conectorilor și ac tualizează spațiul conectorului
pentru a reflecta schimbările care au avut loc în metaverse.
În timpul procesului de export, motorul de sincronizare împinge modificările care sunt organizate
pe obiectele de așteptare și care sunt marcate ca export în aștep tare.
Următoarea ilustrație arată locul în care fiecare dintre procese apare ca flux de informații de
identitate de la o sursă de date conectată la alta.

Procesul de import
În timpul procesului de import, motorul de sincronizare evaluează actualizările informațiilor de
identitate. Motorul de sincronizare compară informațiile de identitate primite de la sursa de date
conectată cu informațiile de identitate despre un obiect de stadializare și determină dacă obiectul
de stadiu necesită actualizări. Dacă est e necesar să actualizați obiectul de staționare cu date noi,
obiectul de așteptare este marcat ca import în așteptare.
Prin stadializarea obiectelor în spațiul conectorului înainte de sincronizare, motorul de sincronizare
poate procesa numai informațiile d e identitate care s -au schimbat. Acest proces oferă următoarele
beneficii:
Sincronizare eficientă . Cantitatea de date procesate în timpul sincronizării este minimizată.

14
Resincronizare eficientă . Puteți schimba modul în care motorul de sincronizare proces ează
informațiile de identitate fără a reconecta motorul de sincronizare la sursa de date.
Oportunitate de previzualiza re a sincronizării . Puteți previzualiza sincronizarea pentru a verifica
dacă ipotezele privind procesul de gestionare a identității sunt corecte.
Pentru fiecare obiect specificat în conector, motorul de sincronizare încearcă mai întâi să găsească
o reprezentare a obiectului în spațiul conector al conectorului. Motorul de sincronizare examinează
toate obiectele de staționare din spațiul con ectorilor și încearcă să găsească un obiect de staționare
corespunzător care are un atribut de ancorare corespunzător. Dacă niciun obiect de staționare
existent nu are un atribut de ancorare corespunzător, motorul de sincronizare încearcă să găsească
un ob iect de staționare corespunzător cu același nume distins.
Când motorul de sincronizare găsește un obiect de staționare care se potrivește cu un nume distinct,
dar nu cu ancora, apare următorul comportament special:
Dacă obiectul aflat în spațiul conectorul ui nu are ancora, atunci motorul de sincronizare elimină
acest obiect din spațiul conectorului și marchează obiectul metaverse la care este conectat,
ca returnând previzionarea la următorul ciclu de sincronizare . Apoi creează noul obiect de import.
Dacă o biectul aflat în spațiul conectorului are o ancora, atunci motorul de sincronizare presupune
că acest obiect a fost fie redenumit, fie șters în directorul conectat. El atribuie un nume temporar,
nou distinct pentru obiectul spațiului de conectare, astfel î ncât să poată staționa obiectul
primit. Obiectul vechi devine apoi tranzitoriu , așteptând ca conectorul să importe redenumirea sau
ștergerea pentru a rezolva situația.
Dacă motorul de sincronizare localizează un obiect de staționare care corespunde cu obi ectul
specificat în Conector, acesta determină ce fel de modificări să se aplice. De exemplu, motorul de
sincronizare poate redenumi sau șterge obiectul din sursa de date conectată sau poate actualiza
doar valorile atributului obiectului.
Punerea în scenă a obiectelor cu date actualizate este marcată ca import în așteptare. Diferite tipuri
de importuri în așteptare sunt disponibile. În funcție de rezultatul procesului de import, un obiect
de staționare din spațiul conectorului are unul dintre următoarele ti puri de import în așteptare:

15
Nici unul . Nu sunt disponibile modificări ale niciunuia dintre atributele obiectului de
staționare. Motorul de sincronizare nu semnalizează acest tip ca import în așteptare.
Adăugați . Obiectul de staționare este un obiect de import nou în spațiul conectorului. Funcția de
sincronizare a motorului semnalează acest tip ca import în așteptare pentru prelucrarea
suplimentară în metaverse.
Actualizați . Motorul de sincronizare găsește un obiect de staționare corespunzător în spațiul
conectorilor și semnalează acest tip ca import în așteptare, astfel încât actualizările atributelor pot
fi procesate în metaverse. Actualizările includ redenumirea obiectelor.
Ștergeți . Motorul de sincronizare găsește un obiect de staționare corespunzăto r în spațiul conector
și semnalează acest tip ca import în așteptare, astfel încât obiectul în comun să poată fi șters.
Ștergeți / Adăugați . Motorul de sincronizare găsește un obiect de staționare corespunzător în
spațiul conectorului, dar tipurile de obi ecte nu se potrivesc. În acest caz, o modificare de ștergere –
adăugare este pusă în scenă. O modificare de ștergere -adăugare indică motorului de sincronizare
faptul că trebuie să apară o resincronizare completă a acestui obiect, deoarece se aplică diferite
seturi de reguli pentru acest obiect atunci când tipul de obiect se modifică.
Setând starea de așteptare la import a unui obiect de staționare, este posibil să se reducă
semnificativ cantitatea de date procesate în timpul sincronizării, deoarece acest lucr u permite
sistemului să proceseze numai acele obiecte care au date actualizate.
Procesul de sincronizare
Sincronizarea constă în două procese conexe:
Sincronizare inbound, atunci când conținutul metaverse este actualizat prin utilizarea datelor din
spațiu l conectorului.
Outbound sincronizare, atunci când conținutul spațiului conectorului este actualizat prin utilizarea
datelor din metaverse.
Prin utilizarea informațiilor staționate în spațiul conectorului, procesul de sincronizare de intrare
creează în met averse vizualizarea integrată a datelor stocate în sursele de date conectate. Fie toate

16
obiectele de staționare, fie cele care au o informație de import în așteptare sunt agregate, în funcție
de modul în care sunt configurate regulile.
Procesul de sincroni zare la ieșire actualizează obiectele de export când se schimbă obiectele
metaverse.
Sincronizarea inbound creează vizualizarea integrată în metaversa a informațiilor de identitate
primite de la sursele de date conectate. Motorul de sincronizare poate proc esa informațiile de
identitate în orice moment utilizând cele mai recente informații de identitate pe care le are de la
sursa de date conectată.
Sincronizare inbound
Sincronizarea inbound include următoarele procese:
Previzionare (numită și Proiecție dacă este important să se facă distincție între acest proces și
previzionarea de sincronizare). Motorul Sync creează un nou obiect metaverse bazat pe un obiect
de staționare și le leagă. Prevederea este o operație la nivel de obiect.
Alătură -te . Motorul Sync l eagă un obiect de staționare la un obiect metaverse existent. O
conexiune este o operație la nivel de obiect.
Importați fluxul atributului . Motorul de sincronizare actualizează valorile atributului, denumite
fluxul atributului, al obiectului în metaverse. Fluxul atributului de import este o operație la nivel
de atribut care necesită o legătură între un obiect de staționare și un obiect metaverse.
Provocarea este singurul proces care creează obiecte în metaverse. Prevederea afectează numai
obiectele de impo rt care sunt obiecte separate. În timpul furnizării, motorul de sincronizare creează
un obiect metaverse care corespunde tipului de obiect al obiectului de import și stabilește o legătură
între cele două obiecte, creând astfel un obiect în comun.
Procesul de conectare stabilește, de asemenea, o legătură între obiectele de import și un obiect
metaverse. Diferența dintre asociere și furnizare este că procesul de conectare necesită ca obiectul
de import să fie legat de un obiect metaverse existent, unde proces ul de furnizare creează un nou
obiect metaverse.

17
Motorul Sync încearcă să se alăture unui obiect de import unui obiect metaverse utilizând criteriile
specificate în configurația Regulilor de sincronizare.
În timpul proceselor de furnizare și de conectare, motorul de sincronizare leagă un obiect separat
într-un obiect metaverse, făcându -le unite. După terminarea acestor operații la nivel de obiect,
motorul de sincronizare poate actualiza valorile atributului obiectului metaverse asociat. Acest
proces se nume ște fluxul atributului de import.
Fluxul atributului de import are loc pe toate obiectele de import care poartă date noi și sunt legate
de un obiect metaverse.
Sincronizare externă
Actualizările de sincronizare de ieșire exportă obiecte atunci când un obie ct metaverse se schimbă,
dar nu este șters. Obiectivul sincronizării de ieșire este de a evalua dacă modificările aduse
obiectelor metaverse necesită actualizarea obiectelor de staționare în spațiile conectorilor. În unele
cazuri, modificările pot necesita actualizarea obiectelor de staționare în toate spațiile
conectorilor. Plasarea obiectelor modificate este marcată ca export în așteptare, făcându -le să
exporte obiecte. Aceste obiecte de export sunt ulterior împinse către sursa de date conectată în
timpul procesului de export.
Sincronizarea la ieșire are trei procese:
-Provizionarea
-Deprevizionarea
-Exportați debitul atributului
Asigurarea și depr ovizionarea sunt atât operații la nivel de obiect. Deprovizionarea depinde de
provizionare, deoarece numai pro vizionarea o poate iniția. Deprovi zionarea este declanșată atunci
când provizionarea elimină legătura dintre un obiect metaverse și un obiect de export.
Asigurarea întotdeauna este declanșată atunci când se aplică modificări obiectelor din
metaverse. Când se fac modificări obiectelor metaverse, motorul de sincronizare poate efectua
oricare dintre următoarele sarcini, ca parte a procesului de furnizare:
Creați obiecte integrate, în care un obiect metaverse este legat de un obiect de export nou creat.

18
Redenum iți un obiect în comun.
Dezasamblați legăturile dintre un obiect metavers e și obiectele de așteptare, creând un obiect
separat.
Dacă provizionarea necesită un motor de sincronizare pentru a crea un nou obiect conector,
obiectul de staționare la care este l egat obiectul metaverse este întotdeauna un obiect de export,
deoarece obiectul nu există încă în sursa de date conectată.
Dacă provizionarea necesită un motor de sincronizare pentru a separa un obiect în comun, creând
un obiect separat, declanșarea este d eclanșată. Procesul de deprovi zionare șterge obiectul.
În timpul deproviz ionar ii, ștergerea unui obiect de export nu șterge fizic obiectul. Obiectul este
marcat ca șters , ceea ce înseamnă că operația de ștergere este pusă pe obiect.
Debitarea atributului de export apare și în timpul procesului de sincronizare la ieșire, similar cu
modul în care fluxul atributului de import are loc în timpul sincronizării inbound. Fluxul atributului
de export apare numai între obiectele metaverse și export care sunt unite.
Procesul de export
În timpul procesului de export, motorul de sincronizare examinează toate obiectele de export care
sunt marcate ca export în așteptare în spațiul conectorilor și apoi trimite actualizări la sursa de date
conectată.
Motorul de sincronizar e poate determina succesul unui export, dar nu poate determina în mod
suficient că procesul de gestionare a identității este complet. Obiectele din sursa de date conectate
pot fi întotdeauna schimbate prin alte procese. Deoarece motorul de sincronizare nu are o
conexiune persistentă la sursa de date conectată, nu este suficient să se facă presupuneri despre
proprietățile unui obiect din sursa de date conectată numai pe baza unei notificări de export de
succes.
De exemplu, un proces din sursa de date conecta tă ar putea schimba atributele obiectului înapoi la
valorile lor originale (adică sursa de date conectată ar putea suprascrie valorile imediat după
expulzarea datelor de către motorul de sincronizare și aplicată cu succes în sursa de date conectată).

19
Motor ul de sincronizare stochează informații de import și de export despre fiecare obiect de
staționare. Dacă valorile atributelor specificate în lista de includere a atributelor s -au modificat de
la ultima exportare, stocarea stării de import și export permite motorului de sincronizare să
reacționeze în mod corespunzător. Motorul de sincronizare utilizează procesul de import pentru a
confirma valorile atributelor care au fost exportate la sursa de date conectată. O comparație între
informațiile importate și cel e exportate, după cum se arată în următoarea ilustrație, permite
motorului de sincronizare să determine dacă exportul a avut succes sau dacă trebuie repetat.

De exemplu, dacă exportul de sincronizare a motorului atribut C, care are o valoare de 5, la o s ursă
de date conectată, stochează C = 5 în memoria sa de stare de export. Fiecare export suplimentar pe
acest obiect are drept rezultat o încercare de a exporta C = 5 la sursa de date conectată din nou,
deoarece motorul de sincronizare presupune că această valoare nu a fost aplicată persistent
obiectului (adică dacă nu a fost importată recent o valoare diferită de la conexiunea sursă de
date). Memoria de export este șters când C = 5 este primit în timpul unei operații de import pe
obiect.
3. Variante de securi tate in infrastructuri Hibride (ADFS, Token -uri, Protocoale de
autentificare)
3.1.ADFS

20
Identificarea corectă a obiectivelor de implementare a serviciilor Active Directory Federation (AD
FS) este esențială pentru succesul proiectului AD FS. Prioritizați și, eve ntual, combinați
obiectivele dvs. de implementare, astfel încât să puteți proiecta și implementa AD FS folosind o
abordare iterativă. Puteți profita de obiectivele existente, documentate și predefinite ale AD FS
care sunt relevante pentru desenele AD FS și dezvoltă o soluție de lucru pentru situația dvs.
Versiunile anterioare ale AD FS au fost utilizate cel mai frecvent pentru a realiza următoarele:
Oferind angajaților sau clienților dvs. o experiență SSO bazată pe web atunci când accesează
aplicațiile baza te pe revendicări din cadrul companiei dvs.
Oferind angajaților sau clienților dvs. o experiență SSO bazată pe web pentru a accesa resursele în
orice organizație partenere federată.
Oferind angajaților sau clienților dvs. o experiență SSO bazată pe Web atu nci când accesează de
la distanță site -uri sau servicii găzduite intern.
Oferind angajaților sau clienților dvs. o experiență SSO bazată pe web atunci când accesează
resurse sau servicii în cloud.
În plus, AD FS în Windows Server® 2012 R2 adaugă funcțional ități care vă pot ajuta să realizați
următoarele:
Dispozitivul de lucru al dispozitivului se alăture pentru SSO și autentificarea secundară fără
cusur. Acest lucru permite organizațiilor să permită accesul de la dispozitivele personale ale
utilizatorilor ș i să gestioneze riscul atunci când furnizează acest acces.
Gestionarea riscurilor prin controlul accesului multi -factor. AD FS oferă un nivel bogat de
autorizare care controlează cine are acces la ce aplicații. Acest lucru se poate baza pe atributele
utilizatorilor (UPN, email, apartenența la grupuri de securitate, puterea de autentificare etc.),
atributele dispozitivului (dacă dispozitivul este asociat la locul de muncă) sau solicitați atribute
(locație rețea, adresă IP sau agent utilizator).
Gestionarea r iscurilor cu autentificare multi -factor suplimentară pentru aplicații sensibile. AD FS
vă permite să controlați politicile pentru a putea necesita autentificare multifactorială la nivel
global sau pe baza unei aplicații. În plus, AD FS furnizează puncte de extensibilitate pentru orice

21
furnizor multi -factor care se integrează profund pentru o experiență multi -factor sigură și fără
probleme pentru utilizatorii finali.
Furnizarea de capacități de autentificare și de autorizare pentru accesarea resurselor web d in
extranet protejate de WAP .
Pentru a rezuma, AD FS în Windows Server 2012 R2 poate fi implementat pentru a atinge
următoarele obiective în organizația dvs.:
Permiteți utilizatorilor să acceseze resursele de pe dispozitivele personale de oriunde
A se ang aja la locul de muncă care permite utilizatorilor să se alăture dispozitivelor lor personale
în cadrul companiei Active Directory și ca rezultat să obțină acces și experiențe fără probleme
atunci când accesează resurse corporative de la aceste dispozitive.
Pre-autentificarea resurselor din cadrul rețelei corporative care sunt protejate de proxy -ul
Aplicației Web și accesate de pe internet.
Schimbarea parolei pentru a permite utilizatorilor să -și schimbe parola de la orice dispozitiv
conectat la locul de mun că atunci când parola a expirat, astfel încât să poată continua accesarea
resurselor.
Îmbunătățiți instrumentele de gestionare a riscului de control al accesului
Gestionarea riscului este un aspect important al guvernării și conformității în fiecare organ izație
IT. Există numeroase îmbunătățiri privind gestionarea riscurilor de control al accesului în AD FS
în Windows Server® 2012 R2, inclusiv următoarele:
Comenzi flexibile bazate pe locația rețelei pentru a stabili modul în care un utilizator se autentifi că
pentru a accesa o aplicație securizată AD FS.
Politică flexibilă pentru a determina dacă un utilizator trebuie să efectueze autentificarea multi –
factor pe baza datelor utilizatorului, a datelor dispozitivului și a locației în rețea.
Per-control de aplic ație pentru a ignora SSO și forța utilizatorului să ofere acreditări de fiecare
dată când accesează o aplicație sensibilă.
Politică flexibilă de acces pe aplicație, bazată pe datele utilizatorului, datele dispozitivului sau
locația rețelei.

22
AD FS Extranet Lockout, care permite administratorilor să protejeze conturile Active Directory
de atacuri de forță brute de pe internet.
Revocarea accesului pentru orice dispozitiv conectat la locul de muncă care este dezactivat sau
șters în Active Directory.
Utilizați A D FS pentru a îmbunătăți experiența de conectare
Următoarele sunt noile capabilități AD FS în Windows Server® 2012 R2 care permit
administratorului să personalizeze și să îmbunătățească experiența de conectare:
Modificarea unificată a serviciului AD FS, u nde modificările se fac o dată și apoi se propagă
automat către restul serverelor de federație AD FS dintr -o fermă dată.
Actualizați paginile de conectare care arată modern și răspund automat la factorii de formă diferiți.
Sprijinul pentru înlocuirea autom ată a autentificării bazate pe formulare pentru dispozitivele care
nu se alătură domeniului corporativ, dar care sunt încă folosite, generează cereri de acces din
interiorul rețelei corporative (intranet).
Controale simple pentru a particulariza logo -ul co mpaniei, imagine ilustrativă, linkuri standard
pentru suport IT, pagina de pornire, confidențialitate etc.
Personalizarea mesajelor de descriere în paginile de conectare.
Personalizarea temelor web.
Home Realm Discovery (HRD) bazată pe sufixul organizațion al al utilizatorului pentru o mai bună
confidențialitate a partenerilor unei companii.
Filtrarea HRD pe baza unei aplicații pentru a alege automat un domeniu bazat pe aplicație.
Raportare de eroare cu un singur clic pentru rezolvarea mai ușoară a problemel or IT.
Mesaje de eroare personalizabile.
Alegerea autentificării utilizatorului atunci când sunt disponibili mai mulți furnizori de
autentificare.
3.2.OPEN ID

23
Autorizați accesul la aplicațiile web utilizând OpenID Connect și Azure Active Directory
OpenID Conne ct este un simplu strat de identitate construit pe protocolul OAuth 2.0. OAuth 2.0
definește mecanisme pentru a obține și utiliza token -uri de acces pentru a accesa resursele
protejate, dar nu definesc metode standard pentru a furniza informații de identit ate. Conectarea
OpenID implementează autentificarea ca o extensie a procesului de autorizare OAuth 2.0. Acesta
oferă informații despre utilizatorul final sub forma unui id_token care verifică identitatea
utilizatorului și furnizează informații de bază desp re profil despre utilizator.
OpenID Connect este recomandarea noastră dacă construiți o aplicație web găzduită pe un server
și accesată printr -un browser.
Înregistrați -vă cererea cu chiriașul dvs. AD
În primul rând, trebuie să vă înregistrați cererea cu c hiriașul Azure Active Directory (Azure AD).
Acest lucru vă va oferi un ID de aplicație pentru aplicația dvs., precum și să îi permiteți să
primească jetoanele.
Conectați -vă la portalul Azure .
Alegeți chiriașul Azure AD dând clic pe contul dvs. în colțul d in dreapta sus al paginii.
În panoul de navigare din stânga, faceți clic pe Azure Active Directory .
Faceți clic pe Înregistrarea aplicațiilor și faceți clic pe Înregistrare nouă a aplicației .
Urmați instrucțiunile și creați o nouă aplicație. Nu contează dacă este o aplicație web sau o aplicație
nativă pentru acest tutorial, dar dacă doriți exemple specifice pentru aplicații web sau aplicații
native, verificați rapidul nostru.
Pentru aplicațiile Web, furnizați adresa URL de conectare , care este adresa URL de bază a
aplicației dvs., unde utilizatorii se pot conecta, de exemplu http://localhost:12345 .
Pentru aplicațiile native furnizați un URI de redirecționare , pe care Azure AD îl va folosi pentru
a returna răspunsurile token. Introduceți o valoare specif ică aplicației dvs., http://MyFirstAADApp
După ce ați terminat înregistrarea, Azure AD va atribui aplicației dvs. un identificator unic al
clientului, ID -ul aplicației . Aveți nevoie de această valoare în secțiunile următoare, așa că copiați –
o din pagina d e aplicație.

24
Pentru a găsi aplicația dvs. în portalul Azure, faceți clic pe Înscrierile aplicațiilor , apoi pe
Vizualizați toate aplicațiile .
Flux de autentificare utilizând OpenID Connect
Cel mai elementar flux de conectare conține următorii pași – fiecare dintre acestea este descris în
detaliu mai jos.
OpenId Connect Autentificare flux
Document OpenID pentru metadatele Connect
OpenID Connect descrie un document de metadate care conține majoritatea informațiilor necesare
pentru ca o aplicație să efectue ze conectarea. Acestea includ informații cum ar fi adresele URL de
utilizat și locația cheilor publice de semnare ale serviciului.
Metadatele sunt un document JSON (Object Notation) simplu. Consultați următorul fragment
pentru un exemplu. Conținutul frag mentului este descris complet în specificația OpenID Connect
.{ "authorization_endpoint": "https://login.microsoftonline.com/common/oauth2/authorize",
"token_endpoint": "https://login.microsoftonline.com/common/oauth2/token",
"token_endpoint_auth_methods_s upported": [ "client_secret_post", "private_key_jwt" ],
"jwks_uri": "https://login.microsoftonline.com/common/discovery/keys" … }
Trimiteți cererea de conectare
Atunci când aplicația web trebuie să autentifice utilizatorul, trebuie să direcționeze util izatorul
către /authorize endpoint. Această solicitare este similară cu prima etapă a fluxului de coduri de
autorizare OAuth 2.0 , cu câteva distincții importante:
Cererea trebuie să includă domeniul de aplicare openid în parametrul de scope .
Parametrul i d_token trebuie să includă id_token .
Cererea trebuie să includă parametrul nonce .
Astfel, o solicitare de eșantion ar arăta astfel:
// Line breaks for legibility only GET
https://login.microsoftonline.com/{tenant}/oauth2/authorize? client_id=6731de76 -14a6-49ae –

25
97bc -6eba6914391e &response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%3a12345 &response_mode=form_post
&scope=openid &state=12345 &nonce=7362CAEA -9CA5 -4B43 -9BA3 -34D7C303EBA7
Parametru Descriere
chiriaș necesar Valoarea {tenant} din calea cererii poate fi utilizată pentru a controla cine poate să
se înscrie în aplicație. Valorile permise sunt identificatorii chiriașilor, de exemplu, 8eaef023 -2b34 –
4da1 -9baa -8bc8c9d6a490 sau contoso.onmicrosoft.com sau common pentru jetoanele
independente de chiriaș
CLIENT_ID necesar ID-ul aplicației atribuit aplicației dvs. când l -ați înregistrat la Azure AD.
Puteți găsi acest lucru în Portalul Azure. Faceți clic pe Azure Active Directory , faceți clic pe
Înregistrarea aplicațiilor , alegeți aplicația și loca lizați Id -ul aplicației pe pagina aplicației.
response_type necesar Trebuie să includă id_token pentru conectarea OpenID Connect. Poate
include și alte tipuri de răspuns, cum ar fi code .
domeniu necesar O listă de spații separate. Pentru OpenID Connect, t rebuie să includă
domeniul de aplicare openid , care se traduce în permisiunea "Sign in" în interfața de utilizare a
consimțământului. Puteți include și alte domenii în această solicitare de solicitare a
consimțământului.
nonce necesar O valoare inclusă în cerere, generată de aplicație, care este inclusă în id_token
rezultată ca revendicare. Aplicația poate apoi să verifice această valoare pentru a atenua atacurile
de repetare token. Valoarea este de obicei un șir randomizat, unic sau GUID care poate fi fol osit
pentru a identifica originea solicitării.
redirect_uri recomandat Redirect_uri din aplicația dvs., în care răspunsurile la autentificare
pot fi trimise și primite de aplicația dvs. Trebuie să se potrivească exact cu unul din redirect_uris
pe care l -ați înregistrat în portal, cu excepția faptului că trebuie să fie codat url.
response_mode recomandat Specifică metoda care ar trebui folosită pentru a trimite
codul de autorizare rezultat înapoi în aplicație. Valorile acceptate sunt form_post pentru formula rul
HTTP post și fragment pentru fragment de adresă URL . Pentru aplicațiile web, vă recomandăm

26
să utilizați response_mode=form_post pentru a vă asigura transferul cel mai sigur de jetoane în
aplicația dvs. Modul implicit, dacă nu este inclus modul de răsp uns_, este fragment .
stat recomandat O valoare inclusă în cerere care este returnată în răspunsul token. Acesta
poate fi un șir de orice conținut pe care doriți. O valoare unică generată la întâmplare este folosită
în mod tipic pentru a împiedica atacuril e de tip "forge t request" . Statul este, de asemenea, utilizat
pentru a codifica informații despre starea utilizatorului în aplicație înainte ca cererea de
autentificare să aibă loc, cum ar fi pagina sau vizualizarea pe care s -au aflat.
prompt facultativ Indică tipul de interacțiune a utilizatorului necesar. În prezent, singurele
valori valide sunt "login", "none" și "consent". prompt=login forțează utilizatorul să introducă
acreditările la cererea respectivă, negând semnalul unic. prompt=none este opusul – se asigură că
utilizatorul nu este prezentat cu nici un fel de interacțiune interactivă. Dacă cererea nu poate fi
terminată în mod silențios prin semnalizarea unică, punctul final trimite o eroare. prompt=consent
declanșează dialogul de aprobare OAuth dup ă ce utilizatorul se conectează, solicitând
utilizatorului să acorde permisiuni aplicației.
login_hint facultativ Poate fi folosit pentru a pre -umple câmpul pentru numele de
utilizator / adresa de e -mail a paginii de conectare pentru utilizator, dacă știți numele de utilizator
înaintea timpului. Adesea, aplicațiile utilizează acest parametru în timpul reaut entificării, după ce
au extras deja numele de utilizator dintr -o conectare anterioară, folosind mențiunea preferred_
username pentru numele de utilizator .
În acest moment, utilizatorul este rugat să introducă acreditările și să completeze autentificarea.
Exemplu de răspuns
Un răspuns de eșantion, după ce utilizatorul a autentificat, ar putea arăta astfel:
POST / HTTP/1.1 Host: localhost:12345 Content -Type : application/x -www -form -urlencoded
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB…&state=12
345
Parametru Descriere
id_token id_token ul solicitat de aplicație. Puteți utiliza id_token pentru a verifica identitatea
utilizatorului și a începe o sesiune cu utilizatorul.

27
stat O valoare inclusă în solicitare care este returnată și în răspunsul token. O valoare unică
generată la întâmplare este folosită în mod tipic pentru a împiedica atacurile de tip "forgery
request" . Statul este, de ase menea, utilizat pentru a codifica informații despre starea utilizatorului
în aplicație înainte ca cererea de autentificare să aibă loc, cum ar fi pagina sau vizualizarea pe care
s-au aflat.
Răspuns la eroare
De asemenea, răspunsurile de eroare pot fi trim ise la redirect_uri astfel încât aplicația să le poată
gestiona în mod corespunzător:
POST / HTTP/1.1 Host: localhost:12345 Content -Type: application/x -www -form -urlencoded
error=access_denied&error_description=the+ utilizator +canceled+the+authentication
Parametru Descriere
eroare Un șir de cod de eroare care poate fi folosit pentru a clasifica tipurile de erori care apar și
poate fi folosit pentru a reacționa la erori.
ERROR_DESCRIPTION Un mesaj de eroare specific care poate ajuta un dezvoltator să
identif ice cauza principală a unei erori de autentificare.
Codurile de eroare pentru erorile de punct final de autorizare
Următorul tabel descrie diferitele coduri de eroare care pot fi returnate în parametrul de eroare al
răspunsului la eroare.
Cod de eroare Descriere Acțiunea clientului
cerere invalida Eroare de protocol, cum ar fi un parametru lipsă. Remediați și retrimiteți
solicitarea. Aceasta este o eroare de dezvoltare și este de obicei prinsă în timpul testelor inițiale.
unauthorized_client Aplicația clie nt nu are permisiunea de a solicita un cod de autorizare.
Acest lucru apare, de obicei, atunci când aplicația client nu este înregistrată în Azure AD
sau nu este adăugată la chiriașul AD Azure al utilizatorului. Aplicația poate solicita utilizatorului
instrucțiuni pentru instalarea aplicației și adăugarea acesteia la Azure AD.
acces interzis Resursele proprietarului au refuzat acordul Aplicația client poate notifica
utilizatorului că nu poate continua decât dacă consimțământul utilizatorului.

28
unsupported_re sponse_type Serverul de autorizare nu acceptă tipul de răspuns din cerere.
Remediați și retrimiteți solicitarea. Aceasta este o eroare de dezvoltare și este de obicei
prinsă în timpul testelor inițiale.
Eroare de server Serverul a întâmpinat o eroare neașt eptată. Reîncercați cererea. Aceste
erori pot rezulta din condiții temporare. Aplicația client ar putea explica utilizatorului că răspunsul
său este întârziat din cauza unei erori temporare.
Temporar indisponibil Serverul este temporar prea ocupat pentru a face față cererii.
Reîncercați cererea. Aplicația client ar putea explica utilizatorului că răspunsul său este
întârziat din cauza unei condiții temporare.
invalid_resource Resursa țintă nu este validă deoarece nu există, Azure AD nu o poate găsi
sau nu e ste configurată corect. Aceasta indică faptul că resursa, dacă există, nu a fost
configurată în chiriaș. Aplicația poate solicita utilizatorului instrucțiuni pentru instalarea aplicației
și adăugarea acesteia la Azure AD.
Validați id_token
Doar primirea u nui id_token nu este suficientă pentru a autentifica utilizatorul; trebuie să validați
semnătura și să verificați revendicările din id_token funcție de cerințele aplicației dvs. Obiectivul
Azure AD utilizează JSON Web Tokens (JWTs) și criptografia cheilor publice pentru a semna
token -uri și a verifica dacă acestea sunt valide.
Puteți alege să validați codul id_token în codul clientului, dar o practică obișnuită este să trimiteți
id_token la un server backend și să efectuați validarea acolo. Odată ce ați val idat semnătura
id_token , există câteva revendicări pe care trebuie să le verificați.
Puteți, de asemenea, să doriți să validați pretenții suplimentare în funcție de scenariul dvs. Unele
validări comune includ:
Asigurați -vă că utilizatorul / organizația sa înscris pentru aplicație.
Asigurarea că utilizatorul are autorizație / privilegii corespunzătoare
Asigurarea unei anumite valori a autentificării a avut loc, cum ar fi autentificarea multifactorială.

29
Odată ce ați validat id_token , puteți începe o sesiune cu utilizatorul și puteți utiliza revendicările
din id_token pentru a obține informații despre utilizatorul din aplicația dvs. Aceste informații pot
fi utilizate pentru afișare, înregistrări, autorizări etc. Pentru mai multe informații despre tipurile de
jetoane și despre revendicări, citiți Tipurile de jetoane acceptate și de revendicare .
Trimiteți o solicitare de deconectare
Când doriți să semnați utilizatorul din aplicație, nu este suficient să ștergeți cookie -urile aplicației
sau să încheiați în alt mod sesiunea cu utilizatorul. De asemenea, trebuie să redirecționați
utilizatorul spre punctul de end_session_endpoint pentru a vă deconecta. Dacă nu reușiți,
utilizatorul va putea re intra în aplicația dvs. fără a -și introduce din nou datele de acreditare,
deoarece va avea o sesiune de conectare unică validă cu punctul final Azure AD.
Puteți redirecționa pur și simplu utilizatorul la punctul de end_session_endpoint listat în
documentul OpenID Connect metadata:
GET https://login.microsoftonline.com/common/oa uth2/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
Parametru Descriere
post_logout_redirect_uri recomandat Adresa URL la care utilizatorul ar trebui să fie
redirecționat după o deconectare reușită. Dacă nu este inclus, utilizatorul p rimește un mesaj
generic.
Sign-out singular
Când redirecționați utilizatorul la punctul de end_session_endpoint , Azure AD șterge sesiunea
utilizatorului din browser. Cu toate acestea, utilizatorul poate fi încă conectat la alte aplicații care
utilizează Azure AD pentru autentificare. Pentru a permite acestor aplicații să semneze simultan
utilizatorul, Azure AD trimite o cerere HTTP GET către LogoutUrl înregistrat pentru toate
aplicațiile la care este conectat utilizatorul. Aplicațiile trebuie să răspundă la această solicitare prin
eliminarea oricărei sesiuni care identifică utilizatorul și returnând răspunsul de 200 . Dacă doriți
să LogoutUrl semnarea unică în aplicația dvs., trebuie să implementați un astfel de LogoutUrl în
codul aplicației. Puteți seta L ogoutUrl din portalul Azure:
Navigați la portalul Azure .

30
Alegeți -vă Active Directory făcând clic pe contul dvs. în colțul din dreapta sus al paginii.
Din panoul de navigare din partea stângă, alegeți Azure Active Directory , apoi selectați
Înregistrări ap licație și selectați aplicația.
Faceți clic pe Setări , apoi pe Proprietăți și găsiți caseta de text pentru URL -ul de deconectare .
Achiziționarea de mărci
Multe aplicații web trebuie să semneze nu numai utilizatorul, ci și să acceseze un serviciu web în
numele acelui utilizator utilizând OAuth. Acest scenariu combină OpenID Connect pentru
autentificarea utilizatorilor, în timp ce achiziționează simultan un c od de authorization_code care
poate fi folosit pentru a obține access_tokens folosind fluxul de coduri de autorizare OAuth .
Obțineți jetoane de acces
Pentru a obține jetoane de acces, trebuie să modificați din mai sus solicitarea de conectare:
// Line br eaks for legibility only GET
https://login.microsoftonline.com/{tenant}/oauth2/authorize? client_id=6731de76 -14a6 -49ae –
97bc -6eba6914391e // Your registered Application Id &response_type=id_token+code
&redirect_uri=http%3A%2F%2Flocalhost%3a12345 // Your reg istered Redirect Uri, url encoded
&response_mode=form_post // `form_post' or 'fragment' &scope=openid
&resource=https%3A%2F%2Fservice.contoso.com%2F &state=12345 // Any value, provided by
your app &nonce=678910 // Any value, provided by your app
Prin incl uderea response_type=code+id_token permisiune în cerere și prin utilizarea
response_type=code+id_token , criteriul final al authorize asigură că utilizatorul și -a dat acordul
pentru permisiunile indicate în parametrul interogării de scope și returnează apl icației un cod de
autorizare pentru a schimba un jeton de acces.
Răspunsul de succes
Răspunsul reușit utilizând response_mode=form_post arată astfel:
POST /myapp/ HTTP/1.1 Host: localhost Content -Type: application/x -www -form -urlencoded
id_token=eyJ0eXAiOi JKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB…&code=A
wABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq…&state=12345

31
Parametru Descriere
id_token id_token ul solicitat de aplicație. Puteți utiliza id_token pentru a verifica identitatea
utilizatorulu i și a începe o sesiune cu utilizatorul.
cod Codul de autorizare solicitat de aplicație. Aplicația poate utiliza codul de autorizare pentru
a solicita un indicativ de acces pentru resursa țintă. Codurile de autorizare sunt de scurtă durată și,
de obicei, e xpiră după aproximativ 10 minute.
stat Dacă în solicitare este inclus un parametru de stare, în răspuns trebuie să apară aceeași
valoare. Aplicația trebuie să verifice dacă valorile de stare din cerere și răspuns sunt identice.
Răspuns la eroare
De asemen ea, răspunsurile de eroare pot fi trimise la redirect_uri astfel încât aplicația să le poată
gestiona în mod corespunzător:
POST /myapp/ HTTP/1.1 Host: localhost Content -Type: application/x -www -form -urlencoded
error=access_denied&error_description=the+ utilizator +canceled+the+authentication
Parametru Descriere
eroare Un șir de cod de eroare care poate fi folosit pentru a clasifica tipurile de erori care apar și
poate fi folosit pentru a reacționa la erori.
ERROR_DESCRIPTION Un mesaj de eroare specific care poate ajuta un dezvoltator să
identifice cauza principală a unei erori de autentificare.
Pentru o descriere a eventualelor coduri de eroare și a acțiunii clientului recomandate, vedeți
codurile de eroare pentru erorile de punct final .
Odată ce ați obținu t un code autorizare și un id_token , puteți semna utilizatorul și primiți jetoanele
de acces în numele acestuia. Pentru a semna utilizatorul, trebuie să validați id_token exact așa cum
este descris mai sus. Pentru a obține jetoanele de acces, puteți urma pașii descriși în secțiunea
"Utilizați codul de autorizare pentru a solicita un simbol de acces" din documentația noastră de
protocoale OAuth
3.3.OAuth

32
Autorizați accesul la aplicațiile web Azure Active Directory utilizând fluxul de granturi pentru
codul OAut h 2.0
Azure Active Directory (Azure AD) utilizează OAuth 2.0 pentru a vă permite să autorizați accesul
la aplicațiile web și la API -urile web ale agentului dvs. Azure AD. Acest ghid este independent de
limbă și descrie modul de trimitere și primire a mesaj elor HTTP fără a utiliza oricare dintre
bibliotecile noastre open -source .
În primul rând, trebuie să vă înregistrați cererea cu chiriașul Azure Active Directory (Azure AD).
Acest lucru vă va oferi un ID de aplicație pentru aplicația dvs., precum și să îi permiteți să
primească jetoanele.
Conectați -vă la portalul Azure .
Alegeți chiriașul Azure AD dând clic pe contul dvs. în colțul din dreapta sus al paginii.
În panoul de navigare din stânga, faceți clic pe Azure Active Directory .
Faceți clic pe Înregistra rea aplicațiilor și faceți clic pe Înregistrare nouă a aplicației .
Urmați instrucțiunile și creați o nouă aplicație. Nu contează dacă este o aplicație web sau o aplicație
nativă pentru acest tutorial, dar dacă doriți exemple specifice pentru aplicații web sau aplicații
native, verificați rapidul nostru.
Pentru aplicațiile Web, furnizați adresa URL de conectare , care este adresa URL de bază a
aplicației dvs., unde utilizatorii se pot conecta, de exemplu http://localhost:12345 .
Pentru aplicațiile native fu rnizați un URI de redirecționare , pe care Azure AD îl va folosi pentru
a returna răspunsurile token. Introduceți o valoare specifică aplicației dvs., http://MyFirstAADApp
După ce ați terminat înregistrarea, Azure AD va atribui aplicației dvs. un identific ator unic al
clientului, ID -ul aplicației . Aveți nevoie de această valoare în secțiunile următoare, așa că copiați –
o din pagina de aplicație.
Pentru a găsi aplicația dvs. în portalul Azure, faceți clic pe Înscrierile aplicațiilor , apoi pe
Vizualizați toa te aplicațiile .
Fluxul de autorizare OAuth 2.0

33
La un nivel ridicat, întregul flux de autorizare pentru o aplicație arată cam așa:
Solicitați un cod de autorizare
Fluxul de cod de autorizare începe cu clientul care îl direcționează către /authorize punct ul final.
În această solicitare, clientul indică permisiunile de care are nevoie pentru a obține de la utilizator.
Puteți obține obiectivul de autorizare OAuth 2.0 pentru chiriașul dvs., selectând Înregistrări
aplicații> Obiective în portalul Azure.
// Lin e breaks for legibility only https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76 -14a6 -49ae -97bc -6eba6914391e &response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%3A12345 &response_mode=query
&resource=https%3A%2F%2Fservice.c ontoso.com%2F &state=12345
Parametru Descriere
chiriaș necesar Valoarea {tenant} din calea cererii poate fi utilizată pentru a controla cine poate să
se înscrie în aplicație. Valorile permise sunt identificatorii chiriașilor, de exemplu, 8eaef023 -2b34 –
4da1-9baa -8bc8c9d6a490 sau contoso.onmicrosoft.com sau common pentru jetoanele
independente de chiriaș
CLIENT_ID necesar ID-ul aplicației atribuit aplicației dvs. atunci când l -ați înregistrat la Azure
AD. Puteți găsi acest lucru în Portalul Azure. Faceți cl ic pe Azure Active Directory în bara laterală
a serviciilor, faceți clic pe Înregistrarea aplicațiilor și alegeți aplicația.
response_type necesar Trebuie să includă code pentru fluxul de cod de autorizare.
redirect_uri recomandat Redirect_uri din aplicați a dvs., în care răspunsurile la autentificare
pot fi trimise și primite de aplicația dvs. Trebuie să se potrivească exact cu unul din redirect_uris
pe care l -ați înregistrat în portal, cu excepția faptului că trebuie să fie codat url. Pentru aplicațiile
native și mobile, ar trebui să utilizați valoarea implicită a urn:ietf:wg:oauth:2.0:oob .
response_mode recomandat Specifică metoda care ar trebui utilizată pentru a trimite
tokenul rezultat înapoi în aplicație. Poate fi query sau form_post . query furnizeaz ă codul ca
parametru șir de interogare în URI de redirecționare, în timp ce form_post execută un POST care
conține codul în URI de redirecționare.

34
stat recomandat O valoare inclusă în solicitare care este returnată și în răspunsul token. O
valoare unică ge nerată la întâmplare este folosită în mod tipic pentru a împiedica atacurile de tip
"forgery request" . Statul este, de asemenea, utilizat pentru a codifica informații despre starea
utilizatorului în aplicație înainte ca cererea de autentificare să aibă lo c, cum ar fi pagina sau
vizualizarea pe care s -au aflat.
resursă recomandat ID-ul URI al aplicației pentru API -ul Web destinație (resursă securizată).
Pentru a găsi URI -ul App ID, în Azure Portal, faceți clic pe Azure Active Directory , faceți clic pe
Înscrierile aplicațiilor , deschideți pagina Setări a aplicației, apoi faceți clic pe Proprietăți . Poate
fi și o resursă externă, cum ar fi https://graph.microsoft.com . Acest lucru este necesar într -una din
cererile de autorizare sau token. Pentru a asigura o mai puține autentificări solicită, plasați -o în
cererea de autorizare pentru a vă asigura că consimțământul este primit de la utilizator.
domeniu ignorate Pentru aplicațiile v1 Azure AD, domeniile trebuie să fie configurate
static în portalul Azure în ca drul aplicațiilor Setări , Permisiuni necesare .
prompt facultativ Indicați tipul de interacțiune a utilizatorului necesar.
Valorile valide sunt:
login : Utilizatorul trebuie să fie rugat să reautentifice .
select_account : Utilizatorul este rugat să select eze un cont, întreruperea semnului unic.
Utilizatorul poate să selecteze un cont deja conectat, să introducă acreditările pentru un cont
amintit sau să aleagă altfel să utilizeze alt cont.
consimțământ : A fost acordat acordul utilizatorului, dar trebuie a ctualizat. Utilizatorul ar trebui
să fie îndemnat să consimtă.
admin_consent : Un administrator ar trebui să fie îndemnat să consimtă în numele tuturor
utilizatorilor din organizația lor
login_hint facultativ Poate fi folosit pentru a pre -umple câmpul pent ru numele de
utilizator / adresa de e -mail a paginii de conectare pentru utilizator, dacă știți numele de utilizator
înaintea timpului. Adesea, aplicațiile utilizează acest parametru în timpul reau tentif icării, după ce
au extras deja numele de utilizator d intr-o conectare anterioară, folosind mențiunea preferred_
username pentru numele de utilizator.

35
domain_hint facultativ Oferă o sugestie despre chiriaș sau domeniu pe care utilizatorul ar
trebui să o utilizeze pentru a vă conecta. Valoarea domain_hint este un domeniu înregistrat pentru
chiriaș. În cazul în care chiriașul este federalizat într -un director local, AAD redirecționează către
serverul de federații de locatari specificat.
code_challenge_method facultativ Metoda utilizată pentru codarea codificator ului
pentru parametrul code_challenge . Poate fi unul plain sau S256 . Dacă este exclusă,
code_challenge se presupune a fi text în cazul în care code_challenge este inclus. Azure AAD v1.0
suportă atât S256 plain cât și S256 . Pentru mai multe informații, c onsultați PKCE RFC .
code_challenge facultativ Folosit pentru a obține subvenții de cod de autorizare prin
intermediul Proof Key for Code Exchange (PKCE) de la un client nativ sau public. Obligatoriu
dacă este inclus code_challenge_method . Pentru mai mult e informații, consultați PKCE RFC .
Notă
Dacă utilizatorul face parte dintr -o organizație, un administrator al organizației poate consimți sau
refuza în numele utilizatorului sau permite utilizatorului să -și dea consimțământul. Utilizatorului
i se oferă o pțiunea de a consimți numai atunci când administratorul o permite.
În acest moment, utilizatorul este rugat să introducă acreditările și să consimtă permisiunea
solicitată de aplicație în Portalul Azure. Odată ce utilizatorul autentifică și acordă consimță mântul,
Azure AD trimite un răspuns la aplicația dvs. la adresa redirect_uri din solicitarea dvs. împreună
cu codul.
Răspunsul reușit
Un răspuns reușit ar putea arăta astfel:
GET HTTP/1.1 302 Found Location: http://localhost:12345/?code=
AwABAAAAvPM1KaPlr EqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrqqf_ZT_p5uEAEJJ
_nZ3UmphWygRNy2C3jJ239gV_DBnZ2syeg95Ki -374WHUP -i3yIhv5i –
7KU2CEoPXwURQp6IVYMw –
DjAOzn7C3JCu5wpngXmbZKtJdWmiBzHpcO2aICJPu1KvJrDLDP20chJBXzVYJtkfjviLNNW
7l7Y3ydcHDsBRKZc3GuMQanmcghXPyoDg41g8XbwPudVh7uCmUponBQpIh buffFP_tbV8S
NzsPoFz9CLpBCZagJVXeqWoYMPe2dSsPiLO9Alf_YIe5zpi –

36
zY4C3aLw5g9at35eZTfNd0gBRpR5ojkMIcZZ6IgAA&session_state=7B29111D -C220 -4263 –
99AB -6F6E135D75EF&state=D79E5777 -702E -4260 -9A62 -37F75FF22CCE
Parametru Descriere
admin_consent Valoarea este Adevărată da că un administrator a dat consimțământul
solicitării de aprobare.
cod Codul de autorizare solicitat de aplicație. Aplicația poate utiliza codul de autorizare pentru
a solicita un indicativ de acces pentru resursa țintă.
session_state O valoare unică care i dentifică sesiunea curentă a utilizatorului. Această valoare
este un GUID, dar trebuie tratată ca o valoare opacă care este trecută fără examinare.
stat Dacă în solicitare este inclus un parametru de stare, în răspuns trebuie să apară aceeași
valoare. Este o bună practică pentru ca aplicația să verifice dacă valorile de stare din cerere și
răspuns sunt identice înainte de a utiliza răspunsul. Acest lucru ajută la detectarea atacurilor de tip
"Forgery Request Cross -Site" (CSRF) împotriva clientului.
Răspuns la eroare
De asemenea, răspunsurile de eroare pot fi trimise la redirect_uri astfel încât aplicația să le poată
gestiona în mod corespunzător.
GET http://localhost:12345/? error=access_denied &error_description=the+
utilizator +canceled+the+authentication
Parametru Descriere
eroare O valoare de cod de eroare definită în secțiunea 5.2 din cadrul de autorizare OAuth 2.0 .
Următorul tabel descrie codurile de eroare pe care Azure AD le întoarce.
ERROR_DESCRIPTION O descriere mai detaliată a erorii. Acest mesaj nu este destinat să fie
prietenos pentru utilizatorii finali.
stat Valoarea de stat este o valoare non -reutilizată generată la întâmplare care este trimisă în
cerere și returnată în răspuns pentru a preveni atacurile de tip "forgery request" (CSRF).
Coduri le de eroare pentru erorile de punct final de autorizare

37
Următorul tabel descrie diferitele coduri de eroare care pot fi returnate în parametrul de eroare al
răspunsului la eroare.
Cod de eroare Descriere Acțiunea clientului
cerere invalida Eroare de prot ocol, cum ar fi un parametru lipsă. Remediați și retrimiteți
solicitarea. Aceasta este o eroare de dezvoltare și este de obicei prinsă în timpul testelor inițiale.
unauthorized_client Aplicația client nu are permisiunea de a solicita un cod de autorizare.
Acest lucru apare, de obicei, atunci când aplicația client nu este înregistrată în Azure AD
sau nu este adăugată la chiriașul AD Azure al utilizatorului. Aplicația poate solicita utilizatorului
instrucțiuni pentru instalarea aplicației și adăugarea acestei a la Azure AD.
acces interzis Resursele proprietarului au refuzat acordul Aplicația client poate notifica
utilizatorului că nu poate continua decât dacă consimțământul utilizatorului.
unsupported_response_type Serverul de autorizare nu acceptă tipul de răs puns din cerere.
Remediați și retrimiteți solicitarea. Aceasta este o eroare de dezvoltare și este de obicei
prinsă în timpul testelor inițiale.
Eroare de server Serverul a întâmpinat o eroare neașteptată. Reîncercați cererea. Aceste
erori pot rezulta din condiții temporare. Aplicația client ar putea explica utilizatorului că răspunsul
său este întârziat din cauza unei erori temporare.
Temporar indisponibil Serverul este temporar prea ocupat pentru a face față cererii.
Reîncercați cererea. Aplicația client ar putea explica utilizatorului că răspunsul său este
întârziat din cauza unei condiții temporare.
invalid_resource Resursa țintă nu este validă deoarece nu există, Azure AD nu o poate găsi
sau nu este configurată corect. Aceasta indică faptul că resursa, dacă există, nu a fost
configurată în chiriaș. Aplicația poate solicita utilizatorului instrucțiuni pentru instalarea aplicației
și adăugarea acesteia la Azure AD.
Utilizați codul de autorizare pentru a solicita un simbol de acces

38
Acum, când ați obținut u n cod de autorizare și ați primit permisiunea utilizatorului, puteți să
valorificați codul pentru un indicativ de acces la resursa dorită, trimițând o solicitare POST la
punctul final /token :
// Line breaks for legibility only POST /{tenant}/oauth2/token HTTP/1.1 Host:
https://login.microsoftonline.com Content -Type: application/x -www -form -urlencoded
grant_type=authorization_code &client_id=2d4d11a2 -f814-46a7 -890a -274a72a7309e
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrqqf_ZT_p5
uEAEJJ_nZ3Umph WygRNy2C3jJ239gV_DBnZ2syeg95Ki -374WHUP -i3yIhv5i –
7KU2CEoPXwURQp6IVYMw –
DjAOzn7C3JCu5wpngXmbZKtJdWmiBzHpcO2aICJPu1KvJrDLDP20chJBXzVYJtkfjviLNNW
7l7Y3ydcHDsBRKZc3GuMQanmcghXPyoDg41g8XbwPudVh7uCmUponBQpIhbuffFP_tbV8S
NzsPoFz9CLpBCZagJVXeqWoYMPe2dSsPiLO9Alf_YIe5zp i-
zY4C3aLw5g9at35eZTfNd0gBRpR5ojkMIcZZ6IgAA
&redirect_uri=https%3A%2F%2Flocalhost%3A12345
&resource=https%3A%2F%2Fservice.contoso.com%2F &client_secret=p@ssw0rd //NOTE:
client_secret only required for web apps
Parametru Descriere
chiriaș necesar Valoarea {tenant} din calea cererii poate fi utilizată pentru a controla cine poate să
se înscrie în aplicație. Valorile permise sunt identificatorii chiriașilor, de exemplu, 8eaef023 -2b34 –
4da1 -9baa -8bc8c9d6a490 sau contoso.onmicrosoft.com sau common pentru jetoane le
independente de chiriaș
CLIENT_ID necesar ID-ul aplicației atribuit aplicației dvs. când l -ați înregistrat la Azure AD.
Puteți găsi acest lucru în portalul Azure. ID -ul aplicației este afișat în setările înregistrării aplicației.
grant_type necesar Treb uie să fie codul authorization_ pentru fluxul de cod de autorizare.
cod necesar Codul de authorization_code care l -ați achiziționat în secțiunea anterioară
redirect_uri necesar Aceeași valoare redirect_uri care a fost utilizată pentru a obține codul de
authorization_code .

39
client_secret necesar pentru aplicațiile web, care nu sunt permise pentru clienții publici
Secretul aplicației pe care l -ați creat în portalul Azure pentru aplicația dvs. sub Chei . Nu
poate fi folosit într -o aplicație nativă (client publ ic), deoarece secțiunile client_secrets nu pot fi
stocate în mod fiabil pe dispozitive. Este necesar pentru aplicațiile web și API -urile web (toți
clienții confidențiali), care au capacitatea de a stoca client_secret siguranță din partea serverului.
resurs ă recomandat ID-ul URI al aplicației pentru API -ul Web destinație (resursă securizată).
Pentru a găsi URI -ul App ID, în Azure Portal, faceți clic pe Azure Active Directory , faceți clic pe
Înscrierile aplicațiilor , deschideți pagina Setări a aplicației, a poi faceți clic pe Proprietăți . Poate
fi și o resursă externă, cum ar fi https://graph.microsoft.com . Acest lucru este necesar într -una din
cererile de autorizare sau token. Pentru a asigura o mai puține autentificări solicită, plasați -o în
cererea de au torizare pentru a vă asigura că consimțământul este primit de la utilizator. Dacă atât
în cererea de autorizare, cât și în solicitarea tokenului, parametrii resurselor trebuie să se
potrivească.
code_verifier facultativ Același verificator de cod care a fo st utilizat pentru a obține codul
de autorizare. Necesar dacă PKCE a fost utilizat în cererea de acordare a codului de autorizare.
Pentru mai multe informații, consultați PKCE RFC
Pentru a găsi URI -ul App ID, în Azure Portal, faceți clic pe Azure Active Di rectory , faceți clic pe
Înscrierile aplicațiilor , deschideți pagina Setări a aplicației, apoi faceți clic pe Proprietăți .
Răspunsul reușit
Azure AD returnează un jeton de acces printr -un răspuns de succes. Pentru a minimiza apelurile
de rețea din aplic ația client și latența asociată, aplicația client ar trebui să cache -ze token -urile de
acces pentru durata de viață a tokenului specificată în răspunsul OAuth 2.0. Pentru a determina
durata de viață a tokenului, utilizați valorile parametrilor expires_on s au expires_on .
Dacă o resursă API web returnează un cod de eroare invalid_token , aceasta ar putea indica faptul
că resursa a determinat expirarea tokenului. Dacă timpul clientului și al ceasului de resurse sunt
diferite (cunoscut sub numele de "time skew "), resursa ar putea considera că tokenul a expirat
înainte ca tokenul să fie șters din cache -ul clientului. Dacă se întâmplă acest lucru, debifați jetonul
din memoria cache, chiar dacă acesta se află încă în durata de viață calculată.

40

Un răspuns reușit a r putea arăta astfel:
{ "access_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1THdqcHdBSk
9NOW4tQSJ9.eyJhdWQiOiJodHRwczovL.JZw8jC0gptZxVC –
7l5sFkdnJgP3_tRjeQEPgUn28XctVe3QqmheLZw7QVZDPCyGycDWBaqy7FLpSekET_BftDk
ewRhyHk9FW_KeEz0ch2c3i 08NGNDbr6XYGVayNuSesYk5Aw_p3ICRlUV1bqEwk –
Jkzs9EEkQg4hbefqJS6yS1HoV_2EsEhpd_wCQpxK89WPs3hLYZETRJtG5kvCCEOvSHXmD
E6eTHGTnEgsIk –
UlPe275Dvou4gEAwLofhLDQbMSjnlV5VLsjimNBVcSRFShoxmQwBJR_b2011Y5IuD6St5z
PnzruBbZYkGNurQK63TJPWmRd3mbJsGM0mf3CUQ", "token_type": "Bear er", "expires_in":
"3600", "expires_on": "1388444763", "resource": "https://service.contoso.com/", "refresh_token":
"AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4rTfgV29ghDOHRc2B –
C_hHeJaJICqjZ3mY2b_YNqmf9SoAylD1PycGCB90xzZeEDg6oBzOIPfYsbDWNf621pKo2Q3
GGTHYlmN fwoc –
OlrxK69hkha2CF12azM_NYhgO668yfcUl4VBbiSHZyd1NVZG5QTIOcbObu3qnLutbpadZGA
xqjIbMkQ2bQS09fTrjMBtDE3D6kSMIodpCecoANon9b0LATkpitimVCrl –
NyfN3oyG4ZCWu18M9 -vEou4Sq -1oMDzExgAf61noxzkNiaTecM –
Ve5cq6wHqYQjfV9DOz4lbceuYCAA", "scope":
"https%3A%2F%2Fgraph.microsoft. com%2Fmail.read", "id_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi." }
jeton de acces Tokenul de acces solicitat ca JSON Web Token (JWT) semnat. Aplicația poate
folosi acest jeton pentru a se autentifica la resursa securizată, cum a r fi un API web.
token_type Indică valoarea tipului de jeton. Singurul tip pe care îl susține Azure AD este
purtătorul. Pentru mai multe informații despre jetoanele purtătorului, consultați OAuth2.0
Framework Authorization: Utilizarea tokenului la purtător (RFC 6750)
expira in Cât timp indicatorul de acces este valabil (în secunde).

41
expira la Momentul în care expiră tokenul de acces. Data este reprezentată ca numărul de
secunde de la 1970 -01-01T0: 0: 0Z UTC până la ora de expirare. Această valoare este util izată
pentru a determina durata de viață a jetoanelor memorate în memoria cache.
resursă URI ID al aplicației din API -ul web (resursă securizată).
domeniu Permisiunile de împărțire acordate aplicației client. Permisiunea implicită este
utilizator _imperson ation . Proprietarul resursei securizate poate înregistra valori suplimentare în
Azure AD.
refresh_token Un jet de reîmprospătare OAuth 2.0. Aplicația poate folosi acest jeton pentru a
obține jetoane de acces suplimentare după expirarea tokenului de acces curent. Jetoanele de
reîmprospătare sunt de lungă durată și pot fi utilizate pentru a menține accesul la resurse pentru
perioade lungi de timp.
id_token Un JSON Web Token (JWT) nesemnat. Aplicația poate decoda segmentele acestui
token pentru a solicita inf ormații despre utilizatorul care sa conectat. Aplicația poate să cache -ze
valorile și să le afișeze, dar nu ar trebui să se bazeze pe acestea pentru nicio autorizație sau limite
de securitate.
JWT Token Revendicări
id_token JWT în valoarea parametrului id _token poate fi decodificat în următoarele afirmații:
{ "typ": "JWT", "alg": "none" }. { "aud": "2d4d11a2 -f814-46a7 -890a -274a72a7309e", "iss":
"https://sts.windows.net/7fe81447 -da57 -4385 -becb -6de57f21477e/", "iat": 1388440863, "nbf":
1388440863, "exp": 138 8444763, "ver": "1.0", "tid": "7fe81447 -da57 -4385 -becb -6de57f21477e",
"oid": "68389ae2 -62fa-4b18 -91fe-53dd109d74f5", "upn": "frank@contoso.com",
"unique_name": "frank@contoso.com", "sub":
"JWvYdCWPhhlpS1Zsf7yYUxShUwtUm5yzPmw_ -jX3fHY", "family_name": "Mille r",
"given_name": "Frank" }.

Pentru mai multe informații despre jetoanele web JSON, consultați specificația JWT IETF draft .
Pentru mai multe informații despre tipurile de jetoane și despre revendicări, citiți Tipurile de
jetoane acceptate și de revendic are

42
Parametrul id_token include următoarele tipuri de reclamații:
Tip de revendicare Descriere
aud Audiența simbolului. Când jetonul este emis pentru o aplicație client, publicul este
client_id al clientului.
exp Data expirarii. Momentul în care expiră tok enul. Pentru ca tokenul să fie valabil, data / ora
curentă trebuie să fie mai mică sau egală cu valoarea exp . Timpul este reprezentat ca numărul de
secunde din 1 ianuarie 1970 (1970 -01-01T0: 0: 0Z) UTC până la expirarea valabilității tokenului.
nume de fa milie Nume de familie sau prenume al utilizatorului. Aplicația poate afișa această
valoare.
nume dat Nume de utilizator. Aplicația poate afișa această valoare.
eu la Eliberat la timp. Momentul în care JWT a fost emis. Timpul este reprezentat ca numărul
de secunde de la 1 ianuarie 1970 (1970 -01-01T0: 0: 0Z) UTC până la momentul emiterii jetonului.
iss Identifică emitentul de jetoane
NBF Nu mai devreme. Momentul în care tokenul devine eficient. Pentru ca tokenul să fie valabil,
data / ora curentă trebuie să f ie mai mare sau egală cu valoarea Nbf. Timpul este reprezentat ca
numărul de secunde de la 1 ianuarie 1970 (1970 -01-01T0: 0: 0Z) UTC până la momentul emiterii
jetonului.
OID Identificatorul de obiect (ID) al obiectului utilizator în Azure AD.
Sub Identific ator subiect. Acesta este un identificator persistent și imuabil pentru utilizatorul pe
care îl descrie tokenul. Utilizați această valoare în logica cache.
tid Agent de identificare (ID) al chiriașului Azure AD care a emis jetonul.
nume unic Un identificat or unic pentru acesta poate fi afișat utilizatorului. Acesta este, de
obicei, un nume principal al utilizatorului (UPN).
UPN Numele principal al utilizatorului al utilizatorului.
ver Versiune. Versiunea token -ului JWT, de obicei 1.0.

43
Răspuns la eroare
Erorile punctului final al emiterii token sunt coduri de eroare HTTP, deoarece clientul solicită
direct punctul final al emiterii token. Pe lângă codul de stare HTTP, documentul final Azure AD
pentru emiterea tokenului returnează și un document JSON cu obiect e care descriu eroarea.
Un exemplu de răspuns la eroare ar putea arăta astfel:
{ "error": "invalid_grant", "error_description": "AADSTS70002: Error validating credentials.
AADSTS70008: The provided authorization code or refresh token is expired. Send a new
interactive authorization request for this utilizator and resource. \r\nTrace ID: 3939d04c -d7ba –
42bf-9cb7 -1e5854cdce9e \r\nCorrelation ID: a8125194 -2dc8 -4078 -90ba –
7b6592a7f231 \r\nTimestamp: 2016 -04-11 18:00:12Z", "error_codes": [ 70002, 70008 ],
"timestamp ": "2016 -04-11 18:00:12Z", "trace_id": "3939d04c -d7ba -42bf-9cb7 -1e5854cdce9e",
"correlation_id": "a8125194 -2dc8 -4078 -90ba -7b6592a7f231" }
Parametru Descriere
eroare Un șir de cod de eroare care poate fi folosit pentru a clasifica tipurile de erori care ap ar și
poate fi folosit pentru a reacționa la erori.
ERROR_DESCRIPTION Un mesaj de eroare specific care poate ajuta un dezvoltator să
identifice cauza principală a unei erori de autentificare.
error_codes O listă a codurilor de eroare specifice STS care pot ajuta în diagnosticare.
timestamp -ul Momentul în care a apărut eroarea.
trace_id Un identificator unic pentru cererea care vă poate ajuta în diagnosticare.
correlation_id Un identificator unic pentru solicitare care poate ajuta la diagnosticarea între
componente.
Coduri de stare HTTP
Următorul tabel afișează codurile de stare HTTP care revin la punctul final al emiterii tokenului.
În unele cazuri, codul de eroare este suficient pentru a descrie răspunsul, dar dacă există erori,
trebuie să analizați docume ntul JSON însoțitor și să examinați codul său de eroare.

44
Cod HTTP Descriere
400 Codul HTTP implicit. Folosit în majoritatea cazurilor și se datorează de obicei unei cereri
deformate. Remediați și retrimiteți solicitarea.
401 Autentificare esuata. De exempl u, cererea lipsește parametrul client_secret.
403 Autorizatia a esuat. De exemplu, utilizatorul nu are permisiunea de a accesa resursa.
500 A apărut o eroare internă la serviciu. Reîncercați cererea.
Codurile de eroare pentru erorile punctului final pentru token
Cod de eroare Descriere Acțiunea clientului
cerere invalida Eroare de protocol, cum ar fi un parametru lipsă. Remediați și retrimiteți
solicitarea
invalid_grant Codul de autorizare este nevalid sau a expirat. Încercați o nouă solicitare
pentru /aut horize punctul final
unauthorized_client Clientul autentificat nu este autorizat să utilizeze acest tip de acordare a
autorizației. Acest lucru apare, de obicei, atunci când aplicația client nu este înregistrată în
Azure AD sau nu este adăugată la chiriașu l AD Azure al utilizatorului. Aplicația poate solicita
utilizatorului instrucțiuni pentru instalarea aplicației și adăugarea acesteia la Azure AD.
invalid_client Autentificarea clientului a eșuat. Acreditările clientului nu sunt valide. Pentru
a repara, ad ministratorul aplicației actualizează acreditările.
unsupported_grant_type Serverul de autorizare nu acceptă tipul de acordare a autorizației.
Modificați tipul de acordare în cerere. Acest tip de eroare ar trebui să apară numai în timpul
dezvoltării și să fie detectat în timpul testelor inițiale.
invalid_resource Resursa țintă nu este validă deoarece nu există, Azure AD nu o poate găsi
sau nu este configurată corect. Aceasta indică faptul că resursa, dacă există, nu a fost
configurată în chiriaș. Aplicația poate solicita utilizatorului instrucțiuni pentru instalarea aplicației
și adăugarea acesteia la Azure AD.

45
interaction_required Cererea necesită interacțiunea utilizatorului. De exemplu, este necesar un
pas suplimentar de autentificare. În loc de o solicit are non -interactivă, reîncercați cu o
solicitare de autorizare interactivă pentru aceeași resursă.
Temporar indisponibil Serverul este temporar prea ocupat pentru a face față cererii.
Reîncercați cererea. Aplicația client ar putea explica utilizatorului că răspunsul său este
întârziat din cauza unei condiții temporare.
Utilizați tokenul de acces pentru a accesa resursa
Acum, că ați achiziționat cu succes un access_token , puteți utiliza jetonul în cererile către API –
urile Web, prin includerea acestuia în a ntetul Authorization . Specificația RFC 6750 explică modul
de utilizare a jetoanelor purtătorilor în cererile HTTP pentru a accesa resursele protejate.
Cerere de mostra
GET /data HTTP/1.1 Host: service.contoso.com Authorization: Bearer
eyJ0eXAiOiJKV1QiLCJ hbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1THdqcHdBSk9
NOW4tQSJ9.eyJhdWQiOiJodHRwczovL.JZw8jC0gptZxVC –
7l5sFkdnJgP3_tRjeQEPgUn28XctVe3QqmheLZw7QVZDPCyGycDWBaqy7FLpSekET_BftDk
ewRhyHk9FW_KeEz0ch2c3i08NGNDbr6XYGVayNuSesYk5Aw_p3ICRlUV1bqEwk –
Jkzs9EEkQg4hbefqJS6 yS1HoV_2EsEhpd_wCQpxK89WPs3hLYZETRJtG5kvCCEOvSHXmD
E6eTHGTnEgsIk –
UlPe275Dvou4gEAwLofhLDQbMSjnlV5VLsjimNBVcSRFShoxmQwBJR_b2011Y5IuD6St5z
PnzruBbZYkGNurQK63TJPWmRd3mbJsGM0mf3CUQ
Răspuns la eroare
Resursele securizate care implementează RFC 6750 emite coduri de stare HTTP. Dacă cererea nu
include acreditările de autentificare sau lipsește tokenul, răspunsul include un antet WWW –
Authenticate . Când o solicitare nu reușește, serverul de resurse răspunde cu codul de stare HTTP
și un cod de eroare.

Următorul exem plu este un răspuns nereușit când solicitarea clientului nu include tokenul
purtătorului:

46
HTTP/1.1 401 Unauthorized WWW -Authenticate: Bearer
authorization_uri="https://login.microsoftonline.com/contoso.com/oauth2/authorize",
error="invalid_token", error_de scription="The access token is missing.",
Parametri de eroare
Parametru Descriere
authorization_uri URI (punct final fizic) al serverului de autorizare. Această valoare este, de
asemenea, utilizată ca o cheie de căutare pentru a obține mai multe informaț ii despre server dintr –
un punct final pentru descoperire.
Clientul trebuie să valideze că serverul de autorizare este de încredere. Atunci când resursa este
protejată de Azure AD, este suficient să se verifice dacă URL -ul începe cu
https://login.microsofto nline.com sau cu un alt nume de gazdă pe care îl susține Azure AD. O
resursă specifică locatarului ar trebui să returneze întotdeauna un URI de autorizare specific
locatarului.
eroare O valoare de cod de eroare definită în secțiunea 5.2 din cadrul de autor izare OAuth 2.0 .
ERROR_DESCRIPTION O descriere mai detaliată a erorii. Acest mesaj nu este destinat să fie
prietenos pentru utilizatorii finali.
RESOURCE_ID Returnează identificatorul unic al resursei. Aplicația client poate folosi acest
identificator ca valoare a parametrului de resource atunci când solicită un token pentru resursă.
Este important ca aplicația clientului să verifice această valoare, în caz contrar un serviciu rău
intenționat ar putea să inducă un atac de elevare a privilegiilor
Strategia recomandată pentru prevenirea unui atac este să se verifice faptul că resource_id
potrivește cu baza URL -ului API web accesat. De exemplu, dacă se accesează
https://service.contoso.com/data , resursa_id poate fi htttps: //service.contoso.com/. Aplicația
client trebuie să respingă un resource_id care nu începe cu adresa URL de bază decât dacă există
o metodă alternativă sigură de verificare a id -ului.
Codurile de eroare ale schemelor de purtare

47
Specificația RFC 6750 definește următoarele erori pentru resurs ele care utilizează antetul WWW –
Authenticate și Schema purtătorului în răspuns.
Codul de stare HTTP Cod de eroare Descriere Acțiunea clientului
400 cerere invalida Cererea nu este bine formată. De exemplu, s -ar putea să lipsească un
parametru sau să se uti lizeze de două ori același parametru. Remediați eroarea și reîncercați
cererea. Acest tip de eroare ar trebui să apară numai în timpul dezvoltării și va fi detectat în timpul
testelor inițiale.
401 Simbol Invalid Indicele de acces lipsește, nu este valid s au este revocat. Valoarea
parametrului error_description furnizează detalii suplimentare. Solicitați un nou jeton de la
serverul de autorizare. Dacă noul jeton nu reușește, a apărut o eroare neașteptată. Trimiteți un
mesaj de eroare utilizatorului și încer cați din nou după întârzieri aleatorii.
403 insufficient_scope Indicele de acces nu conține permisiunile de confesiune necesare
pentru a accesa resursa. Trimiteți o nouă solicitare de autorizare către punctul final de
autorizare. Dacă răspunsul conține par ametrul de domeniu, utilizați valoarea de destinație din
solicitare la resursă.
403 insufficient_access Subiectul simbolului nu are permisiunile necesare pentru a accesa
resursa. Solicitați utilizatorului să utilizeze un alt cont sau să solicite permisiuni pentru
resursa specificată.
Reîmprospătarea jetoanelor de acces
Token -urile de acces sunt de scurtă durată și trebuie să fie actualizate după expirarea acestora
pentru a continua accesarea resurselor. Puteți reîmprospăta access_token prin trimiterea unei alte
cereri POST către punctul final /token , dar de această dată furnizând refresh_token în locul
codului.
Jetoanele de reîmprospătare nu au o anumită durată de viață. În mod obișnuit, durata de viață a
jetoanelor de reîmprospătare este relativ lungă. Cu toate acestea, în unele cazuri, jetoanele de
reîmprospătare expiră, sunt revocate sau nu au suficiente privilegii pentru acțiunea dorită.
Aplicația dvs. trebuie să aștepte și să gestioneze corect erorile returnate de sfârșitul emisiunii token.

48
Când primiț i un răspuns cu o eroare de jet de reîmprospătare, renunțați la jetonul actual de
actualizare și solicitați un nou cod de autorizare sau un simbol de acces. În special, când utilizați
un jeton de refresh în fluxul de acordare a codului de autorizare, dacă primiți un răspuns cu codurile
de eroare interaction_required sau invalid_grant , aruncați jetonul de reîmprospătare și solicitați
un nou cod de autorizare.
O solicitare de eșantion la obiectivul final al locatarului (puteți utiliza, de asemenea, punctul f inal
comun ) pentru a obține un nou simbol de acces utilizând un jet de reîmprospătare arată astfel:
// Line breaks for legibility only POST /{tenant}/oauth2/token HTTP/1.1 Host:
https://login.microsoftonline.com Content -Type: application/x -www -form -urlenc oded
client_id=6731de76 -14a6 -49ae -97bc -6eba6914391e
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq..
. &grant_type=refresh_token &resource=https%3A%2F%2Fservice.contoso.com%2F
&client_secret=JqQX2PNo9bpM0uEihUPzyrh // NOTE: Only requir ed for web apps
Răspunsul reușit
Un răspuns cu jetoane de succes va arata astfel:
{ "token_type": "Bearer", "expires_in": "3600", "expires_on": "1460404526", "resource":
"https://service.contoso.com/", "access_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiI sIng1dCI6Ik5HVEZ2ZEstZnl0aEV1THdqcHdBSk
9NOW4tQSJ9.eyJhdWQiOiJodHRwczovL.JZw8jC0gptZxVC –
7l5sFkdnJgP3_tRjeQEPgUn28XctVe3QqmheLZw7QVZDPCyGycDWBaqy7FLpSekET_BftDk
ewRhyHk9FW_KeEz0ch2c3i08NGNDbr6XYGVayNuSesYk5Aw_p3ICRlUV1bqEwk –
Jkzs9EEkQg4hbefqJS6yS1HoV_2EsEhpd_w CQpxK89WPs3hLYZETRJtG5kvCCEOvSHXmD
E6eTHGTnEgsIk –
UlPe275Dvou4gEAwLofhLDQbMSjnlV5VLsjimNBVcSRFShoxmQwBJR_b2011Y5IuD6St5z
PnzruBbZYkGNurQK63TJPWmRd3mbJsGM0mf3CUQ", "refresh_token": "AwABAAAAv
YNqmf9SoAylD1PycGCB90xzZeEDg6oBzOIPfYsbDWNf621pKo2Q3GGTHYlmNfwoc –
OlrxK69hkha2CF12azM_NYhgO668yfcUl4VBbiSHZyd1NVZG5QTIOcbObu3qnLutbpadZGA
xqjIbMkQ2bQS09fTrjMBtDE3D6kSMIodpCecoANon9b0LATkpitimVCrl
PM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4rTfgV29ghDOHRc2B –

49
C_hHeJaJICqjZ3mY2b_YNqmf9SoAylD1PycGCB90xzZeEDg6oBzOIPfYsbDWNf621pKo2Q3
GGTHYlm Nfwoc -OlrxK69hkha2CF12azM_NYhgO668yfmVCrl -NyfN3oyG4ZCWu18M9 –
vEou4Sq -1oMDzExgAf61noxzkNiaTecM -Ve5cq6wHqYQjfV9DOz4lbceuYCAA" }
Parametru Descriere
token_type Tipul de jeton. Singura valoare acceptată este purtătorul .
expira in Durata de viață rămasă a jeto nului în câteva secunde. O valoare tipică este 3600 (o
oră).
expira la Data și ora la care expiră tokenul. Data este reprezentată ca numărul de secunde de
la 1970 -01-01T0: 0: 0Z UTC până la ora de expirare.
resursă Identifică resursa securizată pe care poa te fi utilizată tokenul de acces pentru acces.
domeniu Permisiunile de impersonare acordate aplicației client native. Permisiunea implicită
este utilizator _impersonation . Proprietarul resursei țintă poate înregistra valori alternative în
Azure AD.
jeton de acces Noul simbol de acces solicitat.
refresh_token Un nou OAuth 2.0 refresh_token care poate fi folosit pentru a solicita token -uri de
acces noi când expiră cel din răspuns.
Răspuns la eroare
Un exemplu de răspuns la eroare ar putea arăta astfel:
{ "e rror": "invalid_resource", "error_description": "AADSTS50001: The application named
https://foo.microsoft.com/mail.read was not found in the tenant named 295e01fc -0c56 -4ac3 -ac57 –
5d0ed568f872. This can happen if the application has not been installed by the administrator of
the tenant or consented to by any utilizator in the tenant. You might have sent your authentication
request to the wrong tenant. \r\nTrace ID: ef1f89f6 -a14f-49de -9868 -61bd4072f0a9 \r\nCorrelation
ID: b6908274 -2c58 -4e91 -aea9-1f6b9c99347c \r\nTimestamp: 2016 -04-11 18:59:01Z",
"error_codes": [ 50001 ], "timestamp": "2016 -04-11 18:59:01Z", "trace_id": "ef1f89f6 -a14f-49de –
9868 -61bd4072f0a9", "correlation_id": "b6908274 -2c58 -4e91 -aea9-1f6b9c99347c" }
Parametru Descriere

50
eroare Un șir de cod de ero are care poate fi folosit pentru a clasifica tipurile de erori care apar și
poate fi folosit pentru a reacționa la erori.
ERROR_DESCRIPTION Un mesaj de eroare specific care poate ajuta un dezvoltator să
identifice cauza principală a unei erori de autentifi care.
error_codes O listă a codurilor de eroare specifice STS care pot ajuta în diagnosticare.
timestamp -ul Momentul în care a apărut eroarea.
trace_id Un identificator unic pentru cererea care vă poate ajuta în diagnosticare.
correlation_id Un identificat or unic pentru solicitare care poate ajuta la diagnosticarea între
componente.
Pentru o descriere a codurilor de eroare și a acțiunii client recomandate, consultați codurile de
eroare pentru erorile punctului final pentru token .

4. Laborator Hybrid (integra re oricărui aplicații cu autentificare prin Azure folosind
utilizator i sincronizați din on -prem)

Înainte de a începe sa prezentam conceptele de baza la care vrem sa ajungem
Modelul Lab oratorului

51

Autentificare în cadrul modelului
Autentificare utiliz ator pentru a accesa o aplicație

52

Autentificare utilizator pentru a accesa Office 365

Identitatea hibridă

53
Ce este identitatea hibridă? Termenul este utilizat de obicei pentru a descrie îmbinarea a doi
furnizori de identitate într -un amestec omogen de autentificare. Când cuplăm Azure Active
Directory cu Windows Server Active Directory, folosim pe deplin îmbunătățirile în Windows 10,
precum și pentru a permite altor funcții care se bazează pe cloud, cum ar fi Enterprise State
Roaming și Single Sign on p e Azure resources cloud. Identitatea hibridă este, de asemenea, un
element de construcție pentru Windows Hello for Business, acreditările Microsoft cheie sau
certificatele de generație următoare. Windows Hello for Business elimină nevoia de schimburi
tradiționale de nume de utilizatori și parole de acreditare, care pot fi vulnerabile la diferite forme
de atac, de la forța bruta, omul în mijloc și scenariile Pass the Hash.

Există mai mulți pași necesari înainte de a începe să construim laboratorul nostru, i nclusiv un
abonament Azure, un domeniu înregistrat pe Internet și un certificat SSL pentru domeniul dvs. de
Internet.
Dupa ce avem toate aceste prerechizite putem continua cu construire laboratorului.
Creați un Azure AD Domain
Deschideti https://portal.az ure.com și selectați + New. În căutarea în Marketplace, tastați Azure
Active Directory și faceți clic pe Azure Active Directory în caseta derulantă pentru a începe
instalarea.

54

Selectați Creați -o pentru a începe procesul. În pagina Creare director, adăuga ți un nume care vă va
ajuta să îl identificați în abonament, un nume de domeniu unic care va fi prefixat cu
.onmicrosoft.com, țara sau regiunea dvs. și apoi selectați marcajul de verificare k pentru a crea
directorul. Folosind exemplul din imaginea următoa re, alegeți: Un nume organizațional pentru
directorul dvs. Acest lucru poate fi orice vă place și este util pentru a vă ajuta să vă identificați
directorul dintr -o privire în Portalul Azure. În exemplul nostru, vom folosi FQDN (domeniul de
Internet) și o e tichetă ușor de identificat, adică paulhut.xyz (Hybrid Lab Demo). Un nume de
domeniu actual, unic, care va fi prefixat la .onmicrosoft.com. Acest lucru trebuie să fie unic și
expertul nu va trece peste acest punct până când unicitatea nu este verificată în timpul expertului
de instalare. Acesta nu este numele de domeniu solicitat în Registru o secțiune de domeniu mai
devreme. Acesta va fi folosit în următoarea secțiune atunci când vom crea un Admin Global. În
exemplul de mai jos, este paulhut9, făcând chiri așul nostru Azure paulhut9.onmicrosoft.com. O
țară sau regiune care reflectă zona proprie. Multe caracteristici Azure sunt limitate la anumite
regiuni. Cu toate acestea, în acest scenariu, cele mai bune practici ar fi să alegeți țara sau regiunea
cea mai a propiată de dvs. În exemplul de mai jos, am ales Statele Unite. Selectați CREATE pentru

55
a crea Azure Active Directory și permiteți aproximativ un minut pentru finalizarea procesului.
Crearea exemplului directorului

Este nevoie de aproximativ un minut pen tru a crea. După ce ați terminat, selectați Faceți clic aici
pentru a vă gestiona noul director
Adăugați FQDN achiziționat în Azure AD Domain. Continuați cu adăugarea domeniului nostru de
Internet care a fost înregistrat mai devreme și apoi verificați prop rietatea. În pagina de gestionare
Active Directory selectați Domain names, apoi selectați + Add domain name . Adăugarea unui
domeniu suplimentar . Dialogul Add domain începe. Introduceți noul FQDN achiziționat în
secțiunea Nume domeniu și selectați Adăugați domeniu. Pentru a utiliza FQDN, trebuie să
satisfaceți proprietatea asupra domeniului prin adăugarea unei înregistrări unice în înregistrările
DNS ale domeniului. Înregistrările sunt afișate ca exemplul din următoarea imagine: Verificați
domeniul utilizând înregistrări unice Notă: Avem opțiunea de a utiliza fie înregistrări TXT, fie
MX. În circumstanțele noastre, înregistrările TXT sunt preferabile.

56

Creați un cont global de administrator . Pentru a gestiona domeniul și alte elemente cum ar fi Office
365 și Intune vom dori pentru a crea un cont de administrare global pentru a face munca
administrativă.
Pentru a crea un cont de Administrator Global, selectați directorul dvs. Azure, selectați Utilizatorii
și grupurile din zona de administrare a meniului, selec tați Toți utilizatorii, apoi selectați +
Utilizator nou. Alegeți un nume de utilizator pe care îl veți aminti. Se deschide fereastra de dialog
Utilizator nou. Introduceți numele, numele de utilizator și apoi selectați Rolul directorului.
Selectați Administ ratorul global în bara Rolă Directory și apoi selectați OK pentru a accepta
alegerea dvs. Crearea unui cont de administrator global După ce faceți clic pe OK pe panoul Rolă
director, veți fi returnați în panoul utilizatorului . Alegeți caseta Show Password și copiați parola
temporară pentru noul administrator global. Faceți o notă a parolei pentru a fi utilizată într -o etapă
ulterioară. Click CREATE pentru a crea contul global de administrare. Acest lucru încheie
procesul de creare a unui administrator glob al în Azure AD

57

Începeți o încercare gratuită: Enterprise Mobility Suite si asignați licența obținuta contului de cont
de Administrator Global.
4.1.Pregătirea infrastructurii Azure
Această secțiune detaliază pașii necesari pentru crearea infrastructurii adecv ate în Azure
Infrastructure as a Service (IaaS.) Vom folosi Storage and Networks ca parte a acestui proces.
Există multe modalități de a construi IaaS și este imposibil să acoperiți fiecare variantă din acest
document, dar urmând acești pași va fi cel mai rapid mod de a construi laboratorul pentru cei care
nu ar putea fi familiarizați cu Azure IaaS.
Create o rețea virtuală
Aceste pași permit să creați o rețea pentru infrastructura locală care va fi găzduită în Azure
Infrastructure as a Service (IaaS). Prin configurarea unei rețele și adăugarea tuturor VM -urilor la
aceasta, ne asigurăm că pot comunica între ele și pot utiliza aceleași intrări ale serverului DNS.
Conectați -vă la http://portal.azure.com utilizând contul de administrator al serviciului.

58
Select ați rețelele virtuale, apoi + Adăugați pentru a începe. Introduceți un nume unic pentru rețeaua
virtuală. Spațiul adresei verificați dacă adresa este 10.2.0.0/24. Dacă nu, vă rugăm să corectați.
Selectați Creare nou pentru grupul de resurse și alegeți un n ume unic pentru grupul dvs. de resurse.
În locația Locație, alegeți o locație în regiunea geografică. Acceptați valorile implicite pentru
celelalte câmpuri și selectați CREATE. Notă: Ce este un grup de resurse? Un grup de resurse este
un container care deț ine resursele asociate pentru o soluție Azure. Grupul de resurse poate include
toate resursele pentru soluție sau numai acele resurse pe care doriți să le gestionați ca grup. Dvs.
decideți cum doriți să alocați resurse grupurilor de resurse bazându -vă pe c eea ce face cel mai mult
sens pentru organizația dvs.

După actualizarea paginii, selectați noua rețea virtuală pentru a afișa pagina de setări pentru rețeaua
virtuală.
Creați rețea: Adăugați serverul DNS
Selectați servere DNS.

59
Alegeți personalizat.
Selec tați Adăugați server DNS și introduceți adresa IP 10.2.0.4 în câmpul Add server DNS. Faceți
clic pe SAVE pentru a finaliza procesul.
Creați rețea: Adăugați serverul DNS
Notă: De ce trebuie să schimbăm serverul DNS implicit în rețeaua noastră Azure? Trebui e să
putem localiza controlerul de domeniu Windows Server Active Directory, de aceea.

Creați primul VM
Scenariile de identitate hibride necesită un domeniu Active Directory, precum și un domeniu AD
Azure. Această secțiune trece prin crearea infrastructur ii domeniului Active Directory și
configurarea setărilor de rețea. Vom crea un total de patru servere pentru acest laborator, care să
permită spațiu de expansiune mai târziu.
Conectați -vă la http://portal.azure.com utilizând contul de administrator al ser viciului.

60

Selectați + New, Computer și Windows Server 2016 Datacenter pentru a începe.

Din moment ce acesta va fi primul VM și va fi controllerul de domeniu (DC), alegeți un nume care
să indice un DC.
Introduceți o parolă locală și confirmați -o. Acest a este modul în care veți accesa VM -ul.
Asigurați -vă că ați selectat abonamentul corect dacă aveți mai mult de unul.
Selectați Utilizare existentă pentru grupul de resurse și alegeți grupul de resurse creat mai devreme.
Verificați dacă locația este corect ă. Ar trebui să fie același lucru cu grupul de resurse, rețeaua
virtuală și grupul de stocare.

61
Acceptă implicit pentru întrebarea de acordare a licenței și apoi selectați OK pentru a continua.
Alegeți o lamă de dimensiune se deschide. Selectați Vizualizare toate pentru a continua, permițând
încărcarea paginii, apoi derulați până la partea de jos.
Alegerea unui VM din seria A este cel mai rentabil. Alege A1 Basic sau ce îți va permite bugetul.
După ce selectați A1 Basic, selectați SELECT pentru a continua.
Pagina Setări are setări opționale care pot fi configurate. Vom lăsa pe acestea ca implicit și selectați
OK pentru a continua.
Creați primul VM Ecranul final este pagina Achiziție. Aici confirmați configurația VM și costul
asociat acestuia. Când sunteți mul țumit de setările VM, faceți clic pe CUMPĂRAT pentru a crea
VM. Creați primul VM Previziunea VM începe și se va desfășura timp de câteva minute. Așteptați
ca VM să se finalizeze și apoi să ieșiți din portal sau să treceți la pasul următor si anume crearea
următoarelor mașini virtuale necesare ( ADFS1, WAP1, SYNC1 ).

62
Creați un controler de domeniu în rolurile de servicii DC1
Deschideți pe DC1 folosind managerul de server . În Managerul de Server, faceți clic pe Gestionare
și faceți clic pe Adăugați roluri și caracteristici pentru a porni Expertul Adăugare roluri. Pe pagina
Înainte de a începe, faceți clic pe Următorul. În pagina Selectați tipul de instalare, faceți clic pe
Instalare pe bază de roluri sau pe bază de caracteristici, apoi pe Următorul. În pagina Selectați
serverul de destinație, faceți clic pe Selectați un server din poolul de servere, faceți clic pe numele
serverului în care doriți să instalați AD DS și apoi pe Următorul. Pe pagina Roluri server selectați
Active Directory Domain Services, apoi p e Adăugați caseta de dialog Expert roluri și caracteristici,
faceți clic pe Adăugați caracteristici, apoi faceți clic pe Următorul. În pagina Selectați
caracteristici, acceptați valorile implicite și faceți clic pe Următorul. Pe pagina Servicii Active
Directory Domain, revizuiți informațiile și apoi faceți clic pe Următorul. Pe pagina Confirmați
selecțiile de instalare, faceți clic pe Instalare. Configurați serviciile de domeniu din DC1 În pagina
Rezultate, verificați dacă instalarea a reușit și faceți clic pe Promovarea acestui server la un
controler de domeniu pentru a porni Expertul de configurare a serviciilor de domeniu Active
Directory. Configurează serviciile de domeniu: : Dacă închideți Expertul de adăugare a rolurilor
în acest moment fără a porni Ex pertul de configurare a serviciilor de domeniu Active Directory, îl
puteți reporni făcând clic pe Activități din Managerul de server. Căutați triunghiul galben din
partea superioară a Server Manager . Utilizați numele corp.YOURDOMAIN.com și faceți clic pe
NEXT. Furnizați parola Modului de restaurare a adreselor (DSRM) și faceți clic pe NEXT.
Acceptați valorile prestabilite pentru opțiunile DNS și faceți clic pe NEXT. Accept implicite sub
Opțiuni suplimentare și faceți clic pe NEXT. Accept implicite sub Căi ș i faceți clic pe Opțiuni
NEXT. Revizuiți și faceți clic pe NEXT. Odată cerințele prealabile verifica te si selectați
INSTALL. Mașina va reporni, la finalizarea. Înscrieți -vă pe utilizarea CORP \ username, în cazul
în care numele de utilizator este contul l ocal utilizat anterior pentru a vă conecta la aparatul din
secțiunea anterioară.
După ce DC1 este promovat la un controler de domeniu, este timpul să adăugați restul serverelor
în domeniul Active Directory creat pe el. Acum, când toate mașinile sunt conec tate la domeniul
Active Directory, asigurați -vă că utilizați contul Administratorului de domeniu, mai degrabă decât
contul de administrator local.

63
4.2.Instala re Azure AD Connect și configurare AD FS și Web Application Proxy
Azure AD Connect va fi folosit pent ru a permite sincronizarea utilizatorilor din domeniului nostru
Active Directory către directorul nostru Azure Active Directory. Acest lucru se realizează prin
programul de configurare, pe care îl vom folosi, de asemenea, pentru a instala și configura serv erul
de Proxy Web Application și serverul AD FS. Urmați acești pași pentru a începe: conectați -vă la
serverul SYNC1 utilizând acreditările administratorului domeniului dvs. Mai târziu, am exportat
un certificat în Exportul certificatului dvs. de tip "wildc ard" pentru a fi utilizat ulterior în
laboratorul dvs. Copiați fișierul PFX pe desktopul serverului SYNC1. Descărcați fișierul Microsoft
Azure Active Directory. Faceți dublu clic pe pachetul MSI pentru a începe instalarea și acceptați
termenii licenței. Fa ceți clic pe Continuați. Faceți clic pe Particularizare și apoi pe Continuați. În
ecranul următor, este intitulat instalare Componente cerute , acceptați setările implicite și selectați
Install. Acest lucru va dura câteva minute, instalând componentele nece sare. Pentru conectarea
utilizatorului, selectați Federation with AD FS. Faceți clic pe Next. utilizați contul Global Admin
(GA) creat mai devreme. Faceți clic pe Next. În pagina Connect your directories, selectați Add
Directory. Selectați Creare cont nou AD, apoi introduceți numele de utilizator pentru Admin.
Selectați OK pentru a continua. După pasul anterior, veți vedea directorul configurat cu numele
Active Directory marcat cu verificare verde. Selectați NEXT pentru a continua. Pe pagina de
configurare a conectării AD Azure asigurați -vă că UPN adăugat mai devreme este afișat ca Suffix
Active Directory UPN. Acceptă implicit pentru Selectați atributul local utilizat ca numele de
utilizator Azure AD care ar trebui să fie User PrincipalName și selectați NEXT . Acceptați setările
implicite pentru filtrarea domeniilor și OU, Identificați unic utilizatorii, Filtrați utilizatorii și
dispozitivele și opțiunile opționale, dând clic pe Următorul pe fiecare pagină. În pagina de
acreditare a administratorului domeniulu i, introduceți -vă acreditările administratorului
domeniului. Selectați NEXT pentru a continua.
Acum ajungem la configurația AD FS Farm. Faceți clic pe Configurați o nouă fermă AD FS și
răsfoiți certificatul copiat pe desktop mai devreme. Furnizați parola certificatului, apoi faceți clic
pe OK. În meniul derulant Nume subiect selectați numele subiectului * .contoso.com. Aceasta va
deschide caseta Prefix nume de subiect. Introduceți adfs în secțiunea Prefix nume subiect. Valoarea
numele serviciului Federație este similar cu adfs.contoso.com. Selectați NEXT pentru a continua.
Pe pagina servere AD FS introduceți numele de gazdă al serverului dvs. ADFS: ADFS1. De

64
asemenea, puteți naviga la el. Selectați OK pentru a alege și a verifica conectivitatea. Selectați
NEXT după verificarea conectivității. În pagina Servere Proxy Web Application, căutați serverul
Proxy Application Web în același mod. Se numește WAP1. Într-o dată, odată ce conectivitatea
este verificată, selectați NEXT pentru a continua. Avem nevoie de un cont de serviciu pentru ca
serviciul ADFS să ruleze sub. Selectați implicit, Creați un cont de administrare a grupului de
servicii și introduceți acreditările Enterprise Admin. Selectați NEXT pentru a continua. Utilizați
meniul derulant din ecranul Azure AD Domain pentru a selecta domeniul. Selectați NEXT pentru
a continua. Consultați prezentarea generală a procesului de instalare și selectați INSTALL pentru
a începe procesul. Revedeți această pagină înainte de a continua. Odată examinat, începeți pașii de
verificare selectând NEXT. Odată verificată, veți primi o pagină de confirmare. După examinarea
confirmării, selectați EXIT pentru a finaliza instalarea.
4.3. Configurarea si Testarea autentificării in aplicații
Pașii rămași sunt pentru crearea unor utilizat ori de testare, care să le permită să se sincronizeze și
să testeze autentificarea. Creați utilizatorii de testare în Active Directory conectându -vă la
controlerul de domeniu DC1 utilizând contul dvs. de administrator al domeniului. Utilizatorii și
compute rele Active Directory, făcând clic pe Start> Instrumente de administrare> Utilizatori
Active Directory și computere. Creați următorii utilizatori de test, asigurându -vă că selectați noul
sufix UPN introdus în secțiunea Crearea unui Suffix de suplinire UPN în Active Directory.
După ce s -a executat următorul proces de sincronizare Azure AD Connect, utilizatorii creați vor
apărea în Azure AD, proveniți din Active Directory Local. Ciclul standard de sincronizare este o
dată la fiecare 30 de minute.

65
Adăugați licența de Office si EMS la utilizatorului dorit.

Acum se poate merge in Enterprise Applications si adăuga aplicația dorita. Una din cele 3000 de
aplicații din galerie, o alta aplicație web construita de noi pe un serviciu de AppService sau o alta
aplic ație din on -prem folosind un AppProxy.
Vom adaugă pentru test aplicația SAP din galerie si aplicația lt care reprezintă serviciul de
AppService unde putem găzdui ce aplicație dorim.

66
După intram pe configurarea aplicației si adăugam utilizatorului de te st in User s and groups la
ambele aplicații .

La final deschidem o sesiune noua incognito către http://myapps.microsoft.com si introducem
utilizatorului de test:

Deoarece domeniul nostru este federat v -om fi redirecționați prin serverul de WAP către serverul
de ADFS unde trebuie sa introducem parola. Severul de ADFS verifica la rândul lui credenț ialele
printr -un tiket Kerberos la contr olerul nostru de domeniu DC1.

67

Dupa verificarea credenț ialelor primim un token valid si suntem redirecționați la pagin a dorita
inițial unde putem vedea toate aplicațiile disponibile acestui utilizator ( cele incluse in pachetul de
Office si cel 2 adăugate de noi). Din momentul in care utilizator ul are un token valid va benefici a
de logare automata pe oricare din aplicați ile dorite. Daca va accesa spre exemplu aplicația de test
lt va fi logat automat la servi ciul de APPService care poate găzduii oricare din aplicațiile web
construite de noi.

68
Bibliografie :

Micros oft Documents :
https ://docs.microsoft.com/en -us/
Cloud identity and access management :
https://azure.microsoft.com/en -us/resources/infographics/cloud -identity -and-access/