Applica l'isolamento della memoria dell'utente finale con Deep Data Security

Questa guida mostra come applicare l'isolamento dell'utente finale per un'applicazione Oracle AI Agent Memory con OCI IAM e Oracle Deep Data Security.

Avvertenza: solo l'ambiente di apprendimento. Non distribuire questo esempio alla produzione.

L'applicazione utilizza il server di sviluppo Flask, un archivio di sessioni in-memory, segreti dei file di ambiente e gestione semplificata del ciclo di vita dei token. Gli script di impostazione del database modificano le impostazioni e i privilegi del provider di identità a livello di database. Utilizza solo utenti monouso e un Oracle Autonomous AI Database isolato e non di produzione.

Questa guida crea un'applicazione Web volutamente piccola:

Il percorso non mette a confronto Alice e Bob. Passa il token dell'utente finale a Oracle AI Database, dove Oracle Deep Data Security applica il criterio della riga personale della memoria dell'agente.

Questa guida illustra una distribuzione. Per la funzione di sicurezza completa, inclusi tutti i criteri, i principal, le funzioni di amministrazione, le API del contesto di runtime, le tempistiche di auditing e revoca, vedere Deep Data Security API and security reference.

In questa guida potrai:

Comprendere la catena di fiducia

Il browser e l'applicazione utilizzano due token di accesso OAuth diversi:

  1. Il token utente finale identifica Alice o Bob e include i gruppi IAM dell'utente.
  2. Il token di accesso al database, ottenuto dall'applicazione riservata tramite le credenziali client, dimostra che l'applicazione può accedere alla risorsa del database.

Oracle AI Database convalida entrambi i token prima di collegare il contesto di sicurezza dell'utente finale.

Oracle documenta questo modello a due token in Comprendere il flusso di autenticazione e i prerequisiti e l'intero ciclo di vita in Contesto di sicurezza dell'utente finale.

Prerequisiti

È necessario:

Oracle Deep Data Security è un'autorizzazione con filtro applicata al database. Vedere Che cos'è Oracle Deep Data Security.

Configurare il dominio di Identity IAM OCI

Eseguire tutte le operazioni IAM OCI in un unico dominio di Identity. Registrare il relativo URL dominio, ad esempio https://idcs-<id>.identity.oraclecloud.com:443.

L'autorevole procedura guidata Oracle è Configura OCI IAM per l'accesso mediato dall'applicazione. I valori nell'esempio seguente corrispondono al file di ambiente di esempio fornito con questa guida.

Registra la risorsa di database

In Dominio di identità > Applicazioni integrate:

  1. Aggiungere un'applicazione riservata denominata OracleDB.
  2. Configura come server risorse:
    • Audience principale: OracleDB
    • Ambito: DB_ACCESS_SCOPE
  3. Configurare il client e consentire le credenziali client.
  4. Attivalo.
  5. Registrare i relativi ID applicazione, ID client e segreto client.

L'ambito del database completamente qualificato è l'audience concatenata al nome dell'ambito:

OracleDBDB_ACCESS_SCOPE

Seguire Registrare il database in OCI IAM per le etichette della console corrente e le descrizioni dei campi.

Registra l'applicazione Web

Aggiungere una seconda applicazione riservata denominata OracleAgentMemoryWeb:

  1. Abilitare Applica privilegi come autorizzazione.
  2. Configura come server risorse:
    • Audience principale: OracleAgentMemoryWeb
    • Ambito: APP_ACCESS_SCOPE
    • Durata del token di accesso: 3600 secondi per questo esercizio
  3. Configurare un client con le autorizzazioni riportate di seguito.
    • Codice di autorizzazione
    • Credenziali client
  4. Aggiungi questo URL di reindirizzamento esatto: 
    http://127.0.0.1:8000/auth/callback
  5. In Risorse client, concedere l'accesso a entrambi gli elementi riportati di seguito.
    • OracleDBDB_ACCESS_SCOPE
    • OracleAgentMemoryWebAPP_ACCESS_SCOPE
  6. Attivare l'applicazione e registrare i relativi ID client e segreto client.

L'applicazione utilizza il codice di autorizzazione con state e PKCE S256. IAM OCI documenta la configurazione client richiesta in Registrare l'applicazione in IAM OCI e fornisce un esempio di codice di autorizzazione PKCE.

Aggiungi richiesta di risarcimento di gruppo

Oracle AI Database attiva i ruoli dati mappati esternamente dalla richiesta group del token dell'utente finale. Le richieste personalizzate IAM OCI vengono configurate tramite l'API REST del dominio di identità, non la console.

In qualità di amministratore del dominio di Identity, scaricare un token di accesso personale di breve durata in grado di richiamare le API del dominio di Identity. Quindi eseguire:

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
  }'

Una richiesta riuscita restituisce HTTP 201. Non creare un duplicato se il dominio ha già questa richiesta. Vedere Configura richieste di risarcimento personalizzate per informazioni di gruppo in OCI IAM.

Creare Alice, Bob e il gruppo di applicazioni

  1. Creare un gruppo denominato ORACLEAGENTMEMORY_USERS.
  2. Creare gli utenti di test alice e bob.
  3. Assegnare entrambi gli utenti a ORACLEAGENTMEMORY_USERS.
  4. Assegnare il gruppo a OracleAgentMemoryWeb.

Il database mapperà in seguito questo nome di gruppo a un ruolo dati. I nomi dei gruppi vengono confrontati senza distinzione tra maiuscole e minuscole, ma utilizzano la stessa ortografia durante l'impostazione. Vedere Crea utenti e assegna gruppi in IAM OCI.

Preparare l'ambiente

Scaricare l'applicazione Web completa deepsec_oci_iam_webapp.zip. L'archivio contiene inoltre script di impostazione e ispezione del database standalone di proprietà di questo esempio. Non importano o impacchettano script dalla suite di test SDK.

Estrarre l'archivio, immettere la relativa directory di progetto e creare file di ambiente di configurazione e runtime locali:

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))"

Inserire il valore generato in OAM_WEB_SECRET_KEY e popolare ogni segnaposto richiesto in entrambi i file. Entrambi i nomi dei file vengono ignorati da Git.

La directory database_scripts contiene:

File Responsabilità
_common.sh Applicazione di supporto privata che carica .deepsec.env, convalida i valori richiesti, verifica la presenza di SQL*Plus ed esporta TNS_ADMIN quando configurato. Non eseguire direttamente il programma.
db_ociiam_setup.sh Abilita l'autenticazione esterna IAM OCI per Autonomous AI Database di destinazione e sostituisce OCI_IAM_DOMAIN_DB_CRED$.
db_deepsec_user_setup.sh Crea gli utenti schema-owner e app-pool e concede le liste di inclusione dei privilegi documentati.
db_list_all_data_roles.sh Esegue un'ispezione in sola lettura dei ruoli di Deep Data Security, dei mapping IAM, delle concessioni di dati, dei predicati, degli oggetti protetti, degli utenti finali e delle identità delle applicazioni.

.deepsec.env viene utilizzato solo dall'impostazione del database. Include le password amministratore della sicurezza e proprietario dello schema. .deepsec.runtime.env viene caricato dal processo Flask ed esclude intenzionalmente entrambe le password con privilegi. Non esportare il file di installazione nella shell che avvia l'applicazione Web. Per utilizzare percorsi diversi, impostare OAM_DEEPSEC_ENV_FILE per l'impostazione o OAM_WEB_ENV_FILE per il processo Web.

I valori IAM importanti vengono mappati come indicato di seguito.

Variabile d'ambiente Valore IAM OCI
OAM_DEEPSEC_OCI_DB_APP_ID ID applicazione dell'applicazione di database
OAM_DEEPSEC_OCI_DB_CLIENT_ID ID client dell'applicazione di database
OAM_DEEPSEC_OCI_DB_CLIENT_SECRET Segreto client dell'applicazione di database
OAM_WEB_OCI_CLIENT_ID ID client dell'applicazione Web
OAM_WEB_OCI_CLIENT_SECRET Segreto client dell'applicazione Web
OAM_WEB_OCI_END_USER_SCOPE OracleAgentMemoryWebAPP_ACCESS_SCOPE
OAM_WEB_OCI_DATABASE_ACCESS_SCOPE OracleDBDB_ACCESS_SCOPE

OAM_DEEPSEC_CONFIG_DIR è necessario solo quando il DSN è un alias TNS il cui tnsnames.ora non è altrimenti individuabile. La posizione e la password del wallet sono facoltative quando sqlnet.ora e il DSN forniscono già tutto ciò di cui ha bisogno python-oracledb. Per le opzioni di connessione ad Autonomous AI Database, vedere Connetti le applicazioni Python con un wallet.

Configurare anche un provider di incorporamento. L'applicazione elenca e aggiunge solo le memorie, ma la memoria agente crea ancora incorporamenti quando memorizza il contenuto della memoria. Il modello utilizza come esempio un modello compatibile con OpenAI; sostituire il modello, la base API, la chiave e la dimensione con i valori del provider.

Configurare i tre account di database

Avvertenza: i comandi di questa sezione modificano le impostazioni di autenticazione esterna e i privilegi dell'account a livello di database. Prima ispezionare gli script. Non eseguirli in un database condiviso o di produzione.

Utilizzare tre utenti distinti del database:

Responsabilità Account di esempio Lavoro consentito
Amministratore della sicurezza ADMIN Abilita l'integrazione IAM OCI e crea, concede, revoca, elenca e rimuove i ruoli dati e le autorizzazioni dati. Non viene mai utilizzato per le richieste web.
Proprietario schema gestito OAM_SCHEMA_OWNER Crea tabelle di memoria agente, indici, procedure e job scheduler. Utilizzato solo per le operazioni del ciclo di vita dello schema.
Utente DB applicazione OAM_APP_DB_USER Apre le sessioni e collega i contesti di sicurezza dell'utente finale. Non riceve privilegi ordinari SELECT, INSERT, UPDATE o DELETE.

Questa separazione fa sì che una richiesta senza un contesto utente finale valido non venga chiusa. La guida alla configurazione del database di Oracle consiglia CREATE SESSION e CREATE END USER SECURITY CONTEXT per l'account connection pool. Vedere Configurare il database per l'integrazione IAM.

L'esempio utilizza l'account Autonomous AI Database ADMIN per l'impostazione. Un account di amministratore della sicurezza personalizzato deve essere in grado di creare e modificare i due utenti del database e concedere i privilegi di sistema elencati. Poiché le tabelle di memoria agente appartengono a uno schema separato, l'amministrazione dei criteri richiede CREATE ANY DATA GRANT, DROP ANY DATA GRANT e ADMINISTER ANY DATA GRANT anziché solo CREATE DATA GRANT nello schema dell'amministratore. Inoltre, deve essere autorizzato a creare ed eliminare i ruoli dati utilizzati dai criteri.

Abilita convalida token IAM OCI

Esamina ed esegui

bash database_scripts/db_ociiam_setup.sh

Lo script si connette come amministratore della sicurezza e:

Può essere attivo un solo provider di identità esterno. Lo script di esempio utilizza force => TRUE per aggiornare i parametri IAM OCI, che possono interrompere un'altra configurazione di autenticazione esterna. Oracle documenta le chiamate esatte di Autonomous Database in Configura database per integrazione IAM.

Creare il proprietario e gli utenti del pool

Esamina ed esegui

bash database_scripts/db_deepsec_user_setup.sh

Lo script non modifica ADMIN. Crea il proprietario e gli utenti del pool di applicazioni e concede:

-- 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

Il proprietario riceve la quota nella tablespace Autonomous AI Database DATA. L'utente del pool non riceve privilegi diretti sulle tabelle del proprietario. Per mantenere l'esempio focalizzato sulle istruzioni richieste, lo script non controlla gli utenti esistenti né ispeziona i privilegi correnti. Utilizzare i nomi dei nuovi account; lo script si interrompe se un utente esiste già o se un'altra istruzione SQL non riesce.

Creare il criterio negozio e riga personale

Installare l'ambiente di esempio standalone:

uv sync

Eseguire quindi il programma di installazione:

uv run python scripts/setup_memory.py

Questo comando è intenzionalmente distruttivo solo per OAM_WEB_MEMORY_STORE_ID. La proprietà:

  1. si connette come proprietario dello schema per ricreare lo schema di memoria dell'agente;
  2. si connette come amministratore della sicurezza per aggiungere il criterio della propria riga e concederlo a ORACLEAGENTMEMORY_USERS.

Le chiamate di amministrazione Aggiungi e Concedi sono idempotenti. La loro riesecuzione sostituisce le stesse definizioni e assegnazioni dei criteri gestiti e il nuovo tentativo di riparare le DDL gestite parziali lasciate da un tentativo interrotto.

Il criterio crea un ruolo dati mappato esternamente per il gruppo IAM OCI e le concessioni dati il cui predicato riga confronta i valori user_id memorizzati con ORA_END_USER_CONTEXT.username. Oracle documenta la sintassi del mapping in CREATE DATA ROLE e l'autorizzazione riga in CREATE DATA Grants.

Controllare il risultato:

bash database_scripts/db_list_all_data_roles.sh

È necessario visualizzare il ruolo mappato su IAM, le autorizzazioni dei dati della memoria agente e le relative tabelle proprietario-schema protette. Questo script di ispezione esegue solo query sulle viste catalogo e non crea, modifica o rimuove oggetti di Deep Data Security.

Usa un modello di incorporamento nel database con Deep Sec

Questa sezione si applica quando l'applicazione utilizza OracleDBEmbedder con il provider="database" predefinito e un modello di incorporamento memorizzato in Oracle AI Database, in genere un modello ONNX importato come DMUSER.DOC_MODEL. In questa configurazione, l'incorporamento diretto utilizza l'operatore SQL VECTOR_EMBEDDING di Oracle, pertanto il modello richiede il privilegio SELECT ON MINING MODEL descritto di seguito.

OracleDBEmbedder supporta anche i provider remoti tramite DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING, ad esempio provider="openai". Tali configurazioni richiamano ancora la richiesta di incorporamento da Oracle AI Database, ma non accedono a un modello di mining residente nel database; le istruzioni SELECT ON MINING MODEL riportate in questa sezione non sono applicabili. Le operazioni della memoria agente devono comunque essere eseguite all'interno di un file OracleMemoryEndUserSecurityContext.

Un criterio di memoria agente concede l'accesso alle tabelle di memoria agente. Non concede l'accesso a un modello di incorporamento di Oracle AI Database. Il modello deve disporre del proprio privilegio di database: SELECT ON MINING MODEL.

Non concedere tale privilegio all'utente del pool di applicazioni. Durante una richiesta, Deep Sec autorizza l'utente tramite il ruolo dati mappato dal gruppo IAM OCI, non tramite i normali privilegi dell'utente del pool. Un privilegio concesso solo all'utente del pool non è pertanto disponibile mentre è attivo un contesto di sicurezza dell'utente finale.

Creare un ruolo dati mappato per ogni gruppo IAM che deve utilizzare il modello. Assegnare a tale ruolo dati un ruolo di database normale che dispone dell'accesso al modello. Eseguire l'istruzione SQL seguente come amministratore della sicurezza del database o un altro account autorizzato a creare ruoli e concedere l'accesso al modello. Sostituire i nomi di esempio con i nomi dell'applicazione:

-- 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;

L'applicazione utilizza quindi lo stesso nome di gruppo quando concede i criteri di memoria agente:

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() trova il ruolo esistente mappato a YOUR_IAM_GROUP e aggiunge le autorizzazioni dei dati della tabella di memoria agente allo stesso ruolo. Non crea un secondo ruolo. In fase di runtime, un utente il cui token IAM OCI contiene YOUR_IAM_GROUP può accedere sia alle righe di memoria agente consentite che a DMUSER.DOC_MODEL.

Se l'applicazione ha già chiamato grant_agent_memory_policies() prima dell'impostazione del modello, la memoria agente ha già creato il ruolo dati mappato. Non creare un altro ruolo mappato per lo stesso gruppo. Trova il ruolo esistente e concedi invece il ruolo di modello ordinario:

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>;

Conservare ogni operazione OracleDBEmbedder runtime all'interno di OracleMemoryEndUserSecurityContext. Non utilizzare il proprietario dello schema, una connessione amministratore separata o una connessione senza un contesto di sicurezza dell'utente finale per eseguire incorporamenti per una richiesta utente. Ciò bypasserebbe il limite di autorizzazione di Deep Sec.

Comprendere l'applicazione

Il progetto scaricabile, deepsec_oci_iam_webapp.zip, contiene gli script completi dell'applicazione Web e del database. I pezzi chiave dell'applicazione sono volutamente piccoli.

Avvio e completamento di OAuth

L'instradamento di login crea valori casuali state e PKCE. Solo l'ID di sessione opaco viene inserito in un cookie HttpOnly, SameSite=Lax; i token rimangono nell'archivio di sessione demo process-local.

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,
    )

Il callback confronta state in tempo costante e scambia il codice con lo stesso URI di reindirizzamento e verificatore PKCE. L'applicazione ottiene separatamente un token di accesso al database:

    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

IAM OCI documenta entrambe le richieste di token in Convalidare la configurazione IAM OCI.

Ambito di ogni operazione di memoria agente

L'applicazione combina entrambi i token in un contesto di sicurezza dell'utente finale python-oracledb. Quindi definisce ogni inizializzazione e operazione del negozio con OracleMemoryEndUserSecurityContext:

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],
        )

L'area di memorizzazione runtime utilizza SchemaPolicy.NO_CHECK perché la creazione, la convalida, gli aggiornamenti e la ricreazione dello schema appartengono al percorso di impostazione del proprietario dello schema. L'SDK rifiuta un altro criterio di schema mentre il contesto dell'utente finale è attivo e rifiuta le operazioni successive in questa area di memorizzazione runtime protetta quando non è attivo alcun contesto. Le funzioni di amministrazione della sicurezza rifiutano anche le connessioni che portano un contesto utente finale.

Per ogni operazione del database di memoria dell'agente, context manager:

L'account di database del pool non dispone dei privilegi della tabella di fallback. L'API del payload python-oracledb è documentata in Creazione del payload del contesto di sicurezza dell'utente finale. L'API Deep Data Security e il riferimento alla sicurezza spiegano il contratto completo del manager del contesto.

Lascia che il database decida

Il percorso inoltra il nome utente inviato invariato. Recupera e sanifica gli errori del database, ma non contiene alcuna diramazione di autorizzazione username == signed_in_user:

@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 sfugge al contenuto di memoria visualizzato. Le eccezioni del database raw, le risposte OAuth, i token e i valori sottomessi non vengono mai visualizzati.

Eseguire e verificare l'applicazione

Avviare il server di sviluppo Flask:

uv run python run.py

Aprire http://127.0.0.1:8000.

Verificare il limite di autorizzazione:

  1. Accedi come Alice.
  2. Aggiungere Alice's first memory con il nome utente precompilato alice.
  3. Verificare che la memoria venga visualizzata in Memorie visibili.
  4. Aggiungere Alice tries to write for Bob ma modificare il nome utente in bob.
  5. Confermare che Oracle AI Database nega l'operazione.
  6. Uscire, accedere come Bob e confermare che la memoria di Alice non è visibile.
  7. Aggiungere una memoria come Bob, accedere nuovamente come Alice e confermare che la memoria di Bob non è visibile.

Ciò dimostra due controlli indipendenti:

Per le operazioni di produzione, configurare Oracle Unified Auditing per le azioni di amministrazione Deep Sec e di contesto di sicurezza dell'utente finale che l'organizzazione deve mantenere. Inoltre, tenere conto del contratto relativo al tempo di revoca documentato: viene eseguito il commit della revoca dei criteri SDK prima che vengano restituite le chiamate di amministrazione, mentre la rimozione di un utente da un gruppo IAM OCI non riscrive un token di accesso già emesso. Vedere Deep Data Security per le linee guida di auditing, il funzionamento della scadenza del token e i collegamenti alla documentazione Oracle Deep Sec e OCI IAM corrispondente.

Se il login riesce ma il database nega ogni operazione, esaminare il token dell'utente finale e verificare che group contenga ORACLEAGENTMEMORY_USERS. La risoluzione dei problemi di accesso e privilegio Deep Data Security di Oracle descrive inoltre come un amministratore può ispezionare i ruoli dati attivi.

Cosa richiede ancora la produzione

Avvertenza: il completamento di questa guida non rende l'esempio pronto per la produzione.

Prima di adattare il design, sostituire o aggiungere almeno:

Mantenere invariante la memoria di base: l'account del pool runtime non dispone di privilegi DML della tabella diretta e ogni richiesta di memoria agente viene eseguita all'interno di un file OracleMemoryEndUserSecurityContext verificato.