oracle代理认证仅传递身份，不提供权限隔离；必须配合会话级角色激活或database vault realm策略才能实现权限控制，否则代理用户仍可能越权操作。
Oracle代理认证（Proxy Authentication）本身不提供权限隔离，它只负责身份传递；真正的权限控制必须靠后续的会话级角色激活或细粒度策略配合，否则代理用户仍可能越权操作。
什么是代理认证，它能做什么、不能做什么
代理认证是 Oracle 提供的一种连接机制，允许一个已认证用户（PROXY_USER）以另一个用户（CLIENT_USER）身份建立会话，但不需知道后者的密码。典型用法：CONNECT proxy_user[client_user]。
它解决的是“应用服务统一登录 + 保留终端用户上下文”的问题，比如 Web 应用用 app_pool 连接数据库，再以 user123 身份执行语句。但它不会自动限制 user123 能做什么——如果 user123 拥有 DBA 角色，代理进来照样能删表。
- 能：复用连接池、审计链路可追溯到真实用户、避免密码明文传给中间层
- 不能：替代 RBAC、不触发 Database Vault Realm 检查（除非显式启用）、不自动收缩权限范围
必须配合会话级角色（SESSION_ROLES）做权限收缩
代理认证后，默认激活的角色仍是 CLIENT_USER 自身拥有的全部角色（包括 DBA）。要实现隔离，得在连接后立即切换角色：
ALTER SESSION SET ROLE app_reader_role;
这个动作必须由应用在每次连接初始化时显式执行。常见疏漏点：
- 忘记在连接池获取连接后调用
ALTER SESSION，导致后续所有 SQL 都运行在全权限上下文中 - 角色名硬编码在应用代码里，升级时未同步更新，造成权限失效或过度开放
- 没检查
ROLE是否真被激活：SELECT * FROM SESSION_ROLES;，误以为生效了
与 Database Vault Realm 结合才能阻断超级用户绕过
即使你用了代理认证 + 会话角色，SYS 或 DVOWNER 用户仍可能直接连入并操作敏感表——因为 Realm 默认不限制这些高权限账号。关键补救步骤：
- 确认
CLIENT_USER不属于DV_OWNER或DV_ACCTMGR角色（否则天然 bypass Realm） - 对每个 Realm 显式移除隐式授权：
DVSYS.DBMS_MACADM.REMOVE_AUTH_FROM_REALM('HR_Data_Realm', 'SYS') - 代理用户连接后，其会话受 Realm 策略实时拦截，此时
ORA-47401才真正生效
注意：CREATE REALM 时若设 enabled => TRUE，极易锁死自己，务必先关着测试。
容易被忽略的兼容性陷阱
代理认证在某些场景下行为异常，不是配置错，而是机制限制：
- Oracle RAC 中，不同实例间
SESSION_ROLES可能不同步，导致同一代理连接在 failover 后权限丢失 - 使用 JDBC Thin Driver 时，必须显式设置
oracle.jdbc.proxyClientName属性，否则sys_context('USERENV','PROXY_USER')返回空 - Database Vault 启用后，
ALTER SESSION SET ROLE若涉及被保护对象（如 role 包含对 realm 内表的 grant），可能被拦截报ORA-47401
最常出问题的地方不在代理本身，而在「代理之后谁来管权限」——没人激活受限角色，没人清理高权限账号的 Realm 授权，代理就只是个透明通道。
