Pravice: pravila in obseg

Kaj sme klicatelj (oseba ali program, ki pošlje zahtevo), določajo pravila: do katerih aliasov, vrst objektov in posameznih objektov sme dostopati, katere metode sme uporabljati in ali sme samo brati. Pravila dodelite ključem storitve, osebam, računom in skupinam Windows ter prijavam SQL Server. Na tej strani je opisano, kako pravila delujejo skupaj.

• Obseg pravic za vsakega klicatelja in vsak alias posebej.
• Več pravil za različne aliase; vsako se presoja kot celota.
• Pravice za posamezne tabele, poglede in procedure; pogled je lahko dosegljiv tudi brez pravic na njegove tabele.
• Osebni ključ lahko pravice svoje osebe zoži, nikoli pa jih ne more razširiti.

Pravila so zapisana v Gateway:Security:Clients: dovoljeni aliasi, vrste virov, metode HTTP in oznaka samo za branje. Klicatelj brez ustreznega pravila ne doseže ničesar. Ključ brez pravila prepreči zagon prehoda, ker bi se z njim sicer lahko prijavili, dosegli pa ne bi ničesar.

Dva klicatelja ne smeta imeti istega ključa; preverjanje ob zagonu takšno konfiguracijo zavrne. Prehod klicatelja prepozna po ključu. Če bi si dva klicatelja delila ključ, bi prehod vsako zahtevo pripisal tistemu, ki je naveden v konfiguraciji zadnji, drugi pa ne bi bil več dosegljiv. Kateri je kateri, bi bilo odvisno od vrstnega reda vnosov, kar ni zanesljiv nadzor obsega. Sporočilo navede oba klicatelja, ključa pa nikoli, niti kot kontrolno vsoto, ker se sporočilo ob zagonu zapiše v dnevnik in pogosto konča v zahtevku za podporo.

Pravilo je lahko sestavljeno iz več vnosov z istim Id, pri čemer vsak vnos navaja svoje aliase. To je namenjeno pogostemu primeru, ko aplikacija eno podatkovno zbirko samo bere, v drugo pa mora tudi pisati:

"Clients": [
  { "Id": "fachanwendung", "Databases": [ "fachdaten" ],
    "Resources": [ "views" ],                "Verbs": [ "GET" ],          "ReadOnly": true  },
 
  { "Id": "fachanwendung", "Databases": [ "anmeldung" ],
    "Resources": [ "views", "procedures" ],  "Verbs": [ "GET", "POST" ],  "ReadOnly": false }
]

Brez te možnosti bi obseg klicatelja veljal za vse njegove aliase hkrati. Aplikacija, ki mora nekam pisati, bi lahko pisala povsod, kjer sme brati. Kaj to pomeni, je odvisno od vsebine druge podatkovne zbirke: prehod katalog prebere iz podatkovne zbirke, nihče ga ne ureja ročno, zato je dosegljivo vse, kar tam obstaja. V podatkovni zbirki z veliko procedurami bi skupen obseg pomenil, da sme aplikacija klicati vse.

Dva vnosa z istim Id ne smeta navajati istega aliasa, zvezdica * pa ne sme stati poleg drugega vnosa. V obeh primerih se prehod ne zažene in v sporočilu navede Id in podvojeni alias. Sicer bi o tem, kateri obseg velja, odločal vrstni red vnosov, čeprav bi bil vsak vnos sam zase videti pravilen. Ker zahtevi tako ustreza največ en vnos z istim Id, vrstni red ni pomemben. Različna pravila (z različnim Id), na primer pravila iste osebe iz več skupin Windows, pa smejo navajati isti alias; njihove pravice se seštevajo.

Vnos se presoja kot celota. Če bi prehod vzel alias iz enega vnosa in metodo HTTP iz drugega, bi iz dveh ozkih dovoljenj nastalo široko, ki ga nihče ni zapisal. V zgornjem primeru je POST na fachdaten zavrnjen, čeprav sme isti klicatelj izvesti POST na anmeldung.

Posamezen vnos, ki navaja * poleg konkretnega aliasa, je dovoljen, ker si znotraj enega vnosa navedbe ne morejo nasprotovati.

Pravilo lahko navede objekte, za katere velja (Objects), in posamezne izmed njih izvzame (ExceptObjects). Oba seznama imata enako obliko kot seznami tabel pri aliasu: *, shema.* ali shema.ime. Imena so zapisana tako, kot jih navaja prehod (posebni znaki so kodirani, glejte Imena s posebnimi znaki); velike in male črke niso pomembne.

"Clients": [
  { "Id": "lager-lesen", "Databases": [ "fachdaten" ],
    "Resources": [ "views" ], "Objects": [ "dbo.viewLagerbestand" ],
    "Verbs": [ "GET" ], "ReadOnly": true },
 
  { "Id": "lager-pflege", "Databases": [ "fachdaten" ],
    "Resources": [ "tables" ], "Objects": [ "lager.*" ], "ExceptObjects": [ "lager.Preise" ],
    "Verbs": [ "GET", "PATCH" ], "ReadOnly": false }
]

• Brez seznama pravilo velja za vse objekte svojih vrst. Vrste v Resources veljajo še naprej: objekt iz Objects je dosegljiv samo, če je dovoljena tudi njegova vrsta.
• Izvzetje ima znotraj pravila prednost. Med več pravili iste osebe se pravice seštevajo kot povsod: če objekt dovoli drugo pravilo, ostane dosegljiv.
• Pogled ne potrebuje pravic na svoje tabele. Prehod preveri samo objekt, ki ga navaja zahteva. SQL Server tabele za pogledom bere prek verige lastništva, tako kot pri vsaki prijavi, ki sme brati samo pogled. Del tabele torej sprostite tako, da ustvarite pogled in dovolite samo njega.
• Česar klicatelj ne sme brati, zanj ne obstaja. Storitveni dokument, $metadata in seznami kataloga v gonilniku prikazujejo samo dovoljene objekte. Na zahtevo za kateri koli drug objekt prehod odgovori z 404, enako kot pri objektu, ki ne obstaja. Če klicatelj objekt sme brati, ne sme pa ga spreminjati na zahtevani način, prehod odgovori z 403.
• Ne skupaj s sql. Lasten stavek doseže vse, kar doseže prijava, pod katero se izvede: prijava aliasa ali, pri prijavi SQL Server in pri Impersonate, lastna prijava osebe. Prehod besedila takega stavka ne razčlenjuje in seznama objektov tam ne more uveljaviti. Pravilo, ki ima hkrati sql in seznam objektov, zato prepreči zagon prehoda oziroma shranjevanje. Enako velja za klicatelje, katerih stavki se izvajajo pod njihovo lastno prijavo (glejte prepustna pot): tam seznam objektov lastnega stavka ne omejuje. Preverjene stavke brez sql pa prehod preveri glede na seznam objektov, objekt za objektom.

Pravila prehoda segajo do aliasa, vrste vira, objekta, metode HTTP in oznake samo za branje. Pravil za posamezne vrstice prehod ne pozna in jih tudi ne bo dobil. Ali sme oseba določeno vrstico videti ali spremeniti, odloči podatkovna zbirka, s pogledom, ki filtrira, in s procedurami, ki preverjajo. Dva sistema pravic, ki se prekrivata, bi se prej ali slej razšla.

Pogoj: stavek se izvede kot oseba. Pogled lahko filtrira po osebi samo, če SQL Server osebo pozna. To velja v dveh primerih:

• pri aliasu s Persons: Impersonate za klicatelje z lastno prijavo v SQL Server (račun Windows ali prijava SQL Server, vpisana pri osebi). Prehod identiteto zamenja z EXECUTE AS LOGIN. SUSER_SNAME() in USER_NAME() tedaj vrneta osebo, ORIGINAL_LOGIN() pa prehod; SUSER_SID() vrne SID osebe, v stavku pa tudi v privzetih vrednostih stolpcev in sprožilcih. Glejte Posredovanje identitete oseb strežniku SQL Server;
• pri prijavi s prijavo SQL Server prek HTTP Basic, ker se stavek izvede na ločeni povezavi s to prijavo.

Past je privzeta nastavitev. Pri aliasu s Persons: Service, kar je privzeto, se vsi stavki izvajajo pod prijavo aliasa. SUSER_SNAME() in SUSER_SID() tedaj vrneta račun storitve, za vsakega klicatelja enako. Pogled, ki filtrira po njiju, ne sporoči napake, ampak glede na filter vrne nič ali vse. Enako velja za klicatelje s ključem storitve, ker ta identitete nikoli ne zamenja, tudi pri aliasu z Impersonate ne.

Kaj SQL Server vidi v posameznem primeru:

SESSION_CONTEXT prehod nastavi za klicatelje z osebnim ključem in za izbrano identiteto podatkovne zbirke, pri vsakem aliasu in pred vsako zamenjavo identitete, in sicer samo za branje: wkl.person (ime osebe), wkl.key (ID osebnega ključa ali NULL) in wkl.role (izbrana identiteta ali NULL). Preden povezavo iz zaloge povezav dobi naslednja zahteva, se vrednosti ponastavijo.

Primer 1: filter po prijavi osebe. Velja za alias s Persons: Impersonate. Primerja se SUSER_SID(), ne ime, ker preimenovan račun Windows v SQL Serverju obdrži staro ime prijave, SID pa ostane enak (glejte "Der Dienst kann diese Anmeldung in SQL Server nicht annehmen" (prehod ne more prevzeti te prijave v SQL Server) po preimenovanju računa).

CREATE VIEW maske.auftrag_liste AS
SELECT a.auftrag_id, a.betreff, a.bereich_id
FROM dbo.auftrag AS a
WHERE EXISTS (SELECT 1
              FROM iam.konto_bereich AS kb
              WHERE kb.bereich_id = a.bereich_id
                AND kb.login_sid = SUSER_SID());

Primer 2: filter po osebi iz SESSION_CONTEXT. Velja za klicatelje brez lastne prijave (osebni ključ pri aliasu s Persons: Service). Vrednost je ime osebe v skrbniški shrambi; če osebo tam preimenujete, se spremeni tudi vrednost.

CREATE VIEW maske.auftrag_liste_schluessel AS
SELECT a.auftrag_id, a.betreff, a.bereich_id
FROM dbo.auftrag AS a
WHERE EXISTS (SELECT 1
              FROM iam.konto_bereich AS kb
              WHERE kb.bereich_id = a.bereich_id
                AND kb.person_name = CAST(SESSION_CONTEXT(N'wkl.person') AS nvarchar(256)));

Odločiti se morate za eno od dveh poti:

• Oba pogoja združite v enem pogledu (… = SUSER_SID() OR … = SESSION_CONTEXT(N'wkl.person')) in sprejmete, da za ime osebe jamči prehod.
• Alias nastavite na Persons: Impersonate, vsaki osebi date lastno prijavo in uporabljate samo primer 1. Prehod tedaj račun Windows brez lastne prijave zavrne z 403. Osebni ključ brez vpisane prijave SQL Server pa se tudi tu izvaja pod prijavo aliasa: zanj SUSER_SID() vrne račun prehoda in filter iz primera 1 mu pokaže nič ali vse. Pri takih aliasih zato vsaki osebi s ključem vpišite prijavo SQL Server ali pa oba pogoja vendarle združite.

Katere poti zamenjajo identiteto. Vseh šest poti do podatkov odpre povezavo prek iste seje: branje (tudi $apply), branje posameznega zapisa, štetje, klic procedure, pisanje v tabele in prepustna pot.

Branje kataloga je izjema. $metadata, stolpce, ključe in seznam objektov prehod bere pod prijavo aliasa, katere objekte klicatelj vidi, pa odločajo pravila prehoda. To ima dve posledici:

• Pogled, ki filtrira vrstice, v $metadata kljub temu prikaže vse svoje stolpce.
• Ključ pogleda (iz metapodatkov brskanja SQL Serverja) prehod ugotovi pod prijavo aliasa, ne pod prijavo osebe.

• Konfiguracija: pravila
• “Ustvarjanje pravila” (dokumentacija aplikacije za upravljanje)
• Prijava in posredovanje identitete