Security

Remember Fred is only a great starting example. Should you use it to design your own solution; here is a recap of its current security architecture.

Security FeatureImplementation
AuthenticationKeycloak (OIDC)
User RolesAdmin, Editor, Viewer
RBAC EnforcementBackend API checks user roles
WebSocket SecurityToken authentication per session
Document Store AccessOnly admins can upload/delete
Audit LoggingTracks key actions
Session IsolationUsers cannot see each other’s conversations

Authentication with Keycloak (OIDC)

Fred’s UI is built with TypeScript (React) and includes Keycloak authentication to manage user identities.

🔹 How It Works

  1. The UI redirects users to Keycloak for authentication.
  2. After login, Keycloak issues an OIDC access token (JWT).
  3. The UI stores the token securely and includes it in API requests.
  4. The Python backend verifies the token before processing any request.
  5. User roles are extracted from the token to enforce access control.

🔹 User Roles Keycloak assigns roles to users based on their permissions. If you use the default docker compose setup, you will have three users with:

  • Admin: Full access, can upload/delete documents, manage chat sessions, and configure agents.
  • Editor: Can modify some settings but cannot delete critical data.
  • Viewer: Can only read data and interact with chatbots but cannot modify or delete anything.

Backend

The backend is protected using OIDC-based authentication. Every request to the API must include a valid Keycloak token.

  • Token Verification: Each request is validated against Keycloak.
  • Role-Based Access Control (RBAC): Users can only perform actions allowed by their roles.
  • Session Isolation: Users cannot access chatbot conversations from other users.
  • Audit Logging: Important actions (e.g., document uploads, chatbot queries) are logged.