mirror of
https://github.com/hoshikawa2/agent_platform_oci.git
synced 2026-09-07 18:23:46 +00:00
166 lines
6.9 KiB
Markdown
166 lines
6.9 KiB
Markdown
# Autenticação / Authentication
|
|
|
|
> Feature do `agent_framework_oci` — guia bilíngue PT-BR / EN.
|
|
|
|
**Implementação principal / Main implementation:** `security/authentication.py`
|
|
|
|
---
|
|
|
|
## Português (PT-BR)
|
|
|
|
### 1. O que é
|
|
|
|
Verifica quem pode acessar APIs, gateways e serviços protegidos antes que a requisição chegue ao agente.
|
|
|
|
### 2. Problema que resolve
|
|
|
|
Em agentes de produção, não é suficiente pedir ao LLM que “faça a coisa certa”. Esta feature move uma responsabilidade específica para uma camada controlada do framework, reduzindo comportamento imprevisível e código duplicado nos agentes de domínio.
|
|
|
|
### 3. Fluxo simplificado
|
|
|
|
```text
|
|
Cliente/Sistema
|
|
↓
|
|
Authentication Provider
|
|
↓
|
|
credencial válida?
|
|
├─ não → 401/nega acesso
|
|
└─ sim → principal autenticado → agente
|
|
```
|
|
|
|
### 4. Como funciona internamente
|
|
|
|
O framework contém uma abstração `AuthenticationProvider` e implementações para cenários diferentes. Entre as implementações atuais estão `NoAuthenticationProvider`, `DenyAuthenticationProvider`, `BasicAuthenticationProvider`, `ApiKeyAuthenticationProvider`, `StaticBearerAuthenticationProvider`, `JwtAuthenticationProvider`, `OAuth2IntrospectionAuthenticationProvider` e `TrustedProxyAuthenticationProvider`.
|
|
|
|
A autenticação produz um `AuthenticatedPrincipal` com `subject`, `scheme` e, quando aplicável, `claims`. A regra de negócio do agente não deve validar senha/token diretamente.
|
|
|
|
### 5. Como ativar/configurar
|
|
|
|
A ativação exata depende do template/agente. Verifique o arquivo de settings, YAMLs de configuração e o template usado pelo serviço. Nem toda feature precisa de uma flag global: algumas são ativadas pelo contrato retornado por uma tool/workflow.
|
|
|
|
### 6. Exemplo
|
|
|
|
```python
|
|
from agent_framework.security.authentication import BasicAuthenticationProvider
|
|
|
|
provider = BasicAuthenticationProvider(
|
|
client_id="client-a",
|
|
secret_hash="pbkdf2_sha256:...",
|
|
)
|
|
result = await provider.authenticate(request)
|
|
if not result.authenticated:
|
|
# negar acesso
|
|
...
|
|
```
|
|
|
|
Segredos podem ser verificados em formato simples, SHA-256 ou PBKDF2; em produção, prefira hashes fortes e secret stores.
|
|
|
|
### 7. Telemetria e observabilidade
|
|
|
|
Quando a feature participa de uma execução de agente, preserve `request_id`, `trace_id`, `session_id`, `agent_id`, `message_id` e demais chaves de correlação no estado/eventos. Isso permite acompanhar a decisão no Langfuse/Observer sem colocar lógica de observabilidade dentro do domínio.
|
|
|
|
### 8. Como testar
|
|
|
|
1. Crie um teste unitário do comportamento principal.
|
|
2. Crie um teste de integração do runtime quando houver estado entre turns.
|
|
3. Verifique o caso feliz e pelo menos um caso de falha/negação.
|
|
4. Confirme que não há side effects duplicados em retry/replay quando a feature toca transações.
|
|
5. Em produção, valide também telemetria e correlação de IDs.
|
|
|
|
### 9. Erros comuns
|
|
|
|
- Basic auth retornando 401: validar `Authorization: Basic ...` e o secret configurado.
|
|
- Confundir autenticação do usuário com `OCI_AUTH_MODE`: são problemas diferentes.
|
|
- Usar `NoAuthenticationProvider` em produção sem decisão explícita de arquitetura.
|
|
|
|
### 10. Relação com outras features
|
|
|
|
Esta feature deve ser usada junto das demais capacidades horizontais do framework, em vez de criar uma implementação paralela no agente de domínio. Em fluxos transacionais, considere especialmente **Clarification**, **Pause/Resume**, **Durable Idempotency**, **Workflow Error Recovery** e **Guardrails**.
|
|
|
|
### 11. Referências no repositório
|
|
|
|
- `libs/agent_framework/src/agent_framework/security/authentication.py`
|
|
- `Tuning-Performance/`
|
|
- `Documentacao/`
|
|
- `libs/agent_framework/docs/`
|
|
|
|
---
|
|
|
|
## English (EN)
|
|
|
|
### 1. What it is
|
|
|
|
Checks who may access protected APIs, gateways, and services before the request reaches the agent.
|
|
|
|
### 2. Problem it solves
|
|
|
|
Production agents should not rely on prompts alone to “do the right thing”. This feature moves a specific responsibility into a controlled framework layer, reducing unpredictable behavior and duplicate domain-agent code.
|
|
|
|
### 3. Simplified flow
|
|
|
|
```text
|
|
Client/System
|
|
↓
|
|
Authentication Provider
|
|
↓
|
|
valid credential?
|
|
├─ no → 401/deny
|
|
└─ yes → authenticated principal → agent
|
|
```
|
|
|
|
### 4. How it works internally
|
|
|
|
The framework exposes an `AuthenticationProvider` abstraction with multiple implementations. Current providers include `NoAuthenticationProvider`, `DenyAuthenticationProvider`, `BasicAuthenticationProvider`, `ApiKeyAuthenticationProvider`, `StaticBearerAuthenticationProvider`, `JwtAuthenticationProvider`, `OAuth2IntrospectionAuthenticationProvider`, and `TrustedProxyAuthenticationProvider`.
|
|
|
|
Authentication produces an `AuthenticatedPrincipal` containing `subject`, `scheme`, and optional `claims`. Domain code should not validate credentials directly.
|
|
|
|
### 5. How to enable/configure
|
|
|
|
Exact activation depends on the template/agent. Check framework settings, YAML configuration, and the service template. Not every feature requires a global flag: some are activated by the contract returned from a tool/workflow.
|
|
|
|
### 6. Example
|
|
|
|
```python
|
|
from agent_framework.security.authentication import BasicAuthenticationProvider
|
|
|
|
provider = BasicAuthenticationProvider(
|
|
client_id="client-a",
|
|
secret_hash="pbkdf2_sha256:...",
|
|
)
|
|
result = await provider.authenticate(request)
|
|
if not result.authenticated:
|
|
# deny access
|
|
...
|
|
```
|
|
|
|
Secrets may be verified as plain, SHA-256, or PBKDF2 values; for production, prefer strong hashes and managed secret stores.
|
|
|
|
### 7. Telemetry and observability
|
|
|
|
When the feature participates in an agent execution, preserve `request_id`, `trace_id`, `session_id`, `agent_id`, `message_id`, and other correlation keys in state/events. This makes the decision observable through Langfuse/Observer without embedding observability logic in the domain.
|
|
|
|
### 8. How to test
|
|
|
|
1. Add a unit test for the core behavior.
|
|
2. Add a runtime integration test when state spans multiple turns.
|
|
3. Test the happy path and at least one failure/rejection path.
|
|
4. Confirm retries/replays do not duplicate side effects for transactional features.
|
|
5. In production, also validate telemetry and ID correlation.
|
|
|
|
### 9. Common mistakes
|
|
|
|
- Basic auth returns 401: validate the `Authorization: Basic ...` header and configured secret.
|
|
- Do not confuse API authentication with `OCI_AUTH_MODE`; they solve different problems.
|
|
- Avoid `NoAuthenticationProvider` in production unless explicitly accepted by architecture.
|
|
|
|
### 10. Relationship with other features
|
|
|
|
Use this feature together with the framework's horizontal capabilities rather than creating a parallel implementation in domain-agent code. For transactional journeys, pay special attention to **Clarification**, **Pause/Resume**, **Durable Idempotency**, **Workflow Error Recovery**, and **Guardrails**.
|
|
|
|
### 11. Repository references
|
|
|
|
- `libs/agent_framework/src/agent_framework/security/authentication.py`
|
|
- `Tuning-Performance/`
|
|
- `Documentacao/`
|
|
- `libs/agent_framework/docs/`
|