Erzwingen Sie die Speicherisolierung von Endbenutzern mit umfassender Datensicherheit

In diesem Handbuch wird gezeigt, wie Sie die Isolation von Endbenutzern für eine Oracle AI Agent Memory-Anwendung mit OCI IAM und Oracle Deep Data Security durchsetzen.

Warnung: Nur Lernumgebung. Stellen Sie dieses Beispiel nicht in der Produktion bereit.

Die Anwendung verwendet den Flask-Entwicklungsserver, einen In-Memory-Session-Speicher, Umgebungsdateisecrets und eine vereinfachte Verarbeitung des Tokenlebenszyklus. Die Datenbanksetupskripte ändern die datenbankweiten Identity Provider-Einstellungen und -Berechtigungen. Verwenden Sie nur Einwegbenutzer und eine isolierte Nicht-Produktions-Oracle Autonomous AI Database.

In diesem Handbuch wird eine absichtlich kleine Webanwendung erstellt:

Die Strecke vergleicht nicht Alice und Bob selbst. Das Endbenutzertoken wird an Oracle AI Database übergeben, wo Oracle Deep Data Security die Eigenzeilen-Policy des Agent-Speichers durchsetzt.

In diesem Handbuch wird ein Deployment gezeigt. Das vollständige Sicherheitsfeature, einschließlich jeder unterstützten Policy, Principal, Administrationsfunktion, Laufzeitkontext-API, Auditing und Widerrufstiming, finden Sie unter Deep Data Security-API und Sicherheitsreferenz.

In diesem Leitfaden werden Sie:

Die Vertrauenskette verstehen

Der Browser und die Anwendung verwenden zwei verschiedene OAuth-Zugriffstoken:

  1. Das Endbenutzertoken identifiziert Alice oder Bob und enthält die IAM-Gruppen des Benutzers.
  2. Das Datenbankzugriffstoken, das von der vertraulichen Anwendung über Clientzugangsdaten abgerufen wird, beweist, dass die Anwendung auf die Datenbankressource zugreifen kann.

Oracle AI Database validiert beide Token, bevor der Endbenutzersicherheitskontext angehängt wird.

Oracle dokumentiert dieses Zwei-Token-Modell unter Authentifizierungsablauf und Voraussetzungen und den vollständigen Lebenszyklus unter Endbenutzersicherheitskontext.

Voraussetzungen

Sie benötigen:

Oracle Deep Data Security ist eine datenbankgestützte, feingranulierte Autorisierung. Siehe Was ist Oracle Deep Data Security.

OCI-IAM-Identitätsdomain konfigurieren

Führen Sie alle OCI IAM-Funktionen in einer Identitätsdomain aus. Zeichnen Sie die Domain-URL auf, z.B. https://idcs-<id>.identity.oraclecloud.com:443.

Die maßgebliche Schritt-für-Schritt-Anleitung von Oracle ist OCI IAM für Application-Mediated Access konfigurieren. Die Werte im folgenden Beispiel stimmen mit der in dieser Dokumentation angegebenen Beispielumgebungsdatei überein.

Datenbankressource registrieren

Gehen Sie unter Identitätsdomain > Integrierte Anwendungen wie folgt vor:

  1. Fügen Sie eine vertrauliche Anwendung mit dem Namen OracleDB hinzu.
  2. Als Ressourcenserver konfigurieren:
    • Primäre Zielgruppe: OracleDB
    • Geltungsbereich: DB_ACCESS_SCOPE
  3. Konfigurieren Sie sie als Client, und lassen Sie Clientzugangsdaten zu.
  4. Aktivieren Sie es.
  5. Notieren Sie die Anwendungs-ID, die Client-ID und das Client Secret.

Der vollqualifizierte Datenbankgeltungsbereich ist die Zielgruppe, die mit dem Geltungsbereichsnamen verkettet ist:

OracleDBDB_ACCESS_SCOPE

Befolgen Sie Datenbank in OCI IAM registrieren, um die aktuellen Konsolenlabels und Feldbeschreibungen anzuzeigen.

Webanwendung registrieren

Fügen Sie eine zweite vertrauliche Anwendung mit dem Namen OracleAgentMemoryWeb hinzu:

  1. Aktivieren Sie Berechtigungen als Autorisierung durchsetzen.
  2. Als Ressourcenserver konfigurieren:
    • Primäre Zielgruppe: OracleAgentMemoryWeb
    • Geltungsbereich: APP_ACCESS_SCOPE
    • Zugriffstoken-Lebensdauer: 3600 Sekunden für diese Übung
  3. Konfigurieren Sie es als Client mit den folgenden Berechtigungen:
    • Autorisierungscode
    • Clientzugangsdaten
  4. Fügen Sie diese genaue Umleitungs-URL hinzu: 
    http://127.0.0.1:8000/auth/callback
  5. Gewähren Sie unter Clientressourcen Zugriff auf beide:
    • OracleDBDB_ACCESS_SCOPE
    • OracleAgentMemoryWebAPP_ACCESS_SCOPE
  6. Aktivieren Sie die Anwendung, und notieren Sie ihre Client-ID und ihr Client Secret.

Die Anwendung verwendet den Autorisierungscode mit state und PKCE S256. OCI IAM dokumentiert die erforderliche Clientkonfiguration unter Anwendung in OCI IAM registrieren und stellt ein Beispiel für PKCE-Autorisierungscode bereit.

Gruppenanspruch hinzufügen

Oracle AI Database aktiviert extern zugeordnete Datenrollen aus dem group-Claim des Endbenutzer-Tokens. Benutzerdefinierte OCI IAM-Claims werden über die REST-API der Identitätsdomain und nicht über die Konsole konfiguriert.

Laden Sie als Identitätsdomainadministrator ein kurzlebiges persönliches Zugriffstoken herunter, das Identitätsdomain-APIs aufrufen kann. Führen Sie anschließend Folgendes aus:

export OCI_IAM_DOMAIN_URL='https://<identity-domain-host>:443'
export OCI_IAM_ADMIN_TOKEN='<short-lived-personal-access-token>'

curl --fail-with-body \
  -X POST "$OCI_IAM_DOMAIN_URL/admin/v1/CustomClaims" \
  -H "Authorization: Bearer $OCI_IAM_ADMIN_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": [
      "urn:ietf:params:scim:schemas:oracle:idcs:CustomClaim"
    ],
    "name": "group",
    "value": "$user.groups.*.display",
    "expression": true,
    "mode": "always",
    "tokenType": "AT",
    "allScopes": true
  }'

Eine erfolgreiche Anforderung gibt HTTP 201 zurück. Erstellen Sie kein Duplikat, wenn die Domäne bereits über diesen Anspruch verfügt. Siehe Benutzerdefinierte Claims für Gruppeninformationen in OCI IAM konfigurieren.

Alice, Bob und die Anwendungsgruppe erstellen

  1. Erstellen Sie eine Gruppe namens ORACLEAGENTMEMORY_USERS.
  2. Erstellen Sie Testbenutzer alice und bob.
  3. Weisen Sie beide Benutzer ORACLEAGENTMEMORY_USERS zu.
  4. Weisen Sie die Gruppe OracleAgentMemoryWeb zu.

Die Datenbank ordnet diesen Gruppennamen später einer Datenrolle zu. Gruppennamen werden ohne Berücksichtigung der Groß-/Kleinschreibung verglichen, verwenden jedoch während des gesamten Setups dieselbe Schreibweise. Siehe Benutzer erstellen und Gruppen in OCI IAM zuweisen.

Vorbereiten der Umgebung

Laden Sie die vollständige Webanwendung deepsec_oci_iam_webapp.zip herunter. Das Archiv enthält auch Standalone-Datenbanksetup- und Prüfungsskripte für dieses Beispiel. Sie importieren oder verpacken keine Skripte aus der SDK-Testsuite.

Extrahieren Sie das Archiv, geben Sie das Projektverzeichnis ein, und erstellen Sie lokale Setup- und Laufzeitumgebungsdateien:

unzip deepsec_oci_iam_webapp.zip
cd deepsec_oci_iam_webapp
cp deepsec.env.example .deepsec.env
cp deepsec.runtime.env.example .deepsec.runtime.env
python -c "import secrets; print(secrets.token_hex(32))"

Setzen Sie den generierten Wert in OAM_WEB_SECRET_KEY, und füllen Sie jeden erforderlichen Platzhalter in beiden Dateien auf. Beide Dateinamen werden von Git ignoriert.

Das Verzeichnis database_scripts enthält:

Datei Zuständigkeit
_common.sh Privater Helper, der .deepsec.env lädt, erforderliche Werte validiert, nach SQL*Plus sucht und TNS_ADMIN exportiert, wenn es konfiguriert ist. Führen Sie sie nicht direkt aus.
db_ociiam_setup.sh Aktiviert die externe OCI IAM-Authentifizierung für die autonome KI-Zieldatenbank und ersetzt OCI_IAM_DOMAIN_DB_CRED$.
db_deepsec_user_setup.sh Erstellt die Schemaeigentümer- und App-Pool-Benutzer und erteilt deren dokumentierte Berechtigungsausnahmelisten.
db_list_all_data_roles.sh Führt eine schreibgeschützte Prüfung von Deep Data Security-Rollen, IAM-Mappings, Datenzugriffsberechtigungen, Prädikaten, geschützten Objekten, Endbenutzern und Anwendungsidentitäten aus.

.deepsec.env wird nur vom Datenbanksetup verwendet. Dazu gehören die Kennwörter des Sicherheitsadministrators und des Schemaeigentümers. .deepsec.runtime.env wird vom Flask-Prozess geladen und schließt absichtlich beide privilegierten Kennwörter aus. Exportieren Sie die Setupdatei nicht in die Shell, in der die Webanwendung gestartet wird. Um verschiedene Pfade zu verwenden, legen Sie OAM_DEEPSEC_ENV_FILE für das Setup oder OAM_WEB_ENV_FILE für den Webprozess fest.

Die wichtigen IAM-Werte werden wie folgt zugeordnet:

Umgebungsvariable OCI-IAM-Wert
OAM_DEEPSEC_OCI_DB_APP_ID Anwendungs-ID der Datenbankanwendung
OAM_DEEPSEC_OCI_DB_CLIENT_ID Client-ID der Datenbankanwendung
OAM_DEEPSEC_OCI_DB_CLIENT_SECRET Client Secret der Datenbankanwendung
OAM_WEB_OCI_CLIENT_ID Client-ID der Webanwendung
OAM_WEB_OCI_CLIENT_SECRET Client Secret der Webanwendung
OAM_WEB_OCI_END_USER_SCOPE OracleAgentMemoryWebAPP_ACCESS_SCOPE
OAM_WEB_OCI_DATABASE_ACCESS_SCOPE OracleDBDB_ACCESS_SCOPE

OAM_DEEPSEC_CONFIG_DIR ist nur erforderlich, wenn der DSN ein TNS-Alias ist, dessen tnsnames.ora sonst nicht erkannt werden kann. Wallet-Speicherort und -Kennwort sind optional, wenn sqlnet.ora und der DSN bereits alle python-oracledb-Anforderungen bereitstellen. Informationen zu Verbindungsoptionen für autonome KI-Datenbanken finden Sie unter Python-Anwendungen mit einem Wallet verbinden.

Konfigurieren Sie auch einen Einbettungsanbieter. Die Anwendung listet nur Speicher auf und fügt sie hinzu. Agent Memory erstellt jedoch immer noch Einbettungen, wenn Speicherinhalte gespeichert werden. Die Vorlage verwendet ein OpenAI-kompatibles Modell als Beispiel. Ersetzen Sie das Modell, die API-Basis, den Schlüssel und die Dimension durch die Werte Ihres Providers.

Drei Datenbankaccounts konfigurieren

Warnung: Die Befehle in diesem Abschnitt ändern die datenbankweiten Einstellungen für die externe Authentifizierung und die Accountberechtigungen. Prüfen Sie zuerst die Skripte. Führen Sie sie nicht für eine gemeinsam genutzte oder Produktionsdatenbank aus.

Verwenden Sie drei verschiedene Datenbankbenutzer:

Zuständigkeit Beispielkonto Erlaubte Arbeit
Sicherheitsadministrator ADMIN Ermöglicht die OCI IAM-Integration und erstellt, erteilt, entzieht, listet und entfernt Datenrollen und Datenzugriffsberechtigungen. Es wird nie für Webanfragen verwendet.
Eigentümer des verwalteten Schemas OAM_SCHEMA_OWNER Erstellt Agent-Speichertabellen, Indizes, Prozeduren und Scheduler-Jobs. Wird nur für Schemalebenszyklusvorgänge verwendet.
Anwendungs-DB-Benutzer OAM_APP_DB_USER Öffnet Sessions und hängt Sicherheitskontexte für Endbenutzer an. Er erhält keine normalen SELECT-, INSERT-, UPDATE- oder DELETE-Berechtigungen.

Durch diese Trennung kann eine Anforderung ohne gültigen Endbenutzerkontext nicht geschlossen werden. Das Datenbankkonfigurationshandbuch von Oracle empfiehlt CREATE SESSION und CREATE END USER SECURITY CONTEXT für den Connection Pool-Account. Informationen hierzu finden Sie unter Datenbank für IAM-Integration konfigurieren.

Im Beispiel wird der Account ADMIN der autonomen KI-Datenbank für das Setup verwendet. Ein benutzerdefiniertes Sicherheitsadministratorkonto muss in der Lage sein, die beiden Datenbankbenutzer zu erstellen und zu ändern und ihre aufgelisteten Systemberechtigungen zu erteilen. Da die Agent-Speichertabellen zu einem separaten Schema gehören, erfordert die Policy-Administration CREATE ANY DATA GRANT, DROP ANY DATA GRANT und ADMINISTER ANY DATA GRANT und nicht nur CREATE DATA GRANT im eigenen Schema des Administrators. Außerdem muss er autorisiert sein, die von den Policys verwendeten Datenrollen zu erstellen und zu löschen.

OCI-IAM-Tokenvalidierung aktivieren

Prüfen und ausführen

bash database_scripts/db_ociiam_setup.sh

Das Skript meldet sich als Sicherheitsadministrator an und führt folgende Aktionen aus:

Nur ein externer Identitätsprovider kann aktiv sein. Das Beispielskript verwendet force => TRUE, um OCI-IAM-Parameter zu aktualisieren, was eine andere Konfiguration für die externe Authentifizierung unterbrechen kann. Oracle dokumentiert die genauen Autonomous Database-Aufrufe unter Database for IAM-Integration konfigurieren.

Eigentümer und Poolbenutzer erstellen

Prüfen und ausführen

bash database_scripts/db_deepsec_user_setup.sh

Das Skript ändert ADMIN nicht. Es erstellt Eigentümer- und Anwendungspoolbenutzer und Berechtigungen:

-- Managed-schema owner
CREATE SESSION, CREATE TABLE, CREATE SEQUENCE,
CREATE VIEW, CREATE PROCEDURE, CREATE JOB

-- Runtime application pool
CREATE SESSION, CREATE END USER SECURITY CONTEXT

Der Eigentümer erhält Quota für den Tablespace der autonomen KI-Datenbank DATA. Der Poolbenutzer erhält keine direkten Berechtigungen für die Tabellen des Eigentümers. Um das Beispiel auf die erforderlichen Anweisungen zu konzentrieren, prüft das Skript nicht auf vorhandene Benutzer oder prüft ihre aktuellen Berechtigungen. Verwenden Sie neue Kontonamen. Das Skript wird gestoppt, wenn entweder ein Benutzer bereits vorhanden ist oder eine andere SQL-Anweisung nicht erfolgreich ist.

Store und eigene Zeilen-Policy erstellen

Installieren Sie die Standalone-Beispielumgebung:

uv sync

Führen Sie dann das Setup-Programm aus:

uv run python scripts/setup_memory.py

Dieser Befehl ist nur für OAM_WEB_MEMORY_STORE_ID absichtlich destruktiv. Sie:

  1. meldet sich als Schemaeigentümer an, um das Agent-Speicherschema neu zu erstellen;
  2. meldet sich als Sicherheitsadministrator an, um die eigene Zeilen-Policy hinzuzufügen und ORACLEAGENTMEMORY_USERS zu erteilen.

Die Administrationsaufrufe zum Hinzufügen und Erteilen von Berechtigungen sind idempotent. Wenn Sie sie erneut ausführen, werden dieselben verwalteten Policy-Definitionen und -Zuweisungen ersetzt, und es wird erneut versucht, eine teilweise verwaltete DDL zu reparieren, die von einem unterbrochenen Versuch übrig geblieben ist.

Die Policy erstellt eine extern zugeordnete Datenrolle für die OCI-IAM-Gruppe und Datenzugriffsberechtigungen, deren Zeilenprädikat gespeicherte user_id-Werte mit ORA_END_USER_CONTEXT.username vergleicht. Oracle dokumentiert die Zuordnungssyntax in CREATE DATA ROLE und die Zeilenautorisierung in CREATE DATA Grants.

Prüfen Sie das Ergebnis:

bash database_scripts/db_list_all_data_roles.sh

Die IAM-zugeordnete Rolle, die Zugriffsberechtigungen für Agent-Speicherdaten und ihre geschützten Eigentümerschematabellen sollten angezeigt werden. Dieses Inspektionsskript fragt nur Katalogansichten ab. Es erstellt, ändert oder entfernt keine Deep Data Security-Objekte.

Einbettungsmodell in der Datenbank mit Deep Sec verwenden

Dieser Abschnitt gilt, wenn die Anwendung OracleDBEmbedder mit dem Standard-provider="database" und einem Einbettungsmodell verwendet, das in Oracle AI Database gespeichert ist, in der Regel ein importiertes ONNX-Modell wie DMUSER.DOC_MODEL. In dieser Konfiguration verwendet die direkte Einbettung den SQL-Operator VECTOR_EMBEDDING von Oracle. Daher benötigt das Modell die unten beschriebene Berechtigung SELECT ON MINING MODEL.

OracleDBEmbedder unterstützt auch Remoteprovider über DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING. Beispiel: provider="openai". Diese Konfigurationen rufen die Einbettungsanforderung weiterhin von Oracle AI Database auf, greifen jedoch nicht auf ein datenbankresidentes Mining-Modell zu. Die Anweisungen SELECT ON MINING MODEL in diesem Abschnitt finden keine Anwendung. Die Agent-Speichervorgänge müssen weiterhin in einem OracleMemoryEndUserSecurityContext ausgeführt werden.

Eine Agent-Speicher-Policy erteilt Zugriff auf Agent-Speichertabellen. Er gewährt keinen Zugriff auf ein Oracle AI Database-Einbettungsmodell. Das Modell benötigt eine eigene Datenbankberechtigung: SELECT ON MINING MODEL.

Erteilen Sie dem application-pool-Benutzer diese Berechtigung nicht. Während einer Anforderung autorisiert Deep Sec den Benutzer über die Datenrolle, die der OCI-IAM-Gruppe zugeordnet ist, und nicht über die normalen Berechtigungen des Poolbenutzers. Eine Berechtigung, die nur dem Poolbenutzer erteilt wurde, ist daher nicht verfügbar, solange ein Endbenutzer-Sicherheitskontext aktiv ist.

Erstellen Sie eine zugeordnete Datenrolle für jede IAM-Gruppe, die das Modell verwenden muss. Weisen Sie dieser Datenrolle eine normale Datenbankrolle zu, die Zugriff auf das Modell hat. Führen Sie die folgende SQL als Datenbanksicherheitsadministrator oder ein anderes Konto aus, das zum Erstellen von Rollen und Erteilen des Zugriffs auf das Modell autorisiert ist. Ersetzen Sie die Beispielnamen durch Namen für Ihre Anwendung:

-- This must exactly match the OCI IAM group passed to OciGroupPrincipal.
CREATE DATA ROLE APP_MEMORY_USERS_DATA_ROLE
  MAPPED TO 'IAM_OAUTH_GROUP=YOUR_IAM_GROUP';

-- This ordinary database role carries access to one embedding model.
CREATE ROLE APP_DOC_MODEL_ROLE;

GRANT SELECT ON MINING MODEL YOUR_USER.DOC_MODEL
  TO APP_DOC_MODEL_ROLE;

-- Give model access to the IAM group's Deep Sec data role.
GRANT APP_DOC_MODEL_ROLE TO APP_MEMORY_USERS_DATA_ROLE;

Die Anwendung verwendet dann denselben Gruppennamen, wenn sie Agent Memory Policys erteilt:

grant_agent_memory_policies(
    admin_connection,
    owner_schema="OAM_SCHEMA_OWNER",
    memory_store_id="MEMORY",
    principals=[OciGroupPrincipal("YOUR_IAM_GROUP")],
    policies=[UserOwnRowsDeepDataSecurityPolicy()],
)

grant_agent_memory_policies() gibt die vorhandene Rolle zurück, die YOUR_IAM_GROUP zugeordnet ist, und fügt der gleichen Rolle die Datenzugriffsberechtigungen für die Agent-Speichertabelle hinzu. Es wird keine zweite Rolle erstellt. Zur Laufzeit kann ein Benutzer, dessen OCI-IAM-Token YOUR_IAM_GROUP enthält, sowohl auf die zulässigen Agent-Speicherzeilen als auch auf DMUSER.DOC_MODEL zugreifen.

Wenn die Anwendung vor diesem Modellsetup bereits grant_agent_memory_policies() aufgerufen hat, hat Agent Memory bereits die zugeordnete Datenrolle erstellt. Erstellen Sie keine weitere zugeordnete Rolle für dieselbe Gruppe. Suchen Sie die vorhandene Rolle, und erteilen Sie ihr stattdessen die normale Modellrolle:

SELECT data_role
FROM sys.dba_data_roles
WHERE UPPER(mapped_to) = UPPER('IAM_OAUTH_GROUP=YOUR_IAM_GROUP');

GRANT APP_DOC_MODEL_ROLE TO <DATA_ROLE_RETURNED_BY_THE_QUERY>;

Behalten Sie jeden OracleDBEmbedder-Laufzeitvorgang innerhalb von OracleMemoryEndUserSecurityContext bei. Verwenden Sie den Schemaeigentümer, eine separate Administratorverbindung oder eine Verbindung ohne Endbenutzersicherheitskontext nicht, um Einbettungen für eine Benutzeranforderung auszuführen. Dies würde die Deep Sec-Autorisierungsgrenze umgehen.

Anwendung verstehen

Das herunterladbare Projekt deepsec_oci_iam_webapp.zip enthält die vollständigen Webanwendungs- und Datenbankskripte. Die wichtigsten Anwendungsstücke sind bewusst klein.

OAuth starten und abschließen

Die Anmeldungsroute erstellt zufällige state- und PKCE-Werte. Nur die undurchsichtige Session-ID wird in einem HttpOnly-, SameSite=Lax-Cookie abgelegt. Token bleiben im prozesslokalen Demo-Session-Speicher.

def start_authorization(config: RuntimeConfig) -> AuthorizationRequest:
    """Build a state-bound Authorization Code request with PKCE."""
    state = secrets.token_urlsafe(32)
    code_verifier = secrets.token_urlsafe(64)
    challenge = (
        base64.urlsafe_b64encode(hashlib.sha256(code_verifier.encode()).digest())
        .rstrip(b"=")
        .decode("ascii")
    )
    query = urllib.parse.urlencode(
        {
            "client_id": config.oauth_client_id,
            "response_type": "code",
            "redirect_uri": config.redirect_uri,
            "scope": config.end_user_scope,
            "state": state,
            "code_challenge": challenge,
            "code_challenge_method": "S256",
        }
    )
    return AuthorizationRequest(
        url=f"{config.domain_url}/oauth2/v1/authorize?{query}",
        state=state,
        code_verifier=code_verifier,
    )


def exchange_authorization_code(
    config: RuntimeConfig,
    code: str,
    code_verifier: str,
) -> EndUserToken:
    """Exchange one browser authorization code for an end-user token."""
    payload = _token_request(
        config,
        {
            "grant_type": "authorization_code",
            "code": code,
            "redirect_uri": config.redirect_uri,
            "code_verifier": code_verifier,
        },
    )
    access_token, expires_at = _required_access_token(payload)
    return EndUserToken(
        access_token=access_token,
        username=_display_username(access_token),
        expires_at=expires_at,
    )

Der Callback vergleicht state in konstanter Zeit und tauscht den Code mit derselben Umleitungs-URI und PKCE-Verifizierung aus. Die Anwendung ruft separat ein Datenbankzugriffstoken ab:

    def get(self, config: RuntimeConfig) -> str:
        """Return a current database-access token."""
        with self._lock:
            if self._token is not None and time.time() < self._expires_at - 60:
                return self._token
            payload = _token_request(
                config,
                {
                    "grant_type": "client_credentials",
                    "scope": config.database_access_scope,
                },
            )
            self._token, self._expires_at = _required_access_token(payload)
            return self._token

OCI IAM dokumentiert beide Tokenanforderungen unter OCI-IAM-Konfiguration validieren.

Umfang jedes Agent-Speichervorgangs

Die Anwendung kombiniert beide Token in einem python-oracledb-Endbenutzersicherheitskontext. Er gibt dann jede Speicherinitialisierung und jeden Vorgang mit OracleMemoryEndUserSecurityContext an:

def list_visible_memories(
    config: RuntimeConfig,
    pool: Any,
    user_context: Any,
) -> list[Any]:
    """List rows visible to the effective OCI IAM end user."""
    with OracleMemoryEndUserSecurityContext(user_context):
        store = create_runtime_store(config, pool)
        return store.list("memory", limit=100)


def add_memory(
    config: RuntimeConfig,
    pool: Any,
    user_context: Any,
    content: str,
    target_username: str,
) -> None:
    """Attempt to insert a row for the username supplied by the browser."""
    with OracleMemoryEndUserSecurityContext(user_context):
        store = create_runtime_store(config, pool)
        store.add(
            contents=[content],
            record_type="memory",
            user_ids=[target_username],
        )

Der Laufzeitspeicher verwendet SchemaPolicy.NO_CHECK, da Schemaerstellung, -validierung, -upgrades und -wiederherstellung zum Setuppfad des Schemaeigentümers gehören. Das SDK lehnt eine andere Schema-Policy ab, während der Endbenutzerkontext aktiv ist, und lehnt spätere Vorgänge in diesem geschützten Laufzeitspeicher ab, wenn kein Kontext aktiv ist. Die Sicherheitsverwaltungsfunktionen lehnen ebenfalls Verbindungen ab, die einen Endbenutzerkontext tragen.

Für jeden Agent Memory-Datenbankvorgang führt der Kontextmanager folgende Schritte aus:

Das Datenbankkonto des Pools verfügt nicht über Fallback-Tabellenberechtigungen. Die python-oracledb-Payload-API ist in Endbenutzersicherheitskontext - Payload-Erstellung dokumentiert. Mit der Deep Data Security-API und Sicherheitsreferenz wird der vollständige Vertrag des Kontextmanagers erläutert.

Lassen Sie die Datenbank entscheiden

Die Route leitet den weitergeleiteten Benutzernamen unverändert weiter. Er erfasst und bereinigt Datenbankfehler, enthält jedoch keine username == signed_in_user-Autorisierungsverzweigung:

@web.route("/", methods=["GET", "POST"])
def index() -> Response | tuple[str, int]:
    """Show visible memories and let the user attempt one insert."""
    config, pool, _ = _extensions()
    _, session = _session()
    if session is None or session.end_user_token is None:
        return render_template("index.html", session=None, memories=[])

    message = None
    status = 200
    try:
        user_context = _security_context(config, session)
        if request.method == "POST":
            if not hmac.compare_digest(
                request.form.get("csrf_token", ""),
                session.csrf_token,
            ):
                return render_template("error.html", message="The form expired."), 400
            content = request.form.get("content", "").strip()
            target_username = request.form.get("username", "").strip()
            if not content or not target_username:
                message = "Content and username are required."
                status = 400
            elif len(content) > 4000 or len(target_username) > 255:
                message = "The submitted memory is too large."
                status = 400
            else:
                try:
                    add_memory(
                        config,
                        pool,
                        user_context,
                        content,
                        target_username,
                    )
                    message = "Memory added."
                except oracledb.DatabaseError:
                    #Keep listing permitted rows after the deliberately denied write.
                    message = "Oracle AI Database denied this operation for the effective end user."
                    status = 403

        memories = list_visible_memories(config, pool, user_context)
    except oracledb.DatabaseError:
        #Never expose raw database errors, token contents, or submitted values.
        message = "Oracle AI Database denied this operation for the effective end user."
        memories = []
        status = 403
    except OAuthError:
        message = "The login session expired. Sign in again."
        memories = []
        status = 401

    return (
        render_template(
            "index.html",
            session=session,
            memories=memories,
            message=message,
        ),
        status,
    )

Jinja entweicht dem angezeigten Speicherinhalt. Raw-Datenbankausnahmen, OAuth-Antworten, Token und weitergeleitete Werte werden nie wiedergegeben.

Anwendung ausführen und prüfen

Starten Sie den Flask-Entwicklungsserver:

uv run python run.py

Öffnen Sie http://127.0.0.1:8000.

Prüfen Sie die Autorisierungsgrenze:

  1. Melden Sie sich als Alice an.
  2. Fügen Sie Alice's first memory mit dem vorausgefüllten Benutzernamen alice hinzu.
  3. Vergewissern Sie sich, dass der Speicher unter Sichtbare Speicher angezeigt wird.
  4. Fügen Sie Alice tries to write for Bob hinzu, ändern Sie den Benutzernamen jedoch in bob.
  5. Bestätigen Sie, dass Oracle AI Database den Vorgang ablehnt.
  6. Melden Sie sich ab, melden Sie sich als Bob an, und bestätigen Sie, dass Alices Gedächtnis nicht sichtbar ist.
  7. Fügen Sie einen Speicher als Bob hinzu, melden Sie sich als Alice wieder an, und bestätigen Sie, dass Bobs Gedächtnis nicht sichtbar ist.

Dies zeigt zwei unabhängige Kontrollen:

Konfigurieren Sie für Produktionsvorgänge Oracle Unified Auditing für die Deep Sec-Administration und die Sicherheitskontexte von Endbenutzern, die Ihre Organisation beibehalten muss. Außerdem Account für den dokumentierten Widerrufszeitvertrag: Der Widerruf der SDK-Policy wird vor der Rückgabe des Administrationsaufrufs festgeschrieben. Wenn Sie einen Benutzer aus einer OCI-IAM-Gruppe entfernen, wird kein bereits ausgestelltes Zugriffstoken neu geschrieben. Informationen zu Auditingrichtlinien, Tokenablaufverhalten und Links zur entsprechenden Dokumentation zu Oracle Deep Sec und OCI IAM finden Sie unter Deep Data Security.

Wenn die Anmeldung erfolgreich ist, die Datenbank jedoch jeden Vorgang ablehnt, prüfen Sie das Endbenutzertoken, und prüfen Sie, ob group ORACLEAGENTMEMORY_USERS enthält. Im Deep Data Security-Zugriff und Fehlerbehebung bei Berechtigungen von Oracle wird außerdem beschrieben, wie ein Administrator aktive Datenrollen prüfen kann.

Was die Produktion noch braucht

Warnung: Durch das Vervollständigen dieser Dokumentation ist das Beispiel nicht produktionsreif.

Bevor Sie das Design anpassen, ersetzen oder hinzufügen Sie mindestens:

Behalten Sie den Core unverändert bei: Der Laufzeitpoolaccount hat keine direkten DML-Berechtigungen für Tabellen, und jede Agent-Speicheranforderung wird innerhalb einer verifizierten OracleMemoryEndUserSecurityContext ausgeführt.