TITLU: ______ DRUMUL CATRE CLOUD _______________________________________ [625250]

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 LUCRĂRII DE LICENȚĂ/DISERTAȚIE
TITLU: ______ DRUMUL CATRE CLOUD _______________________________________
___________________________________________________________________________
ABSOLVENT/ MASTERAND: ________ OVIDIU MARIAN BEN _____________
PROFESOR COORDONATOR: ___Conf.univ.dr.ing. IUSTIN 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 specialitate 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 INFORMATICĂ

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

TITLU: DRUMUL CATRE CLOUD
ABSOLVENT/ MASTERAND: [anonimizat]: Conf.univ.dr.ing. IUSTIN 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
protocoale 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 înscr ie 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 DEFINIRE ………………………….. ………………………….. ………………………….. ………………………….. ……………………. 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 TURII 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 mare 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 atuurile pe care
acest lucru le poate aduce lic enț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 discuta ș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.
Platfo rma 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 business sa stocheze datele oriunde pe glob, permit e 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 p rin 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ă f aceț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 es te 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.
Recomandarea 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.
Sincro nizare – 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 implementă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 conectate ș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 (C D).
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ătoare a 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 domeniul 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ările 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 atributele 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 obiectele
utilizator din Active Director y 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 containerele
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 constă din două spații de nume care stoch ează
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 date 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 pent ru 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 d e 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 sin cronizare 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 primi t î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 conectorului. 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 vizualizare globală și integrată a tutu ror 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 sincronizare.
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ări ale fiecărui obiect din sursa de dat e
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ă integritatea 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 identit ate î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 g lobal (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 identifică în mod unic un
obiect din surs a 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ă d e 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 utilizează

8
atributul objectGUID pentru o anco ră. 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 multe atribute unice ale unui tip de ob iect, 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 ob iectelor 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 indi că 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 obiec t 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ă.

Motorul 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 export nu există
încă în sursa de date c onectată. 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 ancorare 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 i mport 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 acestea,
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ăstrarea ierarhiei.
Fiecare substituent rep rezintă 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 golurile 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 manager 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 agregată pe care motorul de sincronizar e 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 conectate 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 sp aț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 obiectele 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 obiec t 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 responsabili
pentru importul și exportul de da te 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 sunt utilizate pentru a sincroniza valo rile 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 obiectul metaverse. Fluxul atributului este b idirecț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
acestea, 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 persistentă și poate fi
eliminată numai de reg ulile 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 obiect de staționare ca obiect separat în s paț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 regulil e 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 este un
obiect în comun.
Sincronizați p rocesul 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ății 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 stad ializare 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 actualizează 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șteptare.
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. Motor ul 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ă este 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 de 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 procesează
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 sp ecificat î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 conectorilor ș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 obiect de staționare corespunzător c u 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 conectorului nu are ancora, atunci motorul d e 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ă obiectul aflat în spațiul conectoru lui 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 obiectul
specificat în Conector, aces ta 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 e ste 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 tipuri 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ător î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 obiecte 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 obie ct 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 lucru 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țiul 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 metaverse vizualizarea integ rată 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 sincronizare la ieșire actualizea ză 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 procesa informațiile de
ident itate î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 leagă 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 atributulu i 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 import care sunt obiec te 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 stabi leș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 procesul de furnizare cr eează 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 sincron izare 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 atribut ului 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 obiect metaverse se sc himbă,
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 obie ctelor 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 exp ort.
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 provizionarea 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
Redenumiți un obiect în c omun.
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 legat obiectul meta verse 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 declanșată. Procesu l 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 sincronizare 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 pe rsistentă 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 conectată ar putea schimb a 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
Motorul 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 sinc ronizare 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 cele 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 sursă
de date conec tată, 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 securitate in infrastruc turi 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, eventual, 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ți e 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 bazate 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 atunci 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ționalităț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 ri scul 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, em ail, 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 riscurilor cu auten tificare 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 p entru 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 din
extranet protej ate 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 angaja la locul de mu ncă 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 munc ă 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 organi zaț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 autentific ă
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 aplica ț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 L ockout, 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 AD 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, un de 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 automa tă 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 com paniei, 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ționa l 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 problemelo r 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 Connect 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 id entitate. 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ă despre 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 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 Î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 cont ează 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 adres a 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 s pecifică 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 pag ina de 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ă ef ectueze 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 fragmentului 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_meth ods_supported": [ "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 utilizatorul
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 .
Paramet rul id_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=6731de7 6-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 c alea 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
independent e 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 localizaț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, trebuie 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 po ate fi folosit
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 pent ru formularul
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 mod ul de răspuns_, 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 împiedic a atacurile 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 est e 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 Co ntent -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
utilizato rului ș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 es te, 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.
Răspuns la eroare
De asemenea, răspunsurile de eroare p ot fi trimise 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+authent ication
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.
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 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 utilizato rului
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
unsu pported_response_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ș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 ocu pat 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.
Validați id_token
Doar primirea unui 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 criptogra fia 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 validat 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 / or ganizaț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 înce pe 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ă înche iaț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.c om/common/oauth2/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, ut ilizatorul primeș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. P uteți seta LogoutUrl 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 aplicaț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 serv iciu web în
numele acelui utilizator utilizând OAuth. Acest scenariu combină OpenID Connect pentru
autentificarea utilizatorilor, în timp ce achiziționează simultan un cod de authorization_code care
poate fi folosit pentru a obține access_tokens folosind f luxul 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 breaks for legibility only GET
https://login.microsoftonline.com/{tenant}/oauth2/authoriz e? client_id=6731de76 -14a6 -49ae –
97bc -6eba6914391e // Your registered Application Id &response_type=id_token+code
&redirect_uri=http%3A%2F%2Flocalhost%3a12345 // Your registered 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 includerea 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 retu rnează aplicaț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= eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB…&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
utilizatorului ș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, expiră 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 asemenea, 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_descriptio n=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 spe cific 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ținut 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, pu teț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 OAuth 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 primi re a mesajelor 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 Î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 apl icaț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 specifică 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 de aplicație.
Pentru a găsi aplicația dvs. în portalul Azure, faceți clic pe Înscrierile aplicațiilor , apoi pe
Vizua lizați toate 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 /autho rize punctul 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 Azu re.
// Line 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%2 Fservice.contoso.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, 8eaef0 23-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 clic 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 di n 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. Pentru apli caț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
valoar e unică generată 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ă loc, 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 cl ic 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 A zure în cadrul 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ă selecteze 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 actualizat. 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 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 reau tentif icării, după ce
au extras deja numele de ut ilizator dintr -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 c odificatorului
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 inf ormații, consultaț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 . Pentr u mai multe 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ă opț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=
AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrqqf_ZT_p5uEAEJJ
_nZ3UmphWygRNy2C3jJ239gV_DBnZ2syeg95Ki -374WHUP -i3yIhv5i –
7KU2CEoPXwURQp6IVYMw –
DjAOzn7C3JCu5wpngXmbZKtJdWmiBzHpcO2aICJPu1KvJrDLDP20chJBXzVYJtkfjviLNNW
7l7Y3ydcHDsBRKZc3GuMQanmcghXPyoDg41g8XbwPud Vh7uCmUponBQpIhbuffFP_tbV8S
NzsPoFz9CLpBCZagJVXeqWoYMPe2dSsPiLO9Alf_YIe5zpi –

36
zY4C3aLw5g9at35eZTfNd0gBRpR5ojkMIcZZ6IgAA&session_state=7B29111D -C220 -4263 –
99AB -6F6E135D75EF&state=D79E5777 -702E -4260 -9A62 -37F75FF22CCE
Parametru Descriere
admin_consent Valoarea es te Adevărată dacă 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 valoa re unică care identifică 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 clien tului.
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 erori i. 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).
Codurile 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 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 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 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.
unsupported_response_type Serverul de autorizare nu accep tă 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șteptată. Reîncercați cererea. Aceste
erori p ot 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. Ap licaț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ă fapt ul 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ân d ați obținut un 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=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBr qqf_ZT_p5
uEAEJJ_nZ3UmphWygRNy2C3jJ239gV_DBnZ2syeg95Ki -374WHUP -i3yIhv5i –
7KU2CEoPXwURQp6IVYMw –
DjAOzn7C3JCu5wpngXmbZKtJdWmiBzHpcO2aICJPu1KvJrDLDP20chJBXzVYJtkfjviLNNW
7l7Y3ydcHDsBRKZc3GuMQanmcghXPyoDg41g8XbwPudVh7uCmUponBQpIhbuffFP_tbV8S
NzsPoFz9CLpBCZagJVXeqWo YMPe2dSsPiLO9Alf_YIe5zpi –
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 sa u 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. ID -ul aplicației este afișat în setările înregistrării aplicației.
grant_type necesar Trebuie 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ă pentr u 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 public), 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 pa rtea 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, 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ă, pla sați-o în
cererea de autorizare 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 verif icator de cod care a fost 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 Directory , 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 apelu rile
de rețea din aplicaț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 pa rametrilor expires_on sau 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 s ub 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 ar putea arăta astfel:
{ "access_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1THdqcHdBSk
9NOW4tQSJ9.eyJhdWQiOiJodHRwczovL.JZw8jC0gptZxVC –
7l5sFkdnJgP3_tRjeQEPgUn28XctVe3QqmheLZw7QVZDPCyGycDWBaqy7FLpSekET_BftD k
ewRhyHk9FW_KeEz0ch2c3i08NGNDbr6XYGVayNuSesYk5Aw_p3ICRlUV1bqEwk –
Jkzs9EEkQg4hbefqJS6yS1HoV_2EsEhpd_wCQpxK89WPs3hLYZETRJtG5kvCCEOvSHXmD
E6eTHGTnEgsIk –
UlPe275Dvou4gEAwLofhLDQbMSjnlV5VLsjimNBVcSRFShoxmQwBJR_b2011Y5IuD6St5z
PnzruBbZYkGNurQK63TJPWmRd3mbJsGM0mf3CU Q", "token_type": "Bearer", "expires_in":
"3600", "expires_on": "1388444763", "resource": "https://service.contoso.com/", "refresh_token":
"AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4rTfgV29ghDOHRc2B –
C_hHeJaJICqjZ3mY2b_YNqmf9SoAylD1PycGCB90xzZeEDg6oBzOIPfY sbDWNf621pKo2Q3
GGTHYlmNfwoc –
OlrxK69hkha2CF12azM_NYhgO668yfcUl4VBbiSHZyd1NVZG5QTIOcbObu3qnLutbpadZGA
xqjIbMkQ2bQS09fTrjMBtDE3D6kSMIodpCecoANon9b0LATkpitimVCrl –
NyfN3oyG4ZCWu18M9 -vEou4Sq -1oMDzExgAf61noxzkNiaTecM –
Ve5cq6wHqYQjfV9DOz4lbceuYCAA", "scope":
"https%3 A%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 re sursa securizată, cum ar 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: Utilizare a 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. Ac eastă valoare este utilizată
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ă es te
utilizator _impersonation . 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ă expira rea 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 informaț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 v aloarea 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": 1388444763, "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": "Miller",
"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 revendicare

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. Mom entul în care expiră tokenul. 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 familie 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 re prezentat 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ă fie 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 Identificator 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 identificator 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 obiecte 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 toke n 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": [ 70 002, 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 t ipurile 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.
error_codes O listă a codurilor de eroar e 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 documentul 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 Aute ntificare esuata. De exemplu, 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 ero rile 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 /authorize 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 n u 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.
invalid_client Autentificarea clientului a eșuat. Acreditările clientului nu sunt valide. Pentru
a repara, administratorul 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
configu rată î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 autenti ficare. În loc de o solicitare 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 pute a 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, pr in includerea acestuia în antetul 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
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1THdqcHdBSk9
NOW4tQSJ9.eyJhdWQiOiJodHRwczovL.JZw8jC0gptZxVC –
7l5sFkdnJgP3_tRjeQEPgUn28XctVe3QqmheLZw7QVZDPCyGycDWBaqy7FLpSekET_BftDk
ewRhyHk9FW_KeEz0ch2c3i08NGNDbr6XYGVayNuSesYk5Aw_p3ICRlU V1bqEwk –
Jkzs9EEkQg4hbefqJS6yS1HoV_2EsEhpd_wCQpxK89WPs3hLYZETRJtG5kvCCEOvSHXmD
E6eTHGTnEgsIk –
UlPe275Dvou4gEAwLofhLDQbMSjnlV5VLsjimNBVcSRFShoxmQwBJR_b2011Y5IuD6St5z
PnzruBbZYkGNurQK63TJPWmRd3mbJsGM0mf3CUQ
Răspuns la eroare
Resursele securizate care implement ează 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 exemplu 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_description="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.microsoftonline.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țiu nea 5.2 din cadrul de autorizare 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 fol osi 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 resursele 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 utilizeze 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 acce s lipsește, nu este valid sau 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 ero are utilizatorului și încercaț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 parametrul 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 e misiunii 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 c odului 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 util iza, de asemenea, punctul final
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: ap plication/x -www -form -urlencoded
client_id=6731de76 -14a6 -49ae -97bc -6eba6914391e
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq..
. &grant_type=refresh_token &resource=https%3A%2F%2Fservice.contoso.com%2F
&client_secret=JqQX2PNo9bpM0uEih UPzyrh // NOTE: Only required 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":
"eyJ0eXAi OiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1THdqcHdBSk
9NOW4tQSJ9.eyJhdWQiOiJodHRwczovL.JZw8jC0gptZxVC –
7l5sFkdnJgP3_tRjeQEPgUn28XctVe3QqmheLZw7QVZDPCyGycDWBaqy7FLpSekET_BftDk
ewRhyHk9FW_KeEz0ch2c3i08NGNDbr6XYGVayNuSesYk5Aw_p3ICRlUV1bqEwk –
Jkzs9EEk Qg4hbefqJS6yS1HoV_2EsEhpd_wCQpxK89WPs3hLYZETRJtG5kvCCEOvSHXmD
E6eTHGTnEgsIk –
UlPe275Dvou4gEAwLofhLDQbMSjnlV5VLsjimNBVcSRFShoxmQwBJR_b2011Y5IuD6St5z
PnzruBbZYkGNurQK63TJPWmRd3mbJsGM0mf3CUQ", "refresh_token": "AwABAAAAv
YNqmf9SoAylD1PycGCB90xzZeEDg6oBzOIPfYsbD WNf621pKo2Q3GGTHYlmNfwoc –
OlrxK69hkha2CF12azM_NYhgO668yfcUl4VBbiSHZyd1NVZG5QTIOcbObu3qnLutbpadZGA
xqjIbMkQ2bQS09fTrjMBtDE3D6kSMIodpCecoANon9b0LATkpitimVCrl
PM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4rTfgV29ghDOHRc2B –

49
C_hHeJaJICqjZ3mY2b_YNqmf9SoAylD1PycGCB90xzZeEDg6oBz OIPfYsbDWNf621pKo2Q3
GGTHYlmNfwoc -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 jetonului î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ă res ursa securizată pe care poate 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 ero are ar putea arăta astfel:
{ "error": "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 applicatio n 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 Descri ere

50
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 princ ipală 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.
Pentru o descriere a codurilor de eroare și a acțiunii client recomandate, consultați codurile de
eroare pentru erorile punctului final pentru tok en .

4. Laborator Hybrid (integrare 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 utilizator 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 Enterpri se State
Roaming și Single Sign on pe 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 Busine ss 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 încep e să construim laboratorul nostru, inclusiv 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.azure.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 procesu l. Î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. Fo losind exemplul din imaginea următoare, 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 folos i FQDN (domeniul de
Internet) și o etichetă 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 chiriaș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 apropiată 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 pentru 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 proprietatea. Î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 im agine: 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 z ona de administrare a meniului, selectaț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 R olul directorului.
Selectați Administratorul 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 utilizat orului . 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
procesu l de creare a unui administrator global î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 adecvate î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
Selectaț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 pen tru grupul de resurse și alegeți un nume 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 ceea 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.
Selectaț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 i mplicit în rețeaua noastră Azure? Trebuie 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ă s ecțiune trece prin crearea infrastructurii 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 serviciului.

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. Acesta 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 devr eme.
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 dimen siune 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 Basi c, 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 c ostul
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 pag ina
Î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 pe 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 Expertul 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 local 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 Di rectory creat pe el. Acum, când toate mașinile sunt conectate 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 pentru 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 vo m folosi, de asemenea, pentru a instala și configura serverul
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 "wildcard" 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 pent ru a începe instalarea și acceptați
termenii licenței. Faceț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 necesare. 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 directo ries, 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. Se lectaț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 c are 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 pagi nă. În pagina de
acreditare a administratorului domeniului, 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 cert ificatul 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 P refix 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 verific ată, 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 utilizatori 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
computerele 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 di n 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
aplicaț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 test in User s and groups la
ambele aplicații .

La final deschidem o sesiune noua incognito către http://myapps.microsof t.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 pagina 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țiile 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 :

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