Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Mit dem Daten-API-Generator kann jede Datenbank über eigene spezifische Features verfügen. In diesem Artikel werden die Features beschrieben, die für jede Datenbank unterstützt werden.
Datenbankversionsunterstützung
Viele herkömmliche Datenbanken erfordern eine Mindestversion, die mit dem Daten-API-Generator (DATA API Builder, DAB) kompatibel ist.
| Unterstützte Mindestversion | |
|---|---|
| SQL Server | 2016 |
| MySQL | 8 |
| PostgreSQL | 11 |
Umgekehrt funktionieren Azure-Clouddatenbankdienste ohne eine bestimmte Version sofort mit DAB.
| Unterstützte Mindestversion | |
|---|---|
| Azure SQL | n/a |
| Azure Cosmos DB für NoSQL | n/a |
| Azure Cosmos DB für PostgreSQL | n/a |
Azure SQL und SQL Server
Es gibt einige spezifische Eigenschaften, die für SQL eindeutig sind, einschließlich Azure SQL und SQL Server.
SESSION_CONTEXT
Azure SQL und SQL Server unterstützen die Verwendung der SESSION_CONTEXT Funktion für den Zugriff auf die Identität des aktuellen Benutzers. Dieses Feature ist nützlich, wenn Sie die systemeigene Unterstützung für die Sicherheit auf Zeilenebene (RLS) anwenden möchten, die in Azure SQL und SQL Server verfügbar ist.
Für Azure SQL und SQL Server kann der Daten-API-Generator SESSION_CONTEXT nutzen, um vom Benutzer angegebene Metadaten an die zugrunde liegende Datenbank zu senden. Solche Metadaten stehen dem Daten-API-Generator aufgrund der im Zugriffstoken vorhandenen Ansprüche zur Verfügung. Die an die Datenbank gesendeten Daten können dann verwendet werden, um eine zusätzliche Sicherheitsstufe zu konfigurieren (z. B. durch Konfigurieren von Sicherheitsrichtlinien), um den Zugriff auf Daten in Vorgängen wie SELECT, UPDATE, DELETE weiter zu verhindern. Die SESSION_CONTEXT Daten sind während der Datenbankverbindung für die Datenbank verfügbar, bis diese Verbindung geschlossen ist. Dieselben Daten können auch in einer gespeicherten Prozedur verwendet werden.
Weitere Informationen zum Festlegen von SESSION_CONTEXT Daten finden Sie unter sp_set_session_context (Transact-SQL).
Konfigurieren Sie SESSION_CONTEXT die Verwendung der options Eigenschaft des data-source Abschnitts in der Konfigurationsdatei. Weitere Informationen finden Sie in der data-source Konfigurationsreferenz.
{
...
"data-source": {
"database-type": "mssql",
"options": {
"set-session-context": true
},
"connection-string": "<connection-string>"
},
...
}
Alternativ können Sie das --set-session-context Argument mit dem dab init Befehl verwenden.
dab init --database-type mssql --set-session-context true
Alle im EasyAuth/JWT-Token vorhandenen Ansprüche werden über die SESSION_CONTEXT zugrunde liegende Datenbank gesendet. Alle im Token vorhandenen Ansprüche werden in Schlüsselwertpaare übersetzt, die über SESSION_CONTEXT die Abfrage übergeben werden. Diese Ansprüche umfassen, sind jedoch nicht beschränkt auf:
| Description | |
|---|---|
aud |
Audience |
iss |
Issuer |
iat |
Issued at |
exp |
Expiration time |
azp |
Application identifier |
azpacr |
Authentifizierungsmethode des Clients |
name |
Subject |
uti |
Eindeutiger Tokenbezeichner |
Weitere Informationen zu Ansprüchen finden Sie in der Referenz zu Zugriffstoken für Microsoft Entra-ID.
Diese Ansprüche werden in eine SQL-Abfrage übersetzt. In diesem abgeschnittenen Beispiel wird die Verwendung in diesem Kontext veranschaulicht sp_set_session_context :
EXEC sp_set_session_context 'aud', '<AudienceID>', @read_only = 1;
EXEC sp_set_session_context 'iss', 'https://login.microsoftonline.com/<TenantID>/v2.0', @read_only = 1;
EXEC sp_set_session_context 'iat', '1637043209', @read_only = 1;
...
EXEC sp_set_session_context 'azp', 'a903e2e6-fd13-4502-8cae-9e09f86b7a6c', @read_only = 1;
EXEC sp_set_session_context 'azpacr', 1, @read_only = 1;
..
EXEC sp_set_session_context 'uti', '_sSP3AwBY0SucuqqJyjEAA', @read_only = 1;
EXEC sp_set_session_context 'ver', '2.0', @read_only = 1;
Anschließend können Sie die Sicherheit auf Zeilenebene (RLS) mithilfe der Sitzungsdaten implementieren. Weitere Informationen finden Sie unter Implementieren der Sicherheit auf Zeilenebene mit Sitzungskontext.
Azure Cosmos DB (ein Microsoft-Datenbankdienst)
Es gibt einige spezifische Eigenschaften, die für verschiedene APIs in Azure Cosmos DB einzigartig sind.
Schema in API für NoSQL
Azure Cosmos DB for NoSQL ist schemaunabhängig. Um den Daten-API-Generator mit der API für NoSQL zu verwenden, müssen Sie eine GraphQL-Schemadatei erstellen, die die Objekttypdefinitionen enthält, die das Datenmodell Ihres Containers darstellen. Der Daten-API-Generator erwartet außerdem, dass Ihre GraphQL-Objekttypdefinitionen und -felder die GraphQL-Schemadirektive authorize enthalten, wenn Sie restriktiveren Lesezugriff erzwingen möchten als anonymous.
Diese Schemadatei stellt z. B. ein Book Element in einem Container dar. Dieses Element enthält mindestens title und Authors Eigenschaften.
type Book @model(name:"Book"){
id: ID
title: String @authorize(roles:["metadataviewer","authenticated"])
Authors: [Author]
}
Dieses Beispielschema entspricht der folgenden Entitätskonfiguration in der DAB-Konfigurationsdatei. Weitere Informationen finden Sie in der entities Konfigurationsreferenz.
{
...
"Book": {
"source": "Book",
"permissions": [
{
"role": "anonymous",
"actions": [ "read" ]
},
{
"role": "metadataviewer",
"actions": [ "read" ]
}
]
}
...
}
Die @authorize Direktive mit roles:["metadataviewer","authenticated"] beschränkt dem Zugriff auf das title Feld auf nur Benutzer mit den Rollen metadataviewer und authenticated. Bei authentifizierten Anforderern wird die Systemrolle authenticated automatisch zugewiesen, sodass keine X-MS-API-ROLE Kopfzeile erforderlich ist.
Wenn die authentifizierte Anforderung im Kontext metadataviewerausgeführt werden muss, sollte sie mit einem Anforderungsheader vom Typ X-MS-API-ROLE "Set" metadataviewerbegleitet werden. Wenn der anonyme Zugriff jedoch gewünscht ist, müssen Sie die autorisierte Direktive weglassen.
Die @model Direktive wird verwendet, um eine Korrelation zwischen diesem GraphQL-Objekttyp und dem entsprechenden Entitätsnamen in der Laufzeitkonfiguration herzustellen. Die Direktive ist wie folgt formatiert: @model(name:"<Entity_Name>")
Als tiefergehendes Beispiel kann die @authorize Direktive auf der Obersten Ebene der Typdefinition angewendet werden. Diese Anwendung schränkt den Zugriff auf den Typ und seine Felder ausschließlich auf die in der Direktive angegebenen Rollen ein.
type Series @model(name:"Series") @authorize(roles:["editor","authenticated"]) {
id: ID
title: String
Books: [Book]
}
{
"Book": {
"source": "Series",
"permissions": [
{
"role": "authenticated",
"actions": [ "read" ]
},
{
"role": "editor",
"actions": [ "*" ]
}
]
}
}
Containerübergreifende Abfragen in API für NoSQL
GraphQL-Vorgänge über Container hinweg werden nicht unterstützt. Das Modul antwortet mit einer Fehlermeldung, die besagt, Adding/updating Relationships is currently not supported in Azure Cosmos DB for NoSQL.
Sie können diese Einschränkung umgehen, indem Sie Ihr Datenmodell aktualisieren, um Entitäten im selben Container in einem eingebetteten Format zu speichern. Weitere Informationen finden Sie unter Datenmodellierung in Azure Cosmos DB für NoSQL.