Oktatóanyag: SCIM-végpont kiépítésének fejlesztése és megtervezése az Azure Active Directoryban

Cikk
09/27/2022
33 perc alatt elolvasható

Alkalmazásfejlesztőként a System for Cross-Domain Identity Management (SCIM) felhasználókezelési API-val engedélyezheti a felhasználók és csoportok automatikus kiépítését az alkalmazás és az Azure Active Directory (Azure AD) között. Ez a cikk ismerteti, hogyan hozhat létre SCIM-végpontot, és hogyan integrálható a Azure AD kiépítési szolgáltatással. Az SCIM-specifikáció közös felhasználói sémát biztosít a kiépítéshez. Ha olyan összevonási szabványokkal használják, mint az SAML vagy az OpenID Connect, az SCIM végpontok közötti, szabványalapú megoldást biztosít a rendszergazdáknak a hozzáférés-kezeléshez.

Üzembe helyezés Azure AD-ból egy alkalmazásba SCIM használatával

Az SCIM 2.0 két végpont szabványosított definíciója: egy /Users végpont és egy /Groups végpont. Általános REST API-végpontokat használ objektumok létrehozásához, frissítéséhez és törléséhez. Az SCIM egy előre definiált sémából áll a gyakori attribútumokhoz, például csoportnévhez, felhasználónévhez, utónévhez, vezetéknévhez és e-mail-címhez.

Az SCIM 2.0 REST API-t kínáló alkalmazások csökkenthetik vagy kiküszöbölhetik a saját fejlesztésű felhasználókezelési API-k használatának fájdalmát. Például bármely megfelelő SCIM-ügyfél tudja, hogyan hozhat létre egy JSON-objektum HTTP POST-fájlját a /Users végponton új felhasználói bejegyzés létrehozásához. Ahelyett, hogy egy kissé eltérő API-ra van szüksége ugyanazokhoz az alapvető műveletekhez, az SCIM szabványnak megfelelő alkalmazások azonnal kihasználhatják a már meglévő ügyfelek, eszközök és kódok előnyeit.

Az SCIM 2.0-ban (RFC 7642, 7643, 7644) meghatározott felügyeleti szabványos felhasználói objektumséma és rest API-k lehetővé teszik az identitásszolgáltatók és alkalmazások számára, hogy könnyebben integrálhatók legyenek egymással. Az SCIM-végpontot készítő alkalmazásfejlesztők egyéni munka nélkül integrálhatók bármely SCIM-kompatibilis ügyféllel.

Az alkalmazások üzembe helyezésének automatizálásához létre kell hoznia és integrálnia kell egy SCIM-végpontot, amelyet a Azure AD Provisioning Service ér el. A felhasználók és csoportok alkalmazásba való kiépítésének megkezdéséhez kövesse az alábbi lépéseket.

A felhasználó- és csoportséma megtervezése – Azonosítsa az alkalmazás objektumait és attribútumait, és határozza meg, hogyan képezhetők le a Azure AD SCIM-implementáció által támogatott felhasználói és csoportsémára.
Az SCIM Azure AD implementációjának ismertetése – Ismerje meg, hogyan történik a Azure AD Provisioning Service implementálása az SCIM-protokoll kéréskezelésének és válaszainak modellezéséhez.
SCIM-végpont létrehozása – A végpontnak SCIM 2.0-kompatibilisnek kell lennie a Azure AD kiépítési szolgáltatással való integrációhoz. A végpont létrehozásához használja a Microsoft Common Language Infrastructure (CLI) kódtárait és kódmintáit. Ezek a minták csak referencia- és tesztelési célokra szolgálnak; javasoljuk, hogy ne használja őket függőségként az éles alkalmazásban.
Integrálja az SCIM-végpontot a Azure AD Provisioning Service szolgáltatással. Ha a szervezet külső alkalmazással valósítja meg az SCIM 2.0 olyan profilját, amelyet Azure AD támogat, gyorsan automatizálhatja a felhasználók és csoportok kiépítését és megszüntetését.
[Nem kötelező] Az alkalmazás közzététele a Azure AD alkalmazáskatalógusban – Megkönnyíti az ügyfelek számára az alkalmazás felfedezését és a kiépítés egyszerű konfigurálását.

Az SCIM-végpont és a Azure AD integrálásához szükséges lépéseket bemutató ábra.

A felhasználói és csoportséma megtervezése

Minden alkalmazáshoz különböző attribútumok szükségesek a felhasználó vagy csoport létrehozásához. Indítsa el az integrációt az alkalmazáshoz szükséges objektumok (felhasználók, csoportok) és attribútumok (név, vezető, beosztás stb.) azonosításával.

Az SCIM szabvány egy sémát határoz meg a felhasználók és csoportok kezeléséhez.

Az alapvető felhasználói séma csak három attribútumot igényel (az összes többi attribútum nem kötelező):

id, szolgáltató által definiált azonosító
userName, a felhasználó egyedi azonosítója (általában a Azure AD egyszerű felhasználó nevére van leképezve)
meta, a szolgáltató által fenntartott csak olvasási metaadatok

Az alapvető felhasználói séma mellett az SCIM szabvány egy vállalati felhasználói bővítményt is definiál, amely modellel bővíti a felhasználói sémát az alkalmazás igényeinek megfelelően.

Ha például az alkalmazáshoz egy felhasználó e-mail-címe és a felhasználó felettese is szükséges, az alapsémával gyűjtse össze a felhasználó e-mail-címét és a vállalati felhasználói sémát a felhasználó felettesének gyűjtéséhez.

A séma megtervezéséhez kövesse az alábbi lépéseket:

Sorolja fel az alkalmazás által igényelt attribútumokat, majd kategorizálja a hitelesítéshez szükséges attribútumokat (például loginName és e-mail). A felhasználói életciklus kezeléséhez attribútumokra (például állapot/aktív) és az alkalmazás működéséhez szükséges összes egyéb attribútumra (például felettes, címke) van szükség.
Ellenőrizze, hogy az attribútumok már definiálva vannak-e az alapvető felhasználói sémában vagy a vállalati felhasználói sémában. Ha nem, meg kell adnia egy bővítményt a felhasználói sémához, amely lefedi a hiányzó attribútumokat. Az alábbi példában egy, a felhasználónak szánt bővítményt talál, amely lehetővé teszi a felhasználó tagkiépítését.
Az SCIM-attribútumok leképezése a Azure AD felhasználói attribútumaihoz. Ha az SCIM-végpontban definiált egyik attribútum nem rendelkezik egyértelmű megfelelővel a Azure AD felhasználói sémában, kérje meg a bérlő rendszergazdáját, hogy bővítse ki a sémát, vagy használjon bővítményattribútumot a tags tulajdonsághoz alább látható módon.

Az alábbi táblázat a szükséges attribútumokra mutat be egy példát:

Kötelező alkalmazásattribútum	Leképezett SCIM-attribútum	Megfeleltetett Azure AD attribútum
loginName	userName (Felhasználónév)	userPrincipalName
firstName	name.givenName	givenName
lastName	name.familyName	Vezetéknév
workMail	emails[type eq "work"].value	Mail
manager	manager	manager
címke	urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User:tag	extensionAttribute1
status	active	isSoftDeleted (a felhasználó által nem tárolt számított érték)

Az alábbi JSON hasznos adat egy SCIM-sémát mutat be:

{
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User",
      "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
      "urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User"],
     "userName":"bjensen@testuser.com",
     "id": "48af03ac28ad4fb88478",
     "externalId":"bjensen",
     "name":{
       "familyName":"Jensen",
       "givenName":"Barbara"
     },
     "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
     "Manager": "123456"
   },
     "urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User": {
     "tag": "701984",
   },
   "meta": {
     "resourceType": "User",
     "created": "2010-01-23T04:56:22Z",
     "lastModified": "2011-05-13T04:42:34Z",
     "version": "W\/\"3694e05e9dff591\"",
     "location":
 "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
   }
}

Megjegyzés

Az alkalmazáshoz szükséges attribútumokon kívül a JSON-reprezentáció a szükséges id, externalIdés meta az attribútumokat is tartalmazza.

Segítségével kategorizálhatja /User/Group a Azure AD alapértelmezett felhasználói attribútumait az SCIM RFC-re, és leképezheti azokat. Megtudhatja, hogyan vannak leképezve az attribútumok a Azure AD és az SCIM-végpont között.

Az alábbi táblázat a felhasználói attribútumok példáját sorolja fel:

Azure AD-felhasználó	urn:ietf:params:scim:schemas:extension:enterprise:2.0:User
IsSoftDeleted	active
Részleg	`urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department`
displayName	displayName
employeeId	`urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber`
Facsimile-TelephoneNumber	phoneNumbers[type eq "fax"].value
givenName	name.givenName
jobTitle	cím
Levelezés	emails[type eq "work"].value
mailNickname	externalId
manager	`urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager`
mobil	phoneNumbers[type eq "mobile"].value
postalCode	addresses[type eq "work"].postalCode
proxycímek	email[type eq "other"]. Érték
physical-Delivery-OfficeName	addresses[type eq "other"]. Formázott
streetAddress	addresses[type eq "work"].streetAddress
surname	name.familyName
telefonszám	phoneNumbers[type eq "work"].value
user-PrincipalName	userName (Felhasználónév)

Az alábbi táblázat a csoportattribútumok példáját sorolja fel:

Azure AD csoport	urn:ietf:params:scim:schemas:core:2.0:Group
displayName	displayName
tagok	tagok
objectId	externalId

Megjegyzés

Nem kell támogatnia mind a felhasználókat, mind a csoportokat, vagy az itt látható összes attribútumot, ez csak egy hivatkozás arra vonatkozóan, hogy a Azure AD attribútumai gyakran hogyan vannak leképezve az SCIM protokoll tulajdonságaira.

Az SCIM RFC-ben több végpont is definiálva van. Kiindulhat a /User végpontból, majd onnan kibonthatja a elemet. Az alábbi táblázat néhány SCIM-végpontot sorol fel:

Végpont	Leírás
/Felhasználó	CRUD-műveleteket hajthat végre egy felhasználói objektumon.
/Group	CRUD-műveleteket hajthat végre egy csoportobjektumon.
/Sémák	Az egyes ügyfelek és szolgáltatók által támogatott attribútumok halmaza eltérő lehet. Az egyik szolgáltató tartalmazhat , `nametitle`, és `emails`, míg egy másik szolgáltató használja `name`, `title`és `phoneNumbers`. A sémavégpont lehetővé teszi a támogatott attribútumok felderítését.
/Tömeges	A tömeges műveletek lehetővé teszik, hogy egyetlen műveletben (például egy nagy csoport tagságainak frissítése) hajtsa végre az erőforrás-objektumok nagy gyűjteményén végzett műveleteket.
/ServiceProviderConfig	Részletesen ismerteti az SCIM szabvány támogatott funkcióit, például a támogatott erőforrásokat és a hitelesítési módszert.
/ResourceTypes	Az egyes erőforrások metaadatait határozza meg.

Megjegyzés

Használja a /Schemas végpontot az egyéni attribútumok támogatásához, vagy ha a séma gyakran változik, mivel lehetővé teszi, hogy az ügyfél automatikusan lekérje a legfrissebb sémát. Használja a végpontot a /Bulk csoportok támogatásához.

A Azure AD SCIM implementációjának ismertetése

Az SCIM 2.0 felhasználókezelési API-k támogatásához ez a szakasz ismerteti a Azure AD Provisioning Service implementálását, és bemutatja, hogyan modellezheti az SCIM protokoll kéréskezelését és válaszait.

Fontos

A Azure AD SCIM-implementáció viselkedése legutóbb 2018. december 18-án frissült. A változásokról további információt a Azure AD User Provisioning Service SCIM 2.0 protokollmegfelelőségében talál.

Az SCIM 2.0 protokoll specifikáción belül az alkalmazásnak támogatnia kell ezeket a követelményeket:

Követelmény	Referenciajegyzetek (SCIM protokoll)
Felhasználók és opcionálisan csoportok létrehozása	3.3. szakasz
Felhasználók vagy csoportok módosítása PATCH-kérésekkel	3.5.2. A támogatás biztosítja, hogy a csoportok és a felhasználók kiépítése megfelelő módon történik.
Egy korábban létrehozott felhasználó vagy csoport ismert erőforrásának lekérése	3.4.1. szakasz
Felhasználók vagy csoportok lekérdezése	3.4.2. Alapértelmezés szerint a felhasználókat a saját és `id` a `usernameexternalId`, és a csoportok kérdezik le `displayName`.
A filter excludedAttributes=members a csoporterőforrás lekérdezésekor	3.4.2.2. szakasz
Felhasználók listázásának és lapszámozásának támogatása	3.4.2.4.
Felhasználó helyreállítható `active=false` törlése és visszaállítása `active=true`	A felhasználói objektumot egy kérésben kell visszaadni, függetlenül attól, hogy a felhasználó aktív-e. A felhasználó csak akkor nem adható vissza, ha az alkalmazásból véglegesen törölve van.
A /Schemas végpont támogatása	7. szakasz A sémafelderítési végpont további attribútumok felderítésére szolgál.
Fogadjon el egyetlen tulajdonosi jogkivonatot az alkalmazáshoz Azure AD hitelesítéséhez és engedélyezéséhez.

Az SCIM-végpontok implementálásakor az általános irányelveket követve biztosíthatja a Azure AD való kompatibilitást:

Általános:

id A az összes erőforrás kötelező tulajdonsága. Minden erőforrást visszaadó válasznak biztosítania kell, hogy minden erőforrás rendelkezik ezzel a tulajdonsággal, kivéve ListResponse a nulla elemeket.
Az elküldött értékeket ugyanabban a formátumban kell tárolni, mint az elküldött értékeket. Az érvénytelen értékeket leíró, végrehajtható hibaüzenettel kell elutasítani. Az adatok átalakítása nem történhet meg a Azure AD által küldött és az SCIM-alkalmazásban tárolt adatok között. (például. A 55555555555 ként küldött telefonszámokat nem szabad +5 (555) 555-5555 formátumban menteni/visszaadni)
Nem szükséges a teljes erőforrást belefoglalni a PATCH-válaszba .
Ne követelje meg a kis- és nagybetűket megkülönböztető egyezést az SCIM szerkezeti elemein, különösen a PATCHop műveleti értékeken, a 3.5.2 szakaszban meghatározottak szerint. Azure AD a Hozzáadás, Csere és Eltávolítás értékeket op adja ki.
Microsoft Azure AD kéréseket küld egy véletlenszerű felhasználó és csoport lekérésére, hogy a végpont és a hitelesítő adatok érvényesek legyenek. Ez a Azure Portalkapcsolattesztelési folyamatának részeként is megtörténik.
A HTTPS támogatása az SCIM-végponton.
Az egyéni összetett és többértékű attribútumok támogatottak, de Azure AD ezekben az esetekben nem rendelkezik sok összetett adatstruktúrával az adatok lekéréséhez. Az egyszerű párosított név/érték típusú összetett attribútumok egyszerűen leképezhetők, de az adatok három vagy több alattribútummal rendelkező összetett attribútumba való áramlása jelenleg nem támogatott.
A többértékű összetett attribútumok "típus" felosztott értékeinek egyedinek kell lenniük. Nem lehet például két különböző e-mail-cím a "work" altípussal.
Az összes válasz fejlécének tartalomtípusúnak kell lennie: application/scim+json

Erőforrások lekérése:

A lekérdezési/szűrési kérésre adott válasznak mindig egynek ListResponsekell lennie.
Microsoft Azure AD csak a következő operátorokat használja: eq,and
Az erőforrások lekérdezhető attribútumát egyező attribútumként kell beállítani az alkalmazáshoz a Azure Portal. Lásd: Felhasználóátadási attribútumleképezések testreszabása.

/Felhasználók:

A jogosultságok attribútum nem támogatott.
A felhasználói egyediség szempontjából figyelembe vett attribútumoknak használhatónak kell lenniük egy szűrt lekérdezés részeként. (Ha például a felhasználó egyediségét mind a userName, mind az e-mailek[type eq "work"], a GET to /Users szűrőnek engedélyeznie kell a userName eq "user@contoso.com" és az email[type eq "work"].value eq "user@contoso.com" lekérdezéseket is.

/Csoportok:

A csoportok nem kötelezőek, de csak akkor támogatottak, ha az SCIM-implementáció támogatja a PATCH-kéréseket.
A csoportoknak egyedinek kell lenniük a "displayName" értéken, hogy megegyezhessenek Azure AD és az SCIM-alkalmazással. Az egyediség nem az SCIM protokoll követelménye, hanem az SCIM-végpont Azure AD való integrálásának követelménye.

/Sémák (sémafelderítés):

Mintakérés/válasz
A sémaészlelés jelenleg nem támogatott az egyéni, nem katalógusbeli SCIM-alkalmazásokban, de bizonyos katalógusbeli alkalmazásokban használják. A jövőben a sémafelderítés lesz az egyetlen módszer, amellyel további attribútumokat adhat hozzá egy meglévő katalógus SCIM-alkalmazás sémához.
Ha egy érték nincs jelen, ne küldjön null értékeket.
A tulajdonságértékeket kisbetűsre kell írni (például readWrite).
Listaválaszt kell visszaadnia.
A /schemas kérést a Azure AD Kiépítési szolgáltatás minden alkalommal intézi, amikor valaki menti a kiépítési konfigurációt a Azure Portal, vagy amikor egy felhasználó a Azure Portal szerkesztési kiépítési lapjára kerül. A felderített egyéb attribútumok megjelennek az ügyfelek számára a célattribútum-lista attribútumleképezéseiben. A sémafelderítés csak további célattribútumok hozzáadását eredményezi. Ez nem eredményezi az attribútumok eltávolítását.

Felhasználók kiépítése és megszüntetése

Az alábbi ábra azokat az üzeneteket mutatja be, amelyeket Azure AD küld egy SCIM-végpontnak egy felhasználó életciklusának kezeléséhez az alkalmazás identitástárolójában.

Csoportkiépítés és -megszüntetés

A csoportkiépítés és a megszüntetés nem kötelező. Ha implementálva és engedélyezve van, az alábbi ábrán azok az üzenetek láthatók, amelyeket Azure AD küldenek egy SCIM-végpontnak egy csoport életciklusának kezeléséhez az alkalmazás identitástárolójában. Ezek az üzenetek kétféleképpen különböznek a felhasználókról szóló üzenetektől:

A csoportok lekérésére irányuló kérések megadják, hogy a tagattribútumot ki kell zárni a kérésre adott válaszban megadott erőforrásokból.
A tagattribútummal kapcsolatos kérések annak megállapítására, hogy egy referenciaattribútum rendelkezik-e bizonyos értékkel.

Az alábbi ábrán a csoportbontási sorozat látható:

SCIM protokollkérelmek és válaszok

Ez a cikk az Azure Active Directory (Azure AD) kiépítési szolgáltatása által kibocsátott példa SCIM-kéréseket és a várt válaszokat tartalmazza. A legjobb eredmény érdekében kódolhatja az alkalmazást, hogy ilyen formátumban kezelje ezeket a kéréseket, és a várt válaszokat adja ki.

Fontos

Annak megismeréséhez, hogy a Azure AD felhasználókiépítési szolgáltatás hogyan és mikor bocsátja ki az alább leírt műveleteket, tekintse meg a kiépítési ciklusok: Kezdeti és növekményes szakaszt a kiépítés működésében.

Felhasználói műveletek

Felhasználó létrehozása (kérelemre / adott válasz)
Felhasználó lekérése (kérelemre / adott válasz)
Felhasználó lekérése lekérdezés alapján (kérelemre / adott válasz)
Felhasználó lekérése lekérdezés alapján – Nulla eredmény (Kérelemre / adott válasz)
Felhasználó frissítése [Többértékű tulajdonságok] (Kérelemre / adott válasz)
Felhasználó frissítése [Egyértékű tulajdonságok] (Kérelemre / adott válasz)
Felhasználó letiltása (kérelemre / adott válasz)
Felhasználó törlése (kérelemre / adott válasz)

Csoportműveletek

Csoport létrehozása (kérelemre / adott válasz)
Csoport lekérése (kérésre / adott válasz)
Csoport lekérése displayName szerint (kérés / válasza)
Csoport frissítése [Nem tag attribútumok] (Kérelemre / adott válasz)
Csoport frissítése [Tagok hozzáadása] (kérelemre / adott válasz)
Csoport frissítése [Tagok eltávolítása] (kérelemre / adott válasz)
Csoport törlése (kérelemre / adott válasz)

Sémafelderítés

Séma felderítése (kérelemválasz / )

Felhasználói műveletek

A felhasználókat lekérdezheti attribútumok vagy emails[type eq "work"] attribútumok alapjánuserName.

Felhasználó létrehozása

Kérés

POST /Users

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
    "externalId": "0a21f0f2-8d2a-4f8e-bf98-7363c4aed4ef",
    "userName": "Test_User_ab6490ee-1e48-479e-a20b-2d77186b5dd1",
    "active": true,
    "emails": [{
        "primary": true,
        "type": "work",
        "value": "Test_User_fd0ea19b-0777-472c-9f96-4f70d2226f2e@testuser.com"
    }],
    "meta": {
        "resourceType": "User"
    },
    "name": {
        "formatted": "givenName familyName",
        "familyName": "familyName",
        "givenName": "givenName"
    },
    "roles": []
}

Reagálás

HTTP/1.1 201 Létrehozva

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "id": "48af03ac28ad4fb88478",
    "externalId": "0a21f0f2-8d2a-4f8e-bf98-7363c4aed4ef",
    "meta": {
        "resourceType": "User",
        "created": "2018-03-27T19:59:26.000Z",
        "lastModified": "2018-03-27T19:59:26.000Z"
    },
    "userName": "Test_User_ab6490ee-1e48-479e-a20b-2d77186b5dd1",
    "name": {
        "formatted": "givenName familyName",
        "familyName": "familyName",
        "givenName": "givenName",
    },
    "active": true,
    "emails": [{
        "value": "Test_User_fd0ea19b-0777-472c-9f96-4f70d2226f2e@testuser.com",
        "type": "work",
        "primary": true
    }]
}

Felhasználó beolvasása

Kérés

GET /Users/5d48a0a8e9f04aa38008

Válasz (a felhasználó megtalálta)

HTTP/1.1 200 OK

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "id": "5d48a0a8e9f04aa38008",
    "externalId": "58342554-38d6-4ec8-948c-50044d0a33fd",
    "meta": {
        "resourceType": "User",
        "created": "2018-03-27T19:59:26.000Z",
        "lastModified": "2018-03-27T19:59:26.000Z"
    },
    "userName": "Test_User_feed3ace-693c-4e5a-82e2-694be1b39934",
    "name": {
        "formatted": "givenName familyName",
        "familyName": "familyName",
        "givenName": "givenName",
    },
    "active": true,
    "emails": [{
        "value": "Test_User_22370c1a-9012-42b2-bf64-86099c2a1c22@testuser.com",
        "type": "work",
        "primary": true
    }]
}

Kérés

GET /Users/5171a35d82074e068ce2

Válasz (a felhasználó nem található. A részletek nem kötelezőek, csak állapot.)

{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:Error"
    ],
    "status": "404",
    "detail": "Resource 23B51B0E5D7AE9110A49411D@7cca31655d49f3640a494224 not found"
}

Felhasználó lekérése lekérdezés alapján

Kérés

GET /Users?filter=userName eq "Test_User_dfeef4c5-5681-4387-b016-bdf221e82081"

Reagálás

HTTP/1.1 200 OK

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
    "totalResults": 1,
    "Resources": [{
        "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
        "id": "2441309d85324e7793ae",
        "externalId": "7fce0092-d52e-4f76-b727-3955bd72c939",
        "meta": {
            "resourceType": "User",
            "created": "2018-03-27T19:59:26.000Z",
            "lastModified": "2018-03-27T19:59:26.000Z"
            
        },
        "userName": "Test_User_dfeef4c5-5681-4387-b016-bdf221e82081",
        "name": {
            "familyName": "familyName",
            "givenName": "givenName"
        },
        "active": true,
        "emails": [{
            "value": "Test_User_91b67701-697b-46de-b864-bd0bbe4f99c1@testuser.com",
            "type": "work",
            "primary": true
        }]
    }],
    "startIndex": 1,
    "itemsPerPage": 20
}

Felhasználó lekérése lekérdezés alapján – Nulla eredmény

Kérés

GET /Users?filter=userName eq "nem létező felhasználó"

Reagálás

HTTP/1.1 200 OK

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
    "totalResults": 0,
    "Resources": [],
    "startIndex": 1,
    "itemsPerPage": 20
}

Felhasználó frissítése [Többértékű tulajdonságok]

Kérés

PATCH /Users/6764549bef60420686bc HTTP/1.1

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
            {
            "op": "Replace",
            "path": "emails[type eq \"work\"].value",
            "value": "updatedEmail@microsoft.com"
            },
            {
            "op": "Replace",
            "path": "name.familyName",
            "value": "updatedFamilyName"
            }
    ]
}

Reagálás

HTTP/1.1 200 OK

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "id": "6764549bef60420686bc",
    "externalId": "6c75de36-30fa-4d2d-a196-6bdcdb6b6539",
    "meta": {
        "resourceType": "User",
        "created": "2018-03-27T19:59:26.000Z",
        "lastModified": "2018-03-27T19:59:26.000Z"
    },
    "userName": "Test_User_fbb9dda4-fcde-4f98-a68b-6c5599e17c27",
    "name": {
        "formatted": "givenName updatedFamilyName",
        "familyName": "updatedFamilyName",
        "givenName": "givenName"
    },
    "active": true,
    "emails": [{
        "value": "updatedEmail@microsoft.com",
        "type": "work",
        "primary": true
    }]
}

Felhasználó frissítése [Egyértékű tulajdonságok]

Kérés

PATCH /Users/5171a35d82074e068ce2 HTTP/1.1

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{
        "op": "Replace",
        "path": "userName",
        "value": "5b50642d-79fc-4410-9e90-4c077cdd1a59@testuser.com"
    }]
}

Reagálás

HTTP/1.1 200 OK

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "id": "5171a35d82074e068ce2",
    "externalId": "aa1eca08-7179-4eeb-a0be-a519f7e5cd1a",
    "meta": {
        "resourceType": "User",
        "created": "2018-03-27T19:59:26.000Z",
        "lastModified": "2018-03-27T19:59:26.000Z"
        
    },
    "userName": "5b50642d-79fc-4410-9e90-4c077cdd1a59@testuser.com",
    "name": {
        "formatted": "givenName familyName",
        "familyName": "familyName",
        "givenName": "givenName",
    },
    "active": true,
    "emails": [{
        "value": "Test_User_49dc1090-aada-4657-8434-4995c25a00f7@testuser.com",
        "type": "work",
        "primary": true
    }]
}

Felhasználó letiltása

Kérés

PATCH /Users/5171a35d82074e068ce2 HTTP/1.1

{
    "Operations": [
        {
            "op": "Replace",
            "path": "active",
            "value": false
        }
    ],
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ]
}

Reagálás

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "id": "CEC50F275D83C4530A495FCF@834d0e1e5d8235f90a495fda",
    "userName": "deanruiz@testuser.com",
    "name": {
        "familyName": "Harris",
        "givenName": "Larry"
    },
    "active": false,
    "emails": [
        {
            "value": "gloversuzanne@testuser.com",
            "type": "work",
            "primary": true
        }
    ],
    "addresses": [
        {
            "country": "ML",
            "type": "work",
            "primary": true
        }
    ],
    "meta": {
        "resourceType": "Users",
        "location": "/scim/5171a35d82074e068ce2/Users/CEC50F265D83B4530B495FCF@5171a35d82074e068ce2"
    }
}

Felhasználó törlése

Kérés

DELETE /Users/5171a35d82074e068ce2 HTTP/1.1

Reagálás

HTTP/1.1 204 Nincs tartalom

Csoportműveletek

A csoportokat mindig üres taglistával kell létrehozni.
A csoportokat az displayName attribútum lekérdezheti.
A csoport PATCH-kérésének frissítése http 204 No Content értéket eredményez a válaszban. Az összes tagot tartalmazó törzs visszaküldése nem ajánlott.
Nem szükséges támogatni a csoport összes tagjának visszaküldését.

Csoport létrehozása

Kérés

POST /Groups HTTP/1.1

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group", "http://schemas.microsoft.com/2006/11/ResourceManagement/ADSCIM/2.0/Group"],
    "externalId": "8aa1a0c0-c4c3-4bc0-b4a5-2ef676900159",
    "displayName": "displayName",
    "meta": {
        "resourceType": "Group"
    }
}

Reagálás

HTTP/1.1 201 Létrehozva

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
    "id": "927fa2c08dcb4a7fae9e",
    "externalId": "8aa1a0c0-c4c3-4bc0-b4a5-2ef676900159",
    "meta": {
        "resourceType": "Group",
        "created": "2018-03-27T19:59:26.000Z",
        "lastModified": "2018-03-27T19:59:26.000Z"
        
    },
    "displayName": "displayName",
    "members": []
}

Csoport beolvasása

Kérés

GET /Groups/40734ae655284ad3abcc?excludedAttributes=members HTTP/1.1

Reagálás

HTTP/1.1 200 OK

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
    "id": "40734ae655284ad3abcc",
    "externalId": "60f1bb27-2e1e-402d-bcc4-ec999564a194",
    "meta": {
        "resourceType": "Group",
        "created": "2018-03-27T19:59:26.000Z",
        "lastModified": "2018-03-27T19:59:26.000Z"
    },
    "displayName": "displayName",
}

Csoport lekérése displayName szerint

Kérés

GET /Groups?excludedAttributes=members&filter=displayName eq "displayName" HTTP/1.1

Reagálás

HTTP/1.1 200 OK

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
    "totalResults": 1,
    "Resources": [{
        "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
        "id": "8c601452cc934a9ebef9",
        "externalId": "0db508eb-91e2-46e4-809c-30dcbda0c685",
        "meta": {
            "resourceType": "Group",
            "created": "2018-03-27T22:02:32.000Z",
            "lastModified": "2018-03-27T22:02:32.000Z",
            
        },
        "displayName": "displayName",
    }],
    "startIndex": 1,
    "itemsPerPage": 20
}

Csoport frissítése [Nem tag attribútumok]

Kérés

PATCH /Groups/fa2ce26709934589afc5 HTTP/1.1

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{
        "op": "Replace",
        "path": "displayName",
        "value": "1879db59-3bdf-4490-ad68-ab880a269474updatedDisplayName"
    }]
}

Reagálás

HTTP/1.1 204 Nincs tartalom

Csoport frissítése [Tagok hozzáadása]

Kérés

PATCH /Groups/a99962b9f99d4c4fac67 HTTP/1.1

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{
        "op": "Add",
        "path": "members",
        "value": [{
            "$ref": null,
            "value": "f648f8d5ea4e4cd38e9c"
        }]
    }]
}

Reagálás

HTTP/1.1 204 Nincs tartalom

Csoport frissítése [Tagok eltávolítása]

Kérés

PATCH /Groups/a99962b9f99d4c4fac67 HTTP/1.1

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{
        "op": "Remove",
        "path": "members",
        "value": [{
            "$ref": null,
            "value": "f648f8d5ea4e4cd38e9c"
        }]
    }]
}

Reagálás

HTTP/1.1 204 Nincs tartalom

Csoport törlése

Kérés

DELETE /Groups/cdb1ce18f65944079d37 HTTP/1.1

Reagálás

HTTP/1.1 204 Nincs tartalom

Sémafelderítés

Séma felderítése

Kérés

GET /Sémák

Reagálás

HTTP/1.1 200 OK

{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "itemsPerPage": 50,
    "startIndex": 1,
    "totalResults": 3,
    "Resources": [
  {
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
    "id" : "urn:ietf:params:scim:schemas:core:2.0:User",
    "name" : "User",
    "description" : "User Account",
    "attributes" : [
      {
        "name" : "userName",
        "type" : "string",
        "multiValued" : false,
        "description" : "Unique identifier for the User, typically
used by the user to directly authenticate to the service provider.
Each User MUST include a non-empty userName value.  This identifier
MUST be unique across the service provider's entire set of Users.
REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "server"
      },                
    ],
    "meta" : {
      "resourceType" : "Schema",
      "location" :
        "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:User"
    }
  },
  {
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "displayName",
        "type" : "string",
        "multiValued" : false,
        "description" : "A human-readable name for the Group.
REQUIRED.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },
    ],
    "meta" : {
      "resourceType" : "Schema",
      "location" :
        "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Group"
    }
  },
  {
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"],
    "id" : "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
    "name" : "EnterpriseUser",
    "description" : "Enterprise User",
    "attributes" : [
      {
        "name" : "employeeNumber",
        "type" : "string",
        "multiValued" : false,
        "description" : "Numeric or alphanumeric identifier assigned
to a person, typically based on order of hire or association with an
organization.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },
    ],
    "meta" : {
      "resourceType" : "Schema",
      "location" :
"/v2/Schemas/urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
    }
  }
]
}

Biztonsági követelmények

TLS protokollverziók

Az egyetlen elfogadható TLS-protokollverzió a TLS 1.2 és a TLS 1.3. A TLS más verziói nem engedélyezettek. Az SSL egyik verziója sem engedélyezett.

Az RSA-kulcsoknak legalább 2048 bitnek kell lenniük.
Az ECC-kulcsoknak legalább 256 bitesnek kell lenniük, és jóváhagyott három ponttal kell létrehozni

Kulcshosszok

Minden szolgáltatásnak megfelelő hosszúságú titkosítási kulcsokkal létrehozott X.509-tanúsítványokat kell használnia, ami a következőket jelenti:

Titkosítócsomagok

Minden szolgáltatást úgy kell konfigurálni, hogy az alábbi titkosítási csomagokat használja az alább megadott pontos sorrendben. Ha csak RSA-tanúsítvánnyal rendelkezik, az ECDSA-titkosítási csomagok nincsenek hatással.

TLS 1.2 Titkosítási csomagok minimális sávja:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

IP-tartományok

A Azure AD kiépítési szolgáltatás jelenleg az AzureActiveDirectory IP-tartományai alatt működik az itt felsoroltak szerint. Hozzáadhatja az AzureActiveDirectory címke alatt felsorolt IP-címtartományokat, hogy engedélyezze a forgalmat az Azure AD kiépítési szolgáltatásból az alkalmazásba. Alaposan át kell tekintenie az IP-címtartományok listáját a számított címek esetében. Egy cím, például a "40.126.25.32" a "40.126.0.0/18" ip-címtartomány-listában szerepelhet. Az IP-címtartományok listáját programozott módon is lekérheti az alábbi API-val.

Azure AD emellett egy ügynökalapú megoldást is támogat a privát hálózatokon (helyszíni, Azure-ban üzemeltetett, AWS-ben üzemeltetett stb.) alkalmazásokhoz való kapcsolódáshoz. Az ügyfelek üzembe helyezhetnek egy egyszerűsített ügynököt, amely anélkül biztosít kapcsolatot Azure AD, hogy bejövő portokat nyitnák meg a magánhálózatuk egyik kiszolgálóján. További információkat itt talál.

SCIM-végpont létrehozása

Most, hogy megtervezte a sémát, és megismerte a Azure AD SCIM-implementációt, megkezdheti az SCIM-végpont fejlesztését. Ahelyett, hogy teljesen önállóan építené ki az implementációt, számos nyílt forráskód SCIM-kódtárra támaszkodhat, amelyeket az SCIM-közösség tett közzé.

Az SCIM-végpontok létrehozására vonatkozó útmutatásért, beleértve a példákat, tekintse meg a minta SCIM-végpont fejlesztését ismertető cikket.

A Azure AD kiépítési csapat által közzétett nyílt forráskód .NET Core-referenciakód egy olyan erőforrás, amely elindíthatja a fejlesztést. Az SCIM-végpont létrehozása után érdemes tesztelni. Használhatja a referenciakód részeként megadott Postman-tesztek gyűjteményét, vagy futtathatja a fent megadott mintakéréseket/válaszokat.

Megjegyzés

A referenciakód segítséget nyújt az SCIM-végpont létrehozásának megkezdéséhez, és az "AS IS"-t adja meg. A közösség közreműködésével segítheti a kód összeállítását és karbantartását.

A megoldás két projektből áll: Microsoft.SCIM és Microsoft.SCIM.WebHostSample.

A Microsoft.SCIM-projekt az a kódtár, amely meghatározza a webszolgáltatás azon összetevőit, amelyek megfelelnek az SCIM-specifikációnak. Deklarálja a Microsoft.SCIM.IProvider felületet, a kéréseket a szolgáltató metódusainak hívásaira fordítja le, amelyek egy identitástárolón való működésre lennének programozva.

Lebontás: A szolgáltató metódusainak hívásaira fordított kérés

A Microsoft.SCIM.WebHostSample projekt egy ASP.NET Core-webalkalmazás, amely az Empty sablonon alapul. Lehetővé teszi a mintakód önálló, tárolókban vagy az Internet Information Servicesben való üzembe helyezését. Emellett implementálja a Microsoft.SCIM.IProvider felületet is, amely minta identitástárolóként tárolja az osztályokat a memóriában.

public class Startup
{
    ...
    public IMonitor MonitoringBehavior { get; set; }
    public IProvider ProviderBehavior { get; set; }

    public Startup(IWebHostEnvironment env, IConfiguration configuration)
    {
        ...
        this.MonitoringBehavior = new ConsoleMonitor();
        this.ProviderBehavior = new InMemoryProvider();
    }
    ...

Egyéni SCIM-végpont létrehozása

Az SCIM-végpontnak rendelkeznie kell egy HTTP-címmel és kiszolgálóhitelesítési tanúsítvánnyal, amelynek legfelső szintű hitelesítésszolgáltatója az alábbi nevek egyike:

CNNIC
Comodo
CyberTrust
DigiCert
GeoTrust
Globalsign
Go Daddy
Verisign
WoSign
DST Root CA X3

A .NET Core SDK tartalmaz egy HTTPS fejlesztési tanúsítványt, amely a fejlesztés során használható. A tanúsítvány az első futtatáskor települ. A ASP.NET Core webalkalmazás futtatásától függően a rendszer egy másik portot figyel:

Microsoft.SCIM.WebHostSample: https://localhost:5001
IIS Express:https://localhost:44359

A HTTPS-ről ASP.NET Core a következő hivatkozásra kattintva tájékozódhat: HTTPS kényszerítése ASP.NET Core

Végponthitelesítés kezelése

A Azure AD Provisioning Service-től érkező kérések tartalmaznak egy OAuth 2.0 tulajdonosi jogkivonatot. A tulajdonosi jogkivonat egy engedélyezési kiszolgáló által kiadott biztonsági jogkivonat, például Azure AD, amelyet az alkalmazás megbízhatónak tekint. A Azure AD kiépítendő szolgáltatást az alábbi jogkivonatok egyikének használatára konfigurálhatja:

Egy hosszú élettartamú tulajdonosi jogkivonat. Ha az SCIM-végponthoz nem Azure AD kiállítótól származó OAuth-tulajdonosi jogkivonatra van szükség, másolja a szükséges OAuth-tulajdonosi jogkivonatot az opcionális Titkos jogkivonat mezőbe. Fejlesztési környezetben használhatja a végpont tesztelési jogkivonatát /scim/token . A teszttokeneket nem szabad éles környezetben használni.
Azure AD tulajdonosi jogkivonatot. Ha a Titkos jogkivonat mező üres, Azure AD minden kéréshez tartalmaz egy OAuth-tulajdonosi jogkivonatot Azure AD. Az Azure AD identitásszolgáltatóként használó alkalmazások érvényesíthetik ezt a Azure AD által kibocsátott jogkivonatot.
- A kéréseket fogadó alkalmazásnak ellenőriznie kell, hogy a jogkivonat kiállítója Azure AD-e egy várt Azure AD bérlőhöz.
- A jogkivonatban a kiállítót egy iss jogcím azonosítja. Például: "iss":"https://sts.windows.net/12345678-0000-0000-0000-000000000000/". Ebben a példában a jogcímérték https://sts.windows.net alapcíme Azure AD azonosítja kiállítóként, míg a relatív címszegmens (12345678-0000-0000-0000-0000000000000) annak a Azure AD bérlőnek az egyedi azonosítója, amelyhez a jogkivonatot kiadták.
- A token célközönsége az alkalmazás alkalmazásazonosítója a katalógusban. Az egyetlen bérlőben regisztrált alkalmazások ugyanazt iss a jogcímet kapják az SCIM-kérésekkel. Az összes egyéni alkalmazás alkalmazásazonosítója: 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. A Azure AD kiépítési szolgáltatás által létrehozott jogkivonatot csak teszteléshez szabad használni. Éles környezetben nem szabad használni.

A mintakódban a kérelmek hitelesítése a Microsoft.AspNetCore.Authentication.JwtBearer csomag használatával történik. A következő kód kikényszeríti, hogy a szolgáltatás bármely végpontjára irányuló kérések hitelesítése a Azure AD által adott bérlőhöz kiadott tulajdonosi jogkivonattal történik:

public void ConfigureServices(IServiceCollection services)
{
    if (_env.IsDevelopment())
    {
        ...
    }
    else
    {
        services.AddAuthentication(options =>
        {
            options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
            options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
        })
            .AddJwtBearer(options =>
            {
                options.Authority = " https://sts.windows.net/12345678-0000-0000-0000-000000000000/";
                options.Audience = "8adf8e6e-67b2-4cf2-a259-e3dc5476c621";
                ...
            });
    }
    ...
}

public void Configure(IApplicationBuilder app)
{
    ...
    app.UseAuthentication();
    app.UseAuthorization();
    ...
}

Egy tulajdonosi jogkivonatra is szükség van a megadott Postman-tesztek használatához és a helyi hibakereséshez a localhost használatával. A mintakód ASP.NET Core környezetek használatával módosítja a hitelesítési beállításokat a fejlesztési szakaszban, és engedélyezi az önaláírt token használatát.

További információ a ASP.NET Core több környezetéről: Több környezet használata ASP.NET Core.

A következő kód kikényszeríti, hogy a szolgáltatás bármely végpontjára irányuló kérések egy egyéni kulccsal aláírt tulajdonosi jogkivonattal legyenek hitelesítve:

public void ConfigureServices(IServiceCollection services)
{
    if (_env.IsDevelopment())
    {
        services.AddAuthentication(options =>
        {
            options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
            options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
        })
        .AddJwtBearer(options =>
        {
            options.TokenValidationParameters =
                new TokenValidationParameters
                {
                    ValidateIssuer = false,
                    ValidateAudience = false,
                    ValidateLifetime = false,
                    ValidateIssuerSigningKey = false,
                    ValidIssuer = "Microsoft.Security.Bearer",
                    ValidAudience = "Microsoft.Security.Bearer",
                    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("A1B2C3D4E5F6A1B2C3D4E5F6"))
                };
        });
    }
...

Küldjön GET kérést a jogkivonat-vezérlőnek egy érvényes tulajdonosi jogkivonat lekéréséhez. A GenerateJSONWebToken metódus felelős a fejlesztéshez konfigurált paramétereknek megfelelő jogkivonat létrehozásáért:

private string GenerateJSONWebToken()
{
    // Create token key
    SymmetricSecurityKey securityKey =
        new SymmetricSecurityKey(Encoding.UTF8.GetBytes("A1B2C3D4E5F6A1B2C3D4E5F6"));
    SigningCredentials credentials =
        new SigningCredentials(securityKey, SecurityAlgorithms.HmacSha256);

    // Set token expiration
    DateTime startTime = DateTime.UtcNow;
    DateTime expiryTime = startTime.AddMinutes(120);

    // Generate the token
    JwtSecurityToken token =
        new JwtSecurityToken(
            "Microsoft.Security.Bearer",
            "Microsoft.Security.Bearer",
            null,
            notBefore: startTime,
            expires: expiryTime,
            signingCredentials: credentials);

    string result = new JwtSecurityTokenHandler().WriteToken(token);
    return result;
}

Felhasználók kiépítésének és megszüntetésének kezelése

1. példa. A szolgáltatás lekérdezése egyező felhasználóhoz

Azure AD lekérdezi egy felhasználó szolgáltatását egy externalId olyan attribútumértékkel, amely megfelel egy felhasználó mailNickname attribútumértékének Azure AD. A lekérdezés http-kérésként van kifejezve, például ebben a példában, amelyben a jyoung egy felhasználó mailNickname-jének mintája Azure AD.

Megjegyzés

Ez csak egy példa. Nem minden felhasználó rendelkezik mailNickname attribútummal, és előfordulhat, hogy a felhasználó értéke nem egyedi a címtárban. Emellett az egyeztetéshez használt attribútum (amely ebben az externalIdesetben) konfigurálható az Azure AD attribútumleképezésekben.

GET https://.../scim/Users?filter=externalId eq jyoung HTTP/1.1
 Authorization: Bearer ...

A mintakódban a kérés a szolgáltatás szolgáltatójának QueryAsync metódusára irányuló hívássá lesz lefordítva. Íme a metódus aláírása:

// System.Threading.Tasks.Tasks is defined in mscorlib.dll.  
// Microsoft.SCIM.IRequest is defined in 
// Microsoft.SCIM.Service.  
// Microsoft.SCIM.Resource is defined in 
// Microsoft.SCIM.Schemas.  
// Microsoft.SCIM.IQueryParameters is defined in 
// Microsoft.SCIM.Protocol.  

Task<Resource[]> QueryAsync(IRequest<IQueryParameters> request);

A minta lekérdezésben az attribútum egy adott értékével externalId rendelkező felhasználó esetében a QueryAsync metódusnak átadott argumentumok értékei a következők:

Paraméterek. AlternateFilters.Count: 1
Paraméterek. AlternateFilters.ElementAt(0). AttributePath: "externalId"
Paraméterek. AlternateFilters.ElementAt(0). ComparisonOperator: ComparisonOperator.Equals
Paraméterek. AlternateFilter.ElementAt(0). ComparisonValue: "jyoung"

2. példa. Felhasználó kiépítése

Ha a felhasználó mailNickname attribútumértékével egyező attribútumértékkel rendelkező externalId felhasználó SCIM-végpontjára irányuló lekérdezésre adott válasz nem ad vissza felhasználókat, akkor Azure AD azt kéri, hogy a szolgáltatás a Azure AD egyik felhasználójának megfelelő felhasználót építsen ki. Íme egy példa egy ilyen kérésre:

POST https://.../scim/Users HTTP/1.1
Authorization: Bearer ...
Content-type: application/scim+json
{
   "schemas":
   [
     "urn:ietf:params:scim:schemas:core:2.0:User",
     "urn:ietf:params:scim:schemas:extension:enterprise:2.0User"],
   "externalId":"jyoung",
   "userName":"jyoung@testuser.com",
   "active":true,
   "addresses":null,
   "displayName":"Joy Young",
   "emails": [
     {
       "type":"work",
       "value":"jyoung@Contoso.com",
       "primary":true}],
   "meta": {
     "resourceType":"User"},
    "name":{
     "familyName":"Young",
     "givenName":"Joy"},
   "phoneNumbers":null,
   "preferredLanguage":null,
   "title":null,
   "department":null,
   "manager":null}

A mintakódban a kérés a szolgáltatás szolgáltatójának CreateAsync metódusára irányuló hívássá lesz lefordítva. Íme a metódus aláírása:

// System.Threading.Tasks.Tasks is defined in mscorlib.dll.  
// Microsoft.SCIM.IRequest is defined in 
// Microsoft.SCIM.Service.  
// Microsoft.SCIM.Resource is defined in 
// Microsoft.SCIM.Schemas.  

Task<Resource> CreateAsync(IRequest<Resource> request);

Egy felhasználó kiépítésére irányuló kérésben az erőforrás-argumentum értéke a Microsoft.SCIM.Core2EnterpriseUser osztály egy példánya, amely a Microsoft.SCIM.Schemas kódtárban van meghatározva. Ha a felhasználó kiépítésére irányuló kérés sikeres, akkor a metódus megvalósítása várhatóan a Microsoft.SCIM.Core2EnterpriseUser osztály egy példányát adja vissza, az Azonosító tulajdonság értéke pedig az újonnan kiépített felhasználó egyedi azonosítója lesz.

3. példa. Felhasználó aktuális állapotának lekérdezése

Ha frissíteni szeretne egy olyan felhasználót, akiről ismert, hogy létezik egy SCIM által előtérbelt identitástárolóban, Azure AD a következő kéréssel kéri le a felhasználó aktuális állapotát a szolgáltatásból:

GET ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1
Authorization: Bearer ...

A mintakódban a kérés a szolgáltatás szolgáltatójának RetrieveAsync metódusának hívására lesz lefordítva. Íme a metódus aláírása:

// System.Threading.Tasks.Tasks is defined in mscorlib.dll.  
// Microsoft.SCIM.IRequest is defined in 
// Microsoft.SCIM.Service.  
// Microsoft.SCIM.Resource and 
// Microsoft.SCIM.IResourceRetrievalParameters 
// are defined in Microsoft.SCIM.Schemas 

Task<Resource> RetrieveAsync(IRequest<IResourceRetrievalParameters> request);

A felhasználó aktuális állapotának lekérésére irányuló kérés példájában a paraméterek argumentum értékeként megadott objektum tulajdonságainak értékei a következők:

Azonosító: "54D382A4-2050-4C03-94D1-E769F1D15682"
SchemaIdentifier: urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

4. példa. Frissítendő referenciaattribútum értékének lekérdezése

Ha frissíteni szeretne egy referenciaattribútumot, akkor Azure AD lekérdezi a szolgáltatást annak megállapításához, hogy a szolgáltatás által megnyitott identitástárolóban lévő referenciaattribútum aktuális értéke megegyezik-e az attribútum értékével Azure AD. A felhasználók esetében az egyetlen attribútum, amelynek aktuális értékét így kérdezi le a rendszer, az a felettes attribútum. Íme egy példa egy kérésre annak megállapítására, hogy egy felhasználói objektum kezelői attribútuma jelenleg rendelkezik-e egy bizonyos értékkel: A mintakódban a kérés a szolgáltatás szolgáltatójának QueryAsync metódusára irányuló hívássá lesz lefordítva. A paraméter argumentum értékeként megadott objektum tulajdonságainak értéke a következő:

Paraméterek. AlternateFilters.Count: 2
Paraméterek. AlternateFilters.ElementAt(x). AttributePath: "ID"
Paraméterek. AlternateFilters.ElementAt(x). ComparisonOperator: ComparisonOperator.Equals
Paraméterek. AlternateFilter.ElementAt(x). ComparisonValue: "54D382A4-2050-4C03-94D1-E769F1D15682"
Paraméterek. AlternateFilters.ElementAt(y). AttributePath: "manager"
Paraméterek. AlternateFilters.ElementAt(y). ComparisonOperator: ComparisonOperator.Equals
Paraméterek. AlternateFilter.ElementAt(y). ComparisonValue: "2819c223-7f76-453a-919d-413861904646"
Paraméterek. RequestedAttributePaths.ElementAt(0): "ID"
Paraméterek. SchemaIdentifier: urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

Az x index értéke lehet0, az index értéke pedig y.1 Vagy az x értéke lehet 1 , az y értéke pedig lehet 0. Ez a szűrő lekérdezési paraméter kifejezéseinek sorrendjétől függ.

5. példa. Kérés Azure AD-ról SCIM-végpontra a felhasználó frissítéséhez

Íme egy példa egy kérésre, amely Azure AD egy SCIM-végpontra irányul a felhasználó frissítéséhez:

PATCH ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1
Authorization: Bearer ...
Content-type: application/scim+json
{
    "schemas": 
    [
      "urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations":
    [
      {
        "op":"Add",
        "path":"manager",
        "value":
          [
            {
              "$ref":"http://.../scim/Users/2819c223-7f76-453a-919d-413861904646",
              "value":"2819c223-7f76-453a-919d-413861904646"}]}]}

A mintakódban a kérés a szolgáltató UpdateAsync metódusának hívására lesz lefordítva. Íme a metódus aláírása:

// System.Threading.Tasks.Tasks and 
// System.Collections.Generic.IReadOnlyCollection<T>  // are defined in mscorlib.dll.  
// Microsoft.SCIM.IRequest is defined in
// Microsoft.SCIM.Service.
// Microsoft.SCIM.IPatch, 
// is defined in Microsoft.SCIM.Protocol. 

Task UpdateAsync(IRequest<IPatch> request);

A felhasználó frissítésére irányuló kérés példájában a javítás argumentum értékeként megadott objektum az alábbi tulajdonságértékekkel rendelkezik:

Argumentum	Érték
`ResourceIdentifier.Identifier`	"54D382A4-2050-4C03-94D1-E769F1D15682"
`ResourceIdentifier.SchemaIdentifier`	`urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`
`(PatchRequest as PatchRequest2).Operations.Count`	1
`(PatchRequest as PatchRequest2).Operations.ElementAt(0).OperationName`	`OperationName.Add`
`(PatchRequest as PatchRequest2).Operations.ElementAt(0).Path.AttributePath`	Manager
`(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.Count`	1
`(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.ElementAt(0).Reference`	`http://.../scim/Users/2819c223-7f76-453a-919d-413861904646`
`(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.ElementAt(0).Value`	2819c223-7f76-453a-919d-413861904646

6. példa. Felhasználó kivonása

Ha le szeretne bontani egy felhasználót egy SCIM-végpont előtt lévő identitástárolóból, Azure AD a következőhöz hasonló kérést küld:

DELETE ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1
Authorization: Bearer ...

A mintakódban a kérés a szolgáltatás szolgáltatójának DeleteAsync metódusára irányuló hívássá lesz lefordítva. Íme a metódus aláírása:

// System.Threading.Tasks.Tasks is defined in mscorlib.dll.  
// Microsoft.SCIM.IRequest is defined in 
// Microsoft.SCIM.Service.  
// Microsoft.SCIM.IResourceIdentifier, 
// is defined in Microsoft.SCIM.Protocol. 

Task DeleteAsync(IRequest<IResourceIdentifier> request);

A resourceIdentifier argumentum értékeként megadott objektum az alábbi tulajdonságértékekkel rendelkezik a felhasználó megszüntetésére irányuló kérés példájában:

ResourceIdentifier.Identifier: "54D382A4-2050-4C03-94D1-E769F1D15682"
ResourceIdentifier.SchemaIdentifier: urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

AZ SCIM-végpont integrálása a Azure AD Provisioning Service szolgáltatással

Azure AD konfigurálható úgy, hogy automatikusan kiépítsen hozzárendelt felhasználókat és csoportokat az SCIM 2.0 protokoll egy adott profilját implementáló alkalmazásokhoz. A profil jellemzői a Azure AD SCIM implementációjának ismertetése című témakörben találhatók.

A követelményekkel való kompatibilitásról az alkalmazásszolgáltatónál vagy az alkalmazásszolgáltató dokumentációjában talál információt.

Fontos

A Azure AD SCIM implementációja a Azure AD felhasználókiépítési szolgáltatásra épül, amely úgy lett kialakítva, hogy folyamatosan szinkronban tartsa a felhasználókat a Azure AD és a célalkalmazás között, és nagyon speciális standard műveleteket valósít meg. A Azure AD Kiépítési szolgáltatás viselkedésének megértéséhez fontos megérteni ezeket a viselkedéseket. További információkért lásd a kiépítési ciklusok: Kezdeti és növekményes szakaszt a kiépítés működésében.

Első lépések

Az ebben a cikkben ismertetett SCIM-profilt támogató alkalmazások a Azure AD alkalmazáskatalógus "nem katalógusbeli alkalmazás" funkciójával csatlakoztathatók Azure AD. A csatlakozás után Azure AD 40 percenként futtat egy szinkronizálási folyamatot, amelyben lekérdezi az alkalmazás SCIM-végpontját a hozzárendelt felhasználók és csoportok számára, majd létrehozza vagy módosítja őket a hozzárendelés részleteinek megfelelően.

ScIM-et támogató alkalmazás csatlakoztatása:

Jelentkezzen be a Azure AD portálra. P2-licenccel rendelkező Azure AD ingyenes próbaverziójához a fejlesztői programra való regisztrációval férhet hozzá
Válassza ki a vállalati alkalmazásokat a bal oldali panelen. Megjelenik az összes konfigurált alkalmazás listája, beleértve a katalógusból hozzáadott alkalmazásokat is.
Válassza az + Új alkalmazás>+ Saját alkalmazás létrehozása lehetőséget.
Adja meg az alkalmazás nevét, válassza az "Integráljon minden olyan alkalmazást, amely nem található a katalógusban" lehetőséget, majd válassza a Hozzáadás lehetőséget egy alkalmazásobjektum létrehozásához. Az új alkalmazás megjelenik a vállalati alkalmazások listájában, és megnyílik az alkalmazásfelügyeleti képernyője.

Az alábbi képernyőképen a Azure AD alkalmazáskatalógus látható:

Megjegyzés

Ha a régi alkalmazáskatalógus-felületet használja, kövesse az alábbi képernyős útmutatót.

Az alábbi képernyőképen a Azure AD régi alkalmazáskatalógus-felület látható:
Az alkalmazásfelügyeleti képernyőn válassza a kiépítés lehetőséget a bal oldali panelen.
A Kiépítési mód menüben válassza az Automatikus lehetőséget.

Az alábbi képernyőképen a kiépítési beállítások konfigurálása látható a Azure Portal:
A Bérlő URL-címe mezőben adja meg az alkalmazás SCIM-végpontjának URL-címét. Például: https://api.contoso.com/scim/
Ha az SCIM-végponthoz nem Azure AD kiállítótól származó OAuth-tulajdonosi jogkivonatra van szükség, másolja a szükséges OAuth-tulajdonosi jogkivonatot az opcionális Titkos jogkivonat mezőbe. Ha ez a mező üres, Azure AD az egyes kérésekkel együtt Azure AD által kibocsátott OAuth-tulajdonosi jogkivonatot tartalmaz. Az Azure AD identitásszolgáltatóként használó alkalmazások érvényesíthetik ezt a Azure AD által kibocsátott jogkivonatot.

Megjegyzés

Nem ajánlott üresen hagyni ezt a mezőt, és a Azure AD által létrehozott jogkivonatra támaszkodni. Ez a lehetőség elsősorban tesztelési célokra érhető el.
Válassza a Kapcsolat tesztelése lehetőséget, hogy Azure AD megpróbáljon csatlakozni az SCIM-végponthoz. Ha a kísérlet sikertelen, hibaüzenet jelenik meg.

Megjegyzés

A kapcsolat tesztelése lekérdezi az SCIM-végpontot egy nem létező felhasználóhoz, és véletlenszerű GUID-t használ a Azure AD konfigurációban kiválasztott egyező tulajdonságként. A várt helyes válasz a HTTP 200 OK egy üres SCIM ListResponse üzenettel.
Ha az alkalmazáshoz való kapcsolódási kísérlet sikeres, a rendszergazdai hitelesítő adatok mentéséhez kattintson a Mentés gombra.
A Leképezések szakaszban két választható attribútumleképezés-készlet található: egy a felhasználói és egy a csoportobjektumokhoz. Jelölje ki mindegyiket a Azure AD és az alkalmazás között szinkronizált attribútumok áttekintéséhez. Az egyező tulajdonságokként kiválasztott attribútumok az alkalmazás felhasználóinak és csoportjainak frissítési műveletekhez való egyeztetésére szolgálnak. A módosítások véglegesítéséhez válassza a Mentés lehetőséget.

Megjegyzés

A csoportobjektumok szinkronizálását a "csoportok" leképezés letiltásával is letilthatja.
A Beállítások területen a Hatókör mező határozza meg, hogy mely felhasználók és csoportok legyenek szinkronizálva. Válassza a Csak a hozzárendelt felhasználók és csoportok szinkronizálása lehetőséget (ajánlott) a Felhasználók és csoportok lapon hozzárendelt felhasználók és csoportok szinkronizálásához.
A konfiguráció befejezése után állítsa be a kiépítési állapototBe értékre.
Válassza a Mentés lehetőséget a Azure AD kiépítési szolgáltatás elindításához.
Ha csak a hozzárendelt felhasználók és csoportok szinkronizálása javasolt, válassza a Felhasználók és csoportok lapot. Ezután rendelje hozzá a szinkronizálni kívánt felhasználókat vagy csoportokat.

A kezdeti ciklus elindítása után a bal oldali panelen kiválaszthatja a kiépítési naplókat a folyamat figyeléséhez, amely az alkalmazás kiépítési szolgáltatása által végrehajtott összes műveletet megjeleníti. A Azure AD kiépítési naplók olvasásával kapcsolatos további információkért lásd: Jelentéskészítés a felhasználói fiókok automatikus kiépítéséről.

Megjegyzés

A kezdeti ciklus végrehajtása hosszabb időt vesz igénybe, mint a későbbi szinkronizálások, amelyek körülbelül 40 percenként történnek, amíg a szolgáltatás fut.

Az alkalmazás közzététele a Azure AD alkalmazáskatalógusban

Ha egynél több bérlő által használt alkalmazást készít, elérhetővé teheti azt a Azure AD alkalmazáskatalógusban. A szervezetek egyszerűen felfedezhetik az alkalmazást, és konfigurálhatja a kiépítést. Az alkalmazás közzététele a Azure AD gyűjteményben és a kiépítés elérhetővé tétele mások számára egyszerű. Tekintse meg a lépéseket itt. A Microsoft együttműködik Önnel, hogy integrálja alkalmazását a katalógusunkba, tesztelje a végpontot, és kiadja a bevezetési dokumentációt az ügyfelek számára.

Katalógus előkészítési ellenőrzőlistája

Az ellenőrzőlistával gyorsan előkészítheti az alkalmazást, és az ügyfelek zökkenőmentes üzembe helyezést érhetnek el. Az információk a katalógusba való előkészítéskor lesznek összegyűjtve.

SCIM 2.0-s felhasználói és csoportvégpontok támogatása (csak egy szükséges, de mindkettő ajánlott)
Bérlőnként legalább 25 kérés támogatása, hogy a felhasználók és csoportok kiépítése és megszüntetése késedelem nélkül történjen (kötelező)
Mérnöki és támogatási kapcsolattartók létrehozása az ügyfelek számára a katalógus előkészítése után (kötelező)
3 Az alkalmazás nem lejáró teszt hitelesítő adatai (kötelező)
Az OAuth engedélyezési kód megadásának vagy egy hosszú élettartamú jogkivonat támogatásának támogatása az alábbiak szerint (Kötelező)
Mérnöki és támogatási kapcsolattartó pont létrehozása az ügyfelek támogatásához a katalógus előkészítése után (kötelező)
Sémafelderítés támogatása (kötelező)
Több csoporttagság frissítésének támogatása egyetlen PATCH használatával
SCIM-végpont nyilvános dokumentálása

Összekötők kiépítésének engedélyezése az alkalmazáskatalógusban

Az SCIM-specifikáció nem határoz meg SCIM-specifikus sémát a hitelesítéshez és engedélyezéshez, és a meglévő iparági szabványok használatára támaszkodik.

Engedélyezési módszer	Előnyök	Hátrányok	Támogatás
Felhasználónév és jelszó (Azure AD nem ajánlott vagy támogatott)	Könnyen implementálható	Nem biztonságos – a Pa$$word nem számít	Új katalógusbeli vagy nem katalógusbeli alkalmazások esetén nem támogatott.
Hosszú élettartamú tulajdonosi jogkivonat	A hosszú élettartamú jogkivonatokhoz nincs szükség arra, hogy egy felhasználó jelen legyen. A rendszergazdák egyszerűen használhatják őket a kiépítés beállításakor.	A hosszú élettartamú jogkivonatok nehezen oszthatók meg egy rendszergazdával anélkül, hogy nem használnak nem biztonságos módszereket, például e-maileket.	Katalógusbeli és nem katalógusbeli alkalmazások esetén támogatott.
OAuth engedélyezési kód megadása	A hozzáférési jogkivonatok sokkal rövidebb élettartamúak, mint a jelszavak, és olyan automatikus frissítési mechanizmusuk van, amellyel a hosszú élettartamú tulajdonosi jogkivonatok nem rendelkeznek. A valódi felhasználónak jelen kell lennie a kezdeti engedélyezés során, és hozzá kell adnia az elszámoltathatóság szintjét.	Egy felhasználónak jelen kell lennie. Ha a felhasználó elhagyja a szervezetet, a jogkivonat érvénytelen, és az engedélyezést újra be kell fejezni.	Katalógusbeli alkalmazások esetén támogatott, a nem katalógusbeli alkalmazások esetében azonban nem. Rövid távú tesztelési célokra azonban megadhat egy hozzáférési jogkivonatot a felhasználói felületen titkos jogkivonatként. A katalóguson kívüli OAuth-kód megadásának támogatása a katalógusalkalmazás konfigurálható hitelesítési/jogkivonat-URL-címeinek támogatása mellett a teendőlistán is szerepel.
OAuth-ügyfél hitelesítő adatainak megadása	A hozzáférési jogkivonatok sokkal rövidebb élettartamúak, mint a jelszavak, és olyan automatikus frissítési mechanizmusuk van, amellyel a hosszú élettartamú tulajdonosi jogkivonatok nem rendelkeznek. Az engedélyezési kód megadása és az ügyfél hitelesítő adatai is ugyanazt a hozzáférési jogkivonatot hozzák létre, így a módszerek közötti váltás átlátható az API számára. A kiépítés automatizálható, és az új jogkivonatok felhasználói beavatkozás nélkül, csendesen kérhetők.		Katalógusbeli alkalmazások esetén támogatott, a nem katalógusbeli alkalmazások esetében azonban nem. Rövid távú tesztelési célokra azonban megadhat egy hozzáférési jogkivonatot a felhasználói felületen titkos jogkivonatként. A katalóguson kívüli OAuth-ügyfél hitelesítő adatainak támogatása a teendőlistán szerepel.

Megjegyzés

A jogkivonatmezőt nem ajánlott üresen hagyni a Azure AD kiépítési konfigurációs egyéni alkalmazás felhasználói felületén. A létrehozott jogkivonat elsősorban tesztelési célokra érhető el.

OAuth-kód engedélyezési folyamata

A kiépítési szolgáltatás támogatja az engedélyezési kód megadását , és miután elküldte az alkalmazás katalógusban való közzétételére vonatkozó kérelmét, csapatunk együttműködik Önnel a következő információk gyűjtésében:

Engedélyezési URL-cím, az ügyfél url-címe, amely a felhasználó-ügynök átirányításán keresztüli engedélyezést kér az erőforrás tulajdonosától. A rendszer átirányítja a felhasználót erre az URL-címre a hozzáférés engedélyezéséhez.
Jogkivonatcsere URL-címe, amely az ügyfél url-címe egy hozzáférési jogkivonat engedélyezési engedélyének cseréjéhez, jellemzően ügyfél-hitelesítéssel.
Az ügyfél-azonosító, az engedélyezési kiszolgáló egy ügyfélazonosítót ad ki a regisztrált ügyfélnek, amely egy egyedi sztring, amely az ügyfél által megadott regisztrációs adatokat jelöli. Az ügyfélazonosító nem titkos; az erőforrás tulajdonosa számára elérhető, és nem használható egyedül az ügyfél-hitelesítéshez.
Ügyfélkulcs, az engedélyezési kiszolgáló által létrehozott titkos kód, amely csak az engedélyezési kiszolgáló számára ismert egyedi érték lehet.

Megjegyzés

Az engedélyezési URL-cím és a tokencsere URL-címe bérlőnként jelenleg nem konfigurálható.

Megjegyzés

Az OAuth v1 nem támogatott az ügyfél titkos kódjának felfedése miatt. Az OAuth v2 támogatott.

Ajánlott eljárások (ajánlott, de nem kötelező):

Több átirányítási URL-cím támogatása. A rendszergazdák a "portal.azure.com" és a "aad.portal.azure.com" kiépítést is konfigurálhatják. A több átirányítási URL-cím támogatása biztosítja, hogy a felhasználók mindkét portálról engedélyezhessék a hozzáférést.
Több titkos kód támogatása az egyszerű megújításhoz, állásidő nélkül.

OAuth-kód engedélyezési folyamatának beállítása

Jelentkezzen be a Azure Portal, lépjen a Vállalati alkalmazások>alkalmazáskiépítési> lapra, és válassza az Engedélyezés lehetőséget.
1. Azure Portal átirányítja a felhasználót az engedélyezési URL-címre (a harmadik féltől származó alkalmazás bejelentkezési oldalára).
2. Rendszergazda hitelesítő adatokat biztosít a harmadik féltől származó alkalmazásnak.
3. A harmadik féltől származó alkalmazás visszairányítja a felhasználót a Azure Portal, és megadja az engedélyezési kódot
4. Azure AD Kiépítési szolgáltatás meghívja a jogkivonat URL-címét, és megadja az engedélyezési kódot. A külső alkalmazás a hozzáférési jogkivonattal, a frissítési jogkivonattal és a lejárati dátummal válaszol
A kiépítési ciklus kezdetekor a szolgáltatás ellenőrzi, hogy az aktuális hozzáférési jogkivonat érvényes-e, és szükség esetén kicseréli azt egy új jogkivonatra. A hozzáférési jogkivonatot az alkalmazáshoz küldött minden kérés tartalmazza, és a kérés érvényességét minden kérés előtt ellenőrzi a rendszer.

Megjegyzés

Bár nem lehet beállítani az OAuth-t a nem katalógusbeli alkalmazásokon, manuálisan létrehozhat egy hozzáférési jogkivonatot az engedélyezési kiszolgálóról, és titkos jogkivonatként beírhatja azt egy nem katalógusbeli alkalmazásba. Ez lehetővé teszi, hogy ellenőrizze az SCIM-kiszolgáló és a Azure AD Provisioning Service kompatibilitását az alkalmazáskatalógusba való előkészítés előtt, amely támogatja az OAuth-kód megadását.

Hosszú élettartamú OAuth-tulajdonosi jogkivonatok: Ha az alkalmazás nem támogatja az OAuth engedélyezési kód engedélyezési folyamatát, hozzon létre egy hosszú élettartamú OAuth-tulajdonosi jogkivonatot, amelyet a rendszergazda használhat a kiépítési integráció beállításához. A jogkivonatnak véglegesnek kell lennie, különben a kiépítési feladat karanténba kerül a jogkivonat lejáratakor.

További hitelesítési és engedélyezési módszerekért tudassa velünk a UserVoice-on.

Katalógus piaci bevezetési ellenőrzőlistája

A közös integráció ismertségének és igényének növelése érdekében javasoljuk, hogy frissítse a meglévő dokumentációt, és erősítse az integrációt a marketingcsatornákban. Javasoljuk, hogy az indítás támogatásához végezze el a következő ellenőrzőlistát:

Győződjön meg arról, hogy az értékesítési és az ügyfélszolgálati csapatok tisztában vannak az integrációs képességekkel, készen állnak és tudnak beszélni. Tájékoztathatja a csapatokat, gyanakvásokat adhat nekik, és belefoglalhatja az értékesítési anyagokba való integrációt.
Írjon egy blogbejegyzést vagy sajtóközleményt, amely leírja a közös integrációt, az előnyöket és az első lépések módját. Példa: Imprivata és Azure AD Sajtóközlemény
Használja ki a közösségi médiát, például a Twittert, a Facebookot vagy a LinkedInt az ügyfelek integrációjának elősegítéséhez. Ügyeljen arra, hogy belefoglaljuk @AzureAD , hogy újra meg tudjuk adni a bejegyzést. Példa: Imprivata Twitter Post
Hozza létre vagy frissítse a marketingoldalakat/webhelyeket (pl. integrációs oldal, partneroldal, díjszabási oldal stb.), hogy tartalmazza a közös integráció elérhetőségét. Példa: Pingboard integration Page, Smartsheet integration page, Monday.com pricing page
Hozzon létre egy súgóközpont-cikket vagy műszaki dokumentációt arról, hogyan kezdhetik meg az ügyfelek az első lépéseket. Példa: Envoy + Microsoft Azure AD integráció.
Értesítse az ügyfeleket az új integrációról az ügyfélkommunikáción keresztül (havi hírlevelek, e-mail kampányok, termékkiadási megjegyzések).

Következő lépések

SCIM-mintavégpont fejlesztése A felhasználók átadásának és megszüntetésének automatizálása SaaS-alkalmazásokban Attribútumleképezések testreszabása felhasználókiépítéshez Írási kifejezések írása attribútumleképezésekhez Hatókörszűrők a felhasználókiépítési fiókkiépítési értesítésekhez Az SaaS-alkalmazások integrálásával kapcsolatos oktatóanyagok listája