这篇文章主要讲解应用程序客户端访问数据库的新特性。有些地方理解不好
写得也不是很好，请大家帮忙指正，谢谢！
9I安全认证拥有
..解决了阻止未经认证的用户通过其他客户端访问数据的问题.
..在隐藏密码的实现方面有了比以前更好的机制.
..角色的有效性是通过一个包来检测而不是一个口令
……应用设置的概念在8i中已经作了介绍，8i中细粒度访问控制能够达到制作有效的私有数据库，而在9i中应用设置已经可以用一个角色来实现，因此提高了私有数据库的可用性。
为了确认一个角色是否有效，必须调用关联的存储过程，这个存储过程可以通过使用sys_context（'userenv'，nnn）来制定一系列的额外检查。nnn可以是ip_address，proxy_account等。（举例，我们可以在存储过程和触发器里调用select sys_context（'userenv'，ip_address） from dual得到客户端的ip，然后根据这个资料进行判定。sys_context的具体用法如下：
select
SYS_CONTEXT('USERENV','TERMINAL') terminal,
SYS_CONTEXT('USERENV','LANGUAGE') language,
SYS_CONTEXT('USERENV','SESSIONID') sessionid,
SYS_CONTEXT('USERENV','INSTANCE') instance,
SYS_CONTEXT('USERENV','ENTRYID') entryid,
SYS_CONTEXT('USERENV','ISDBA') isdba,
SYS_CONTEXT('USERENV','NLS_TERRITORY') nls_territory,
SYS_CONTEXT('USERENV','NLS_CURRENCY') nls_currency,
SYS_CONTEXT('USERENV','NLS_CALENDAR') nls_calendar,
SYS_CONTEXT('USERENV','NLS_DATE_FORMAT') nls_date_format,
SYS_CONTEXT('USERENV','NLS_DATE_LANGUAGE') nls_date_language,
SYS_CONTEXT('USERENV','NLS_SORT') nls_sort,
SYS_CONTEXT('USERENV','CURRENT_USER') current_user,
SYS_CONTEXT('USERENV','CURRENT_USERID') current_userid,
SYS_CONTEXT('USERENV','SESSION_USER') session_user,
SYS_CONTEXT('USERENV','SESSION_USERID') session_userid,
SYS_CONTEXT('USERENV','PROXY_USER') proxy_user,
SYS_CONTEXT('USERENV','PROXY_USERID') proxy_userid,
SYS_CONTEXT('USERENV','DB_DOMAIN') db_domain,
SYS_CONTEXT('USERENV','DB_NAME') db_name,
SYS_CONTEXT('USERENV','HOST') host,
SYS_CONTEXT('USERENV','OS_USER') os_user,
SYS_CONTEXT('USERENV','EXTERNAL_NAME') external_name,
SYS_CONTEXT('USERENV','IP_ADDRESS') ip_address,
SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') network_protocol,
SYS_CONTEXT('USERENV','BG_JOB_ID') bg_job_id,
SYS_CONTEXT('USERENV','FG_JOB_ID') fg_job_id,
SYS_CONTEXT('USERENV','AUTHENTICATION_TYPE') authentication_type,
SYS_CONTEXT('USERENV','AUTHENTICATION_DATA') authentication_data
from dual
9i以前的版本,认证角色是通过passWord的方法,将用户名,口令写入应用程序来进行连接.
这样的缺点是,假如口令在客户端被解析出来,任何应用程序都能够访问你的数据.
下面我们看一个9i认证角色的例子.
CREATE ROLE salesuser
IDENTIFIED USING sh.sales_chk;
CREATE OR REPLACE PROCEDURE sales_chk
AUTHID CURRENT_USER IS
ipchk STRING(30);
BEGIN /* Only certain IP addresses allowed */
SELECT SYS_CONTEXT(’USERENV’,’IP_ADDRESS’)
INTO ipchk FROM DUAL;
IF SUBSTR(ipchk,1,4) != ’192.’
THEN RETURN; END IF; /* Fail silently */
DBMS_SESSION.SET_ROLE(’SALESUSER’); /* Enable */
END;
/
这个过程做到,假如不在192网段,这个角色失效.
全局应用设置
一个设置现在能够被全局化和共享.
全局化应用设置就是:
..比每个进程一个设置更节省资源.
..利用有效私有数据库能够更好的适应基于web的应用.
..仍然可以通过identifier验证访问权限.
..更适应多路连接.
Oracle9i的有效私有数据库特性提供了连接池以答应多重会话使用一个或多个全局应用设置，而不需要为每个用户建立一个应用设置。
全局应用设置为基于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 hr.init AccessED GLOBALLY;
应用服务器启动将为HR用户建立多重连接。
当用户JOHN连接到应用服务器后，JOHN不是一个数据库用户。应用服务器将在应用里鉴别JOHN，并且为这个连接0设置一个临时的会话ID，4523，基于唯一应用会话属性，这个会话ID作为COOKIE或者应用服务器的维护的一部分返回用户JOHN的浏览器。
应用服务器为这个客户端初始应用设置称为HR.INIT包，它执行
DBMS_SESSION.SET_CONTEXT(’webhr’,’id’, ’JOHN’, ’HR’,4523);
DBMS_SESSION.SET_CONTEXT(’webhr’,’dep’,’sales’,’HR’,4523);
例子：
CREATE CONTEXT webhr USING hr.init ACCESSED GLOBALLY;
DBMS_SESSION.SET_CONTEXT(’webhr’,’id’,’JOHN’,’HR’,4523);
DBMS_SESSION.SET_IDENTIFIER(4523);
…
SYS_CONTEXT calls are in John’s context
…
DBMS_SESSION.CLEAR_IDENTIFIER(4523);
当用户JOHN用应用服务器访问数据，应用服务器找到所有登陆的会话，并执行DBMS_SESSION.SET_IDENTIFIER（4523）；所有的这个会话的SYS_CONTEXT将只返回属于这个客户端的应用程序设置，例如SYS_CONTEXT（'WEBHR'，'ID'） 将只返回'JOHN'.
最后注重：假如数据访问是通过有效私有数据库来治理的，建立设置并不能自动限制数据访问。
