Friday, August 31, 2012

哦! Oracle Proxy User

這一篇解釋 Oracle Proxy User相當經典。http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:21575905259251

目前大部分網路應用系統開發(Web Application)在連接資料庫時,會建立一位資料庫連線使用者(讓我們假設此使用者的資料庫username為"MIDTIER"),然後所用經過網路應用系統認証(authenticate)的網路用戶,就會以MIDTIER連進資料庫,進行資料存取。

為了讓使用者MIDTIER能順利存取所需要的資料,一般會採取以下幾種的授權(authorize)方式:
1. 所有要被存取的資料全部建立於MIDTIER的使用者名下
2. 資料的擁有者為其他資料庫使用者,由其他使用者授權給MIDTIER使用

就安全與實務上來說,方法2為比較適合的方式;也是建議的方法。其優點除安全之外,在實務上也比較方管理,應用程式也比較容易移植在其他環境。

有個問題,在這樣的方式下,MIDTIER要給夠足夠的授權,才能夠滿足前端網路應用系統使用者的需求。讓我們假設:我們有2個不同授權的網路使用者-MANAGER與CLERK。

MANAGER與CLERK一經被網路應用程式認證,就能透過MIDTIER存取資料,因此MIDTIER的授權是要同時為MANAGER與CLERK授權的聯集。這會導致MIDTIER被過份授權。如果要想達到適當的授權,Oracle Proxy User為一種解決方案。(這裏有一種隱含的假設--MANAGER與CLERK的認證是由網路應用系統所認證而且資料庫"相信"網路應用系統的認證)

以下為展示Oracle Proxy User的做法:我們會在Oracle資料庫下建立幾個不同的USER:

MIDTIER為網路應用系統與資料庫之間連線的使用者或有人用為中間件軟體(middleware)建立Connection Pool的使用者:在這裏我們只會給予最少的權限"CREATE SESSION"(只能夠建立資料庫連線)。
MANAGER與CLERK為模擬經過網路應用系統認證過的使用者(因為經過網路應用系統認證所以資料庫不再認證)。
SCOTT為我們熟悉的USER,是真正表格的擁有者,為簡化展示會分別給予CLERK SELECT的授權於表格DEPT, EMP而MANAGER SELECT授權於表格DEPT, EMP, BONUS, SALGRADE。

SQL> connect system/oracle@orcl
Connected.
SQL> create user MIDTIER identified by MIDTIER;

User created.

SQL> create user MANAGER identified by whateveryouwanatoset;

User created.

SQL> create user CLERK identified by whateveryouwanatoset;

User created.

SQL> grant CREATE SESSION to MIDTIER;

Grant succeeded.

SQL> grant CREATE SESSION to MANAGER;

Grant succeeded.

SQL> grant CREATE SESSION to CLERK;

Grant succeeded.

SQL> grant SELECT on SCOTT.DEPT to CLERK;

Grant succeeded.

SQL> grant SELECT on SCOTT.DEPT to MANAGER;

Grant succeeded.

SQL> grant SELECT on SCOTT.EMP to CLERK;

Grant succeeded.

SQL> grant SELECT on SCOTT.EMP to MANAGER;

Grant succeeded.

SQL> grant SELECT on SCOTT.BONUS to MANAGEAR;
grant SELECT on SCOTT.BONUS to MANAGEAR
                               *
ERROR at line 1:
ORA-01917: user or role 'MANAGEAR' does not exist


SQL> grant SELECT on SCOTT.BONUS to MANAGER;

Grant succeeded.

SQL> grant SELECT on SCOTT.SALGRADE to MANAGER;

Grant succeeded.

SQL>

接下來設定MANAGER與CLERK可以透過MIDTIER登入Oracle 資料庫--MIDTIER可以代表MANAGER與CLERK登入資料庫。

SQL> alter user CLERK grant connect through MIDTIER;

User altered.

SQL> alter user MANAGER grant connect through MIDTIER;

User altered.

SQL>

上述的指令是說:MANAGER與CLERK可以透過MIDTIER所使用的資料連線連接資料庫:一旦前面的應用系統認證MANAGER或CLERK為其本人之後,Oracle資料庫就承認前端應用系統的認證並允許MIDTIER可以代表經過認證的MANAGER或CLERK,執行原本為MANAGER或CLERK所被授權的權利。


現在先使用MIDTIER連進Oracle 資料庫,並查看是否具備讀取SCOTT的資料表格。

SQL> connect MIDTIER/MIDTIER@ORCL
Connected.
SQL> select table_name from all_tables where owner='SCOTT';

no rows selected

接著使用PROXY USER連接的語法登入資料庫
SQL> connect MIDTIER[CLERK]/MIDTIER@ORCL
Connected.
SQL> select table_name from all_tables where owner='SCOTT';

TABLE_NAME
------------------------------
DEPT
EMP

SQL> select user from dual;

USER
------------------------------
CLERK

SQL> connect MIDTIER[MANAGER]/MIDTIER@ORCL
Connected.
SQL> select table_name from all_tables where owner='SCOTT';

TABLE_NAME
------------------------------
DEPT
EMP
BONUS
SALGRADE

SQL> select user from dual;

USER
------------------------------
MANAGER


首先先解釋"connect MIDTIER[CLERK]/MIDTIER@ORCL" -- CLERK已經先被我驗證過了,CLERK就是CLERK沒有問題, 我就是CLERK(我代表CLERK來登入資料庫),但是我是用MIDTIER的使用者與其密碼來登入資料庫;因為之前我們都已經同意,資料庫相信我對前端使用者的認証。因此當登入成功之後,我就是(代表)CLERK,我只被授權看到SCOTT的2個表格。


當使用"connect MIDTIER[MANAGER]/MIDTIER@ORCL",當登入成功之後,我就是(代表)MANAGER,我就被授權看到SCOTT的4個表格。

以上過程中(先排除討論MANAGER與CLERK如何被認証),都是使用MIDTIER的使用者名稱與密碼,MANAGER與CLERK的密碼完全不必知道也不用被送出;而且資料庫知道真正的前端使用者是誰(SELECT USER FROM DUAL),現在就容易做資料稽核了。

PROXY USER的機制被廣泛地運用在Web Application,利用MIDTIER建立connection pool,且MIDTIER除了資料庫連線能力之外,沒有其它的能力,保障了connection pool 資料庫連線的安全性與便利性。經過Web Application認証之後才以前端真正使用者的身份(如為MANAGER或CLEARK) 進行資料庫的操作;請注意我們並沒有重新進行資料庫連接,而是在取得資料庫connection pool的資源後,設定其真正的使用者,進行對資料庫的操作。

如此,我們可以保有使用connection pool的快速與方便而且同時具備了安全性;從資料庫的角度,也能稽核到真正進入資料庫的使用者。

Oracle JDBC connection pool Proxy User 使用程式範例,詳情可參考Proxy Authentication 於 Oracle® Database JDBC Developer's Guide

接下來面臨的問題:
如果面對的是大量的網際網路使用者,難到真的要將所有使用者都建立在資料庫上嗎?還是有其它的解決方案 -- 解決方案之一:Oracle Enterprise User Security