这篇文章主要讲解应用程序客户端访问数据库的新特性有些地方理解不好
写得也不是很好请大家帮忙指正谢谢！
I安全认证拥有
解决了阻止未经认证的用户通过其他客户端访问数据的问题
在隐藏密码的实现方面有了比以前更好的机制
角色的有效性是通过一个包来检测而不是一个口令
……应用设置的概念在i中已经作了介绍i中细粒度访问控制能够达到制作有效的私有数据库而在i中应用设置已经可以用一个角色来实现因此提高了私有数据库的可用性
为了确认一个角色是否有效必须调用关联的存储过程这个存储过程可以通过使用sys_context（userenvnnn）来制定一系列的额外检查nnn可以是ip_addressproxy_account等（举例我们可以在存储过程和触发器里调用select sys_context（userenvip_address） from dual得到客户端的ip然后根据这个资料进行判断sys_context的具体用法如下
select
SYS_CONTEXT(USERENVTERMINAL) terminal
SYS_CONTEXT(USERENVLANGUAGE) language
SYS_CONTEXT(USERENVSESSIONID) sessionid
SYS_CONTEXT(USERENVINSTANCE) instance
SYS_CONTEXT(USERENVENTRYID) entryid
SYS_CONTEXT(USERENVISDBA) isdba
SYS_CONTEXT(USERENVNLS_TERRITORY) nls_territory
SYS_CONTEXT(USERENVNLS_CURRENCY) nls_currency
SYS_CONTEXT(USERENVNLS_CALENDAR) nls_calendar
SYS_CONTEXT(USERENVNLS_DATE_FORMAT) nls_date_format
SYS_CONTEXT(USERENVNLS_DATE_LANGUAGE) nls_date_language
SYS_CONTEXT(USERENVNLS_SORT) nls_sort
SYS_CONTEXT(USERENVCURRENT_USER) current_user
SYS_CONTEXT(USERENVCURRENT_USERID) current_userid
SYS_CONTEXT(USERENVSESSION_USER) session_user
SYS_CONTEXT(USERENVSESSION_USERID) session_userid
SYS_CONTEXT(USERENVPROXY_USER) proxy_user
SYS_CONTEXT(USERENVPROXY_USERID) proxy_userid
SYS_CONTEXT(USERENVDB_DOMAIN) db_domain
SYS_CONTEXT(USERENVDB_NAME) db_name
SYS_CONTEXT(USERENVHOST) host
SYS_CONTEXT(USERENVOS_USER) os_user
SYS_CONTEXT(USERENVEXTERNAL_NAME) external_name
SYS_CONTEXT(USERENVIP_ADDRESS) ip_address
SYS_CONTEXT(USERENVNETWORK_PROTOCOL) network_protocol
SYS_CONTEXT(USERENVBG_JOB_ID) bg_job_id
SYS_CONTEXT(USERENVFG_JOB_ID) fg_job_id
SYS_CONTEXT(USERENVAUTHENTICATION_TYPE) authentication_type
SYS_CONTEXT(USERENVAUTHENTICATION_DATA) authentication_data
from dual
i以前的版本认证角色是通过password的方法将用户名口令写入应用程序来进行连接
这样的缺点是如果口令在客户端被解析出来任何应用程序都能够访问你的数据
下面我们看一个i认证角色的例子
CREATE ROLE salesuser
IDENTIFIED USING shsales_chk;
CREATE OR REPLACE PROCEDURE sales_chk
AUTHID CURRENT_USER IS
ipchk STRING();
BEGIN /* Only certain IP addresses allowed */
SELECT SYS_CONTEXT(USERENVIP_ADDRESS)
INTO ipchk FROM DUAL;
IF SUBSTR(ipchk) !=
THEN RETURN; END IF; /* Fail silently */
DBMS_SESSIONSET_ROLE(SALESUSER); /* Enable */
END;
/
这个过程做到如果不在网段这个角色失效
全局应用设置
一个设置现在能够被全局化和共享
全局化应用设置就是:
比每个进程一个设置更节省资源
利用有效私有数据库能够更好的适应基于web的应用
仍然可以通过identifier验证访问权限
更适应多路连接
oraclei的有效私有数据库特性提供了连接池以允许多重会话使用一个或多个全局应用设置而不需要为每个用户建立一个应用设置全局应用设置为基于web的应用提供了额外的灵活的设置在多重会话中重复利用普通应用设置大大提高了性能
在ebusiness应用中应用用户代理认证可以使用公用应用设置来提高适应性和性能通过公用应用设置的一次设立代替为每个会话独立设置初始化应用设置这种方式进行会话级重用提高了性能
为了决定当前会话的运行环境以符合细粒度访问控制中间件必须为每一个应用设定应用设置全局设置允许中间件把各种应用设置存储在实例里并且在会话建立时为一个用户会话指派设置这个设置也就成为了会话的运行设置这将大大减小用户会话在应用连接池环境中的建立时间
管理全局应用设置
一些接口已经被加到dbms_session包里来管理客户端会话的应用设置
包括
set_context
clear_context
set_identifier
clear_identifier
为了支持通过中间件应用管理的会话连接池对于dbms_session接口的管理应用设置也为每一个应用设置增加了一个客户端认证在这种方式下我们可以全局管理应用设置而客户端仅仅看到为他们设置的应用设置
中间件应用器服务能够使用set_context来为一个制定的客户id设置应用设置那么当分配数据库连接来处理客户端需求应用服务器需要执行set_identifier来表示这个应用会话的id那么每次客户端调用sys_context仅仅被指派给这个验证用户的设置被返回
全局应用设置函数（举例）
管理员通过以下指令建立全局设置
SQL> CREATE CONTEXT webhr USING hrinit ACCESSED GLOBALLY;
应用服务器启动将为HR用户建立多重连接
当用户JOHN连接到应用服务器后JOHN不是一个数据库用户应用服务器将在应用里鑒别JOHN并且为这个连接设置一个临时的会话ID基于唯一应用会话属性这个会话ID作为COOKIE或者应用服务器的维护的一部分返回用户JOHN的浏览器
应用服务器为这个客户端初始应用设置称为HRINIT包它执行
DBMS_SESSIONSET_CONTEXT(webhrid JOHN HR);
DBMS_SESSIONSET_CONTEXT(webhrdepsalesHR);
例子
CREATE CONTEXT webhr USING hrinit ACCESSED GLOBALLY;
DBMS_SESSIONSET_CONTEXT(webhridJOHNHR);
DBMS_SESSIONSET_IDENTIFIER();
…
SYS_CONTEXT calls are in Johns context
…
DBMS_SESSIONCLEAR_IDENTIFIER();
当用户JOHN用应用服务器访问数据应用服务器找到所有登陆的会话并执行DBMS_SESSIONSET_IDENTIFIER（）所有的这个会话的SYS_CONTEXT将只返回属于这个客户端的应用程序设置例如SYS_CONTEXT（WEBHRID） 将只返回JOHN
最后注意如果数据访问是通过有效私有数据库来管理的建立设置并不能自动限制数据访问
