Pojmy ako manažment identít, cloud riešenie, štandard, škálovateľnosť, univerzalita a mnohé daľšie termíny, sú vlastnosťami toho, čím vlastne protokol SCIM je. V tejto publikácií sa dozvieme čo to je, na čo hlavne slúži a na základe príkladov aj to, ako funguje. Po zoznámení sa s týmto protokolom sa na konci dozvieme aj to, prečo práve tento protokol je vhodný na riešenie manažmentu identít, respektíve používateľov.
Čo je SCIM?
Samotná skratka “SCIM” reprezenutuje “System for Cross-domain Identity Management” alebo po slovensky “Systém na správu identit medzi doménami”. Tento systém je štandardizovaný spôsob reprezentácie používateľov, skupín a všetkého súvisiaceho. Druhou dôležitou vlastnosťou je, že SCIM štandardizuje, ktorými sa spracúvajú a reprezentujú dáta. Hovoríme o vytváraní, vyhľadávaní, aktualizovaní a vymazávaní. Vo veľkej miere tomu môžeme hovoriť aj API model (Application programming interface).
Spomenuté dve časti SCIM-u sú rozdelené do dvoch štandardov:
- základná (Core) schéma — určuje reprezentáciu dát a spôsoby jej rozšírenia
- protokol — slúži na prácu s dátami
Prečo sú štandardy ako SCIM dôležité?
Pretože vďaka ním je kód zrozumiteľný pre akýchkoľvek vývojárov a zároveň sa takýto kód ľahko upravuje, ladí a udržiava. Predstavte si, že pracujete vo firme ako marketér. Máte na starosti sociálne siete a ďalšie iné služby. Pre príklad potrebujete na svoju prácu účet na Slack, Gmail, LDAP a iné ďalšie. Vďaka systému SCIM budete vedieť obstarávať všetky účty naraz. Všetky účty budú vytvorené z rovnakých dát a rovnakého hesla. Zabudnete heslo? Cez systém s implementovaným SCIM-om si budete môcť zmeniť heslo na všetkých účtoch. Alebo ste si zmenili váš business email? V systéme so SCIM-om si ho zmeníte a ten automaticky aktualizuje tento údaj na všetkých vašich účtoch.
Ak niekto spomenie takéto štandardy je jasné, že si hneď vybavíme zložité, prepracované, častokrát aj nudné a neprehľadné reprezentácie dát. Nie vždy to tak ale musí byť. V prípade SCIM-u sú všetky údaje reprezentované vo forme schémy ako JSON a protokol je založený na REST architektúre. Ak sa začítate hlbšie do článku (v čo dúfam), na konci si pravdepodobne poviete, že ste sa s aspektami SCIM-u už stretli.
Čas implementovať!
SCIM nebol vyvinutý nato aby nahradzoval existujúce systémy na správu používateľov ale skôr na to, aby spolupracoval a kooperoval so štandardnými rozhraniami. Myslíme tým všetko od SQL databáz, LDAP, NoSQL, až po SOAP alebo REST API. SCIM má málo požiadaviek vzhľadom na to, čo všetko je potrebné implementovať. Ale ako odporúčanie by som povedal, že je lepšie implementovať základné funkcie a hlavne tie, ktoré pre firmu majú zmysel a prípadne neskôr portfólio funkcií rozšíriť.
Veľkým plusom v používaní štandardného rozhrania je to, že tu neexistuje potreba dokumentovať každý systém separátne. Ak už máte jednotný spôsob na spravovanie používateľov, dokumentácia sa nachádza v samotnej špecifikácii. V tomto momente je dôležité spomenúť, že špecifikácia SCIM-u sa zameriava skôr na potreby pre správu používateľov a nie na zabezpečenie. Pre tieto veci ako napríklad zabezpečený prístup a oprávnenia zabezpečuje iný štandard. Príkladom takého štandardu môže byť OAuth.
Toto je schéma, zoznámte sa.
V SCIM-e je všetko odvodené od typu zdroja (resource type) a zároveň zdieľa sadu spoločných atribútov. Je vysoko pravdepodobné, že ste sa už s týmto súborom atribútov stretli. Pretože sú bežné takmer vo všetkých systémoch, ktoré spravujú identity. Všetky SCIM-ovské typy sú identifikované schémou v tzv. “payload” teda tele HTTP požiadavky alebo odpovede. Príklad môžete vidieť nižšie. Jedná sa o schému Používateľa a teda “User Schema”.
- id - definuje globálny jedinečný identifikátor
- externalId - identifikuje zdroj údajov a môžeme povedať, že by mohlo ísť o ID vašej databázy odkiaľ získavate vaše dáta
- meta - tiež známe ako metadata určujú napríklad, kedy bol zdroj vytvorený, môžeme tu taktiež vidieť lastModified a location v tvare URL z ktorých isto viete vydedukovať čo definujú
Tu vám ukážem príklad zdroja v podobe JSON:
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "1252c283-4a56-123a-524368788512",
"externalId": "112471",
"meta": {
"resourceType": "User",
"created": "2018-01-04T13:37:15Z",
"lastModified": "2018-01-05T13:37:15Z",
"location": "https://ex.com/v2/Users/1252c283-4a56-123a-524368788512"
}
}
Jednou z hlavných výhod SCIM je to, že máte možnosť rozšíriť polia kódu znázorneného vyššie o svoje vlastné schémy alebo typy resp. atribúty. Ako to myslím? Takto:
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "1252c283-4a56-123a-524368788512",
"externalId": "112471",
"meta": {
"resourceType": "User",
"created": "2018-01-04T13:37:15Z",
"lastModified": "2018-01-05T13:37:15Z",
"location": "https://ex.com/v2/Users/1252c283-4a56-123a-524368788512"
}
"Obľúbená farba":"Zelená",
"Obľúbený herec":"Brad Pitt",
"Obľúbené sladkosti":"Všetky",
...
}
Hľadáš používateľov? Pozri si koncový bod /Users.
Centrom všetkých systémov manažmentu identít je koncept používateľov. Základná schéma definuje súbor atribútov, ktoré by mali byť pre väčšinu používateľov bežné ale rovnako aj niektoré, ktoré bežné nie sú. Ako to myslím? No bežný atribút, ktorý popisuje používateľa je jeho meno, priezvisko, prezývka, titul, telefónne číslo a pod. Na druhej strane sú atribúty, ktoré bežné niesu. Myslíme tým ICQ číslo, obľúbená farba, obľúbené jedlo, obľúbený herec a i.
User? Čo to je?
V takmer všetkých systémoch, ktoré pracujú a manipulujú s používateľmi, nájdeme tieto atribúty. Znázornené atribúty nižšie považujeme za bežné.
- používateľské meno
- meno a priezvisko (samozrejme aj iné napríklad stredné, rodné, prezývky atp.)
- kontakty (telefón, e-mail, fax atp.)
- skupiny
- lokalizačné údaje (časové pásmo, lokalita, bydlisko atp.)
- heslo
Keď sa zastavíme pri heslách, pri SCIM sú trochu špeciálne. Je to atribút spracovaný v podobe štandardu, ale pri žiadosti zo zdroja ho nikdy nemôžete zobraziť. Nemôžete získať zoznam hesiel ani heslo konkrétneho používateľa. Čo však prostredníctvom SCIM viete, je heslá vyhľadať a overiť. V zmysle vyhľadať berieme to, že systém SCIM si ho vie získať pre vlastnú potrebu ale nijak vám ho nevie zobraziť.
Menej časté atribúty sú napríklad sociálne siete, skype meno, obľúbená farba a tomu podobné. Takéto atribúty sú však veľmi pekné a užitočné na obohatenie a rozmanitosť špecifikácie používateľa.
Používateľov poznáš. A čo tak Skupiny?
Môžeme povedať, že skupiny nie sú až tak potrebné na správu používateľov. Ale na druhej strane robia systémy na manažment identít viac prehľadnejšie. Teda utvárajú akýsi poriadok v systéme. Skupiny v SCIM obsahujú poväčšine len názov a zoznam členov.
Už vieme čo je čo, teraz poďme s protokolom pracovať!
V tejto časti si dovolím povedať, že je vysoko pravdepodobné, že všetko čo spomeniem nižšie určite poznáte. Prečo? Lebo celá funkcionalita SCIM protokolu je založená na REST architektúre. Na prácu so SCIM-om používame nasledovné metódy:
- GET: Získa existujúci zdroj, buď podľa ID alebo podľa iných údajov, ktoré definujeme vo vyhľadávaní.
- POST: Odoslanie žiadosti na koncový bod za účelom vytvorenia nových záznamov.
- PUT: Nahradenie existujúcich zdrojov.
- PATCH: Aktualizácia atribútov existujúceho zdroja.
- DELETE: Zmazanie zdroja.
Všade samé koncové body a endpointy, čo to je?
Každý resource type je reprezentovaný pod koncovým bodom pomenovaný podľa svojho typu. Zložitá veta? Nebojte sa. Jednoducho používatelia, teda Users, majú koncový bod /Users. Skupiny, teda Groups, zase majú koncový bod /Groups. Stále nič? Tak ak by šlo o autá, teda Cars, tak koncový bod bude /Cars.
Tak teda viem kde sa čo nachádza, ale ako to vyhľadám?
Veľmi dobrou otázkou je, ako SCIM vyhľadáva. Používa sa na to metóda GET, ktorú ste si už určite vyššie všimli. Jedná sa o regulárnu požiadavku, ktorú nasmerujeme na požadovaný koncový bod. Následne sa nám vráti zoznam všetkých zdrojov požadovaného typu z nami zvoleného koncového bodu.
Hľadanie môžeme nastaviť akokoľvek chceme. Môžeme hľadať konkrétne údaje, alebo všeobecne a to všetko vďaka filtrom. Príklad: Vylistuj všetkých používateľov čo sú na koncovom bode /Users, ale zároveň len tých, ktorých meno sa začína na ,,P”, majú viac ako 25 rokov a používajú skype. Výsledok nám vráti JSON s odpoveďou na našu požiadavku. Môže to vyzerať aj nejako takto:
{
"totalResults": 33,
"itemsPerPage": 10,
"startIndex": 1,
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"Resource": [{
…
}]
}
Musíme podotknúť aj fakt, že vyhľadávanie pomocou GET metódy na získavanie informácií nieje často ideálne. Hlavne nie je ideálne na zobrazovanie hesiel alebo osobných identifikátorov v adrese URL. GET požiadavky sú RESTful charakteru a zobrazujú parametre v URL. Existuje preto bezpečnejší spôsob, ktorý je ideálnejší na vyhľadávanie citlivých údajov akými sú napríklad poverenia alebo iné osobné informácie. Jednoducho existuje špeciálny koncový bod /.search. Pridáme ho hosta a odošleme požiadavku na vyhľadanie za pomoci metódy POST, pričom do tela požiadavky pridáme to čo chceme hľadať. Takýto typ je oveľa bezpečnejší, pretože sa údaje nelistujú v URL.
Jednoduchý príklad aj s filtrom aby sme sa porozumeli:
POST /.search <- Metóda a zvolený endpoint
Host: example.com <- Adresa hosta
Accept: application/scim+json <- Druh akceptovanej požiadavky
Content-Type: application/scim+json <- Forma požiadavky
Authorization: Bearer h480djs93hd8 <- Autentifikačné údaje
Content-Length: ...
<- Odtiaľ pokračuje payload a teda telo požiadavky
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
"attributes": ["displayName", "userName"],
"filter":
"displayName sw \"K\"", <- Hľadáme používateľov ktorých atribút
displayName začína na "K"
"startIndex": 1,
"count": 10
}
Ak nerozumieme aj napriek príkladu nebojte sa, pretože ďalší odsek sa tejto problematike bude venovať bližšie.
O akom filtri je reč?
Jednou z najsilnejších funkcií SCIM a zároveň jednou z naj-komplexnejších je schopnosť odosielať filtrované požiadavky na hľadanie. Už sme to vyššie spomenuli ale teraz tak aby ste tomu porozumeli v úplnej podobe. Príklad: Posielame požiadavku na vyhľadanie s filtrom v podobe ,,/Users?filter=username eq “Patrik””, alebo po slovensky povedané: ,,ukáž mi všetkých používateľov, ktorých atribút “username” je “Patrik”.
Príklady na vyhľadávanie pomocou GET metódy na koncový bod kde sa nachádzajú používatelia:
Vyhľadávanie užívateľov, ktorých atribút userName sa rovná stringu "John"
/Users?filter=userName eq "John"
Vyhľadávanie užívateľov, ktorých atribút emails.value končí stringom "tuke.sk" a zároveň boli upravovaný pred 1. januárom 2015.
/Users?filter=emails.value ew "tuke.sk" and meta.lastModified lt "2015-01-01T00:00:00Z"
Vyhľadávanie užívateľov, ktorých atribút familyName obsahuje string "Doe"
/Users?filter=name.familyName co "Doe"
Vyhľadávanie užívateľov, ktorých atribút title nieje prázdny
/Users?filter=title pr
Vyhľadávanie užívateľov podľa atribútu emails pričom subatribút type sa rovná stringu "work" a atribút value obsahuje string "gmail.com"
/Users?filter=filter=emails[type eq "work" and value co "@gmail.com"]
Vyhľadávanie skupín, ktorých atribút displayName sa rovná stringu "Developers" alebo ten istý atribút sa rovná stringu "Devs"
/Groups?filter=displayName eq "Developers" or displayName eq "Devs"
Syntax je jednoduchý avšak musí mať istú formu, ktorá musí byť splnená. Logika tu hrá rolu. Predsa aj Slovenský jazyk má svoje pravidlá. Preto ak by sme mali nastavený len jeden filter, respektíve ak by sme hľadali na základe jednej podmienky, tak syntax vyzerá nasledovne:
/{koncový bod}?filter={atribút} {operácia} "{string}"
Avšak ak by sme chceli hľadať na základe viacerých podmienok, tak v tom prípade použijeme jednoduché logické operandy ako AND alebo OR. To by vyzeralo nasledovne:
Pre AND:
/{koncový bod}?filter={atribút} {operácia} "{string}" AND {atribút} {operácia} "{string}"
Pre OR:
/{koncový bod}?filter={atribút} {operácia} "{string}" OR {atribút} {operácia} "{string}"
Kombinácia AND a OR:
/{koncový bod}?filter={atribút} {operácia} "{string}" AND ({atribút} {operácia} "{string}" OR {atribút} {operácia} "{string}")
Jednotlivé porovnávacie funkcie sú jednoduché. Existujú tieto:
- eq - equal - rovná sa
- co - contains - obsahuje
- ew - end with - končí s
- sw - starts with - začína s/na
- pr - present - neobsahuje prázdnu hodnotu
- gt - greater than - väčšie ako
- ge - greater than or equal - väčšie alebo rovné ako
- lt - less than - menšie ako
- le - less than or equal - menšie alebo rovné ako
Pri hľadaní pomocou metódy POST na koncový bod /.search to vyzerá takmer identicky. Používame tie isté operandy a aj tie isté porovnávacie funkcie. Rozdiel je len a len v tom, že pri tomto hľadaní všetky filtre zapisujeme do tela požiadavky. Preto to môže vyzerať nejako takto:
<- Tu by sa za bežných okolností písala hlavička ale v tejto ukážke to nieje dôležité. Preto to vynecháme a preskočíme priamo do tela požiadavky.
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
"filter": "userName eq \"Patrik\" and password eq \"PatrikPisePublikaciu\""
}
Životný cyklus identity
Celý cyklus identity začína vždy jeho vznikom. Postupujeme teda tak, že na nami zvolenú platformu odošleme požiadavku. Požiadavka obsahuje správne vyplnenú hlavičku a správne zapísané údaje, ktoré špecifikujú našu vytváranú identitu. Zadefinujme si ale v prom rade nášho používateľa.
- Naša identita sa bude volať Móric Košický.
- Jeho osobná e-mailová adresa bude: moric.ke@slovakia.sk
- Samozrejme Móric je riadne zamestnaný, takže má aj firemný mail: m.kosicky@firma.sk. Je zrejmé, že firemný mail je preňho ten hlavný.
- Jeho bydliskom sú Košice a národnosť teda Slovenská.
- Móric nieje žiadne béčko a preto má aj skončenú vysokú školu, vďaka ktorej získal titul Ing.
- Má rád svoju prezývku Morčo.
- Používa dve telefónne čísla. Firemné 0901 225 335 a osobné 0906 654 543.
Vytvorenie identity:
Na základe vyššie spomenutých špecifikácií postupujeme k vytvoreniu požiadavky. Nesmieme zabudnúť, že požiadavka musí vyhovovať schéme SCIM protokolu a preto sa jej držíme ako predlohy. Keďže ho ideme vytvárať (zaevidovať do systému), odosielame nasledovnú požiadavku:
POST /v2/Users HTTP/1.1
Accept: application/json
Authorization: Bearer h480djs93hd8
Host: azet.sk
Content-Length: ...
Content-Type: application/json
{
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"externalId":"",
"userName":"móric.košický",
"name":{
"familyName":"Košický",
"givenName":"Móric",
"honorPrefix":"Ing."
},
"nickName":"Morčo",
"phoneNumbers":[
{
"value":"0901 225 335",
"type":"work"
},
{
"value":"0906 654 543",
"type":"private"
},
],
"emails":[
{
"value":"moric.ke@slovakia.sk",
"type":"home",
"primary": false
},
{
"value":"m.košický@firma.sk",
"type":"home",
"primary": true
}
],
"addresses":[
{
"type":"home",
"locality":"Košice",
"region":"Košický",
"country":"Slovensko"
}
],
}
Každá akcia vyvoláva reakciu. Preto sa nám spätne vracia dlhočiazna odpoveď. Nás ale z tej odpovede zaujímajú len 2 riadky. Okrem iného aj to, či všetky nami vyplnené údaje súhlasia s tým, čo sa nám vráti v odpovedi.
1. dôležitý riadok, ktorý hľadáme:
HTTP/1.1 201 Created <- Ak nájdeme toto, to znamená úspešné vytvorenie !
2. dôležitý riadok:
"id":"2819c223-7f76-453a-919d-413861904646" <- Toto id systém určilo našej identite
Aktualizácia údajov identity:
Ak by sme pokračovali cyklom ďalej, pri úprave Mórica by sme postupovali takmer rovnako. Miesto metódy POST použijeme PATCH. Za metódou a /v2/Users/* by sme napísali Móricove ID. A do tela stringu by sme pod atribút “schemas” pokračovali takými atribútami, ktoré by sme chceli nahradiť. Samozrejme je tu istá štruktúra ktorú treba dodržať.
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace", <- Replace-nahradiť/Remove-vymazať/Add-pridať
"path": "nickName", <- Definujeme, ktorý atribút chceme zmeniť/zmazať/pridať
"value":"Morčo" <- Ak meníme, tak za akú hodnotu
}
]
}
Odpoveď na našu požiadavku nám povie, či sa nám to podarilo. Ak to bude 200 (Success) tak vieme s istotou povedať áno!
Vymazanie identity:
V prípade, že ideme identitu vymazávať. Odosielame požiadavku, kde miesto POST napíšeme DELETE. Za metódu a /v2/Users/* by sme napísali Móricove ID a vynechali by sme celé telo.
DELETE /v2/Users/2819c223-7f76-453a-919d-413861904646
Host: azet.sk
Authorization: Bearer h480djs93hd8
Výsledkom je vymazanie identity, za predpokladu, že sa nám vráti v odpovedi 204 (No Content).
Toto všetko je len malý zlomok z toho najdôležitejšieho. Pre rozmanitejší opis ďalších funkcií a ako pracovať s ostatnými metódami spolu s príkladmi si určite pozrite tento link: https://tools.ietf.org/html/rfc7644#section-3.3
Tak čo? Však ste tomu rozumeli?
V kútiku duše dúfam, že tento príspevok bol pre vás zaujímavý. SCIM nie je až taká strašidelná záležitosť. Verím, že ak sa niekedy v budúcnosti stretnete so systémom SCIM tak si poviete: ,,O tom som čítal! Viem presne čo to je!”, alebo niečo tomu podobné. Samozrejme si na to určite treba spomenúť keď raz niekedy budete mať veľkú firmu s veľa zamestnancami. Značne vám takýto spôsob uľahčí manipuláciu s nimi. Presnejšie povedané s ich účtami, prístupmi a povereniami. Celkovo je SCIM jednoduchý na pochopenie a manipuláciu a verte mi, jednoduchosť a automatizácia rutinných činností Vás značne odľahčí. Vzniká tým pádom veľa voľného času, ktorý môžete investovať napríklad aj na osobný rozvoj.
Je jednoducho low-cost riešením, open source, veľmi známy na trhu a používaný ako štandard. Dokáže zabezpečiť celý životný cyklus identity od jeho vytvorenia, úpravy až po jeho vymazanie. Môžete si clienta vytvoriť a “nakódit” sami. Avšak ak sa vám nechce, existuje množstvo free-to-use knižníc alebo už rovno pripravených clientov na používanie.
Ak vás to teda zaujalo nebojte sa navštíviť samotnú stránku SCIM-u na http://www.simplecloud.info/. Nájdete tam všetko, od manuálov až po jednotlivé platformy, ktoré majú podporu SCIM. Firmy ako Microsoft, Cisco, Intel, Sailpoint, Google, IBM a rôzny ďalší si SCIM nevedia vynachváliť a sami ho používajú vo svojich interných systémoch. Tak prečo nie vy?