Make moral judgements
Chapter 5: Seminars and Case Studies
5.4 Communicative reason and social learning
Pol´ıtica: ACCESS DCS POLICY
Tabla a proteger: ADMDCSN Due~no tabla a proteger: STUDENTSCH Atributo de Clasificaci´on: CAMPUS
Operaciones en las que aplica: INSERT, UPDATE, DELETE Tabla de clasificaci´on: ACCESSUSR
Tabla 5.4: Template de Especificaci´on de la Pol´ıtica de ACCESS DCS POLICY
5.4.5.
Funci´on de Acceso.
Para la creaci´on de las funciones de acceso y de la implementaci´on de la pol´ıtica, se usar´a la consola de generaci´on de c´odigo vista en el cap´ıtulo 4 secci´on 4.6. El usuario que ser´a encargado de generar el c´odigo y compilar, ser´a SYSTEM. Entonces para generar el c´odigo y la pol´ıtica ACCESS ADM POLICY se proporcionan los siguientes valores en la consola incluidos en estos el template de la tabla 5.3:
Tabla: ADMAPPL Owner: STUDENTSCH Atributo: CAMPUS
Tabla Clasificaci´on: ACCESSUSR
Nombre Pol´ıtica: ACCESS ADM POLICY Cta. Administradora 1: ADMINISTRATOR Nombre Paquete: ADMISSION ACCESS PKG Funci´on de Acceso: UPDATE DELETE ADM DML: Update, Delete
El c´odigo generado es el mostrado en la siguiente figura 5.8:
1 CREATE OR REPLACE PACKAGE ADMISSION_ACCESS_PKG IS
2 FUNCTION UPDATE_DELETE_ADM(SCHEMA IN VARCHAR2, OBJECT IN VARCHAR2) RETURN VARCHAR2; 3 END ADMISSION_ACCESS_PKG;
4 /
6 FUNCTION UPDATE_DELETE_ADM(SCHEMA IN VARCHAR2, OBJECT IN VARCHAR2) RETURN VARCHAR2 IS 7 PREDICATE VARCHAR2(2000);
8 BEGIN
9 IF SCHEMA = SYS_CONTEXT(’USERENV’,’SESSION_USER’)
10 OR SYS_CONTEXT(’USERENV’,’SESSION_USER’) = ’ADMINISTRATOR’ THEN 11 PREDICATE := ’1 = 1’;
12 ELSE
13 IF OBJECT = ’ADMAPPL’ THEN
14 PREDICATE := OBJECT||’_CAMPUS IN (SELECT ACCESSUSR_CAMPUS 15 FROM ACCESSUSR
16 WHERE ACCESSUSR_USERID= SYS_CONTEXT(’’USERENV’’,’’SESSION_USER’’)))’; 17 END IF; 18 END IF; 19 RETURN PREDICATE; 20 END; 21 END ADMISSION_ACCESS_PKG; / EXEC DBMS_RLS.ADD_POLICY(’STUDENTSCH’,’ADMAPPL’,’ACCESS_ADM_POLICY’,’SYSTEM’, ’ADMISSION_ACCESS_PKG.UPDATE_DELETE_ADM’,’UPDATE,DELETE’,TRUE);
Figura 5.8: Paquete ADMISSION ACCESS PKG. La explicaci´on del c´odigo de la figura 5.8 es la siguiente:
En la figura 5.8, entre las l´ıneas 1 y 3 se puede notar la creaci´on del encabezado del paquete. Como se puede ver el paquete contiene la declaraci´on de la funci´on de acceso UPDATE DELETE ADM.
Como se puede observar, la funci´on de acceso est´a recibiendo los par´ametros que se describieron en el cap´ıtulo 4; estos par´ametros son SCHEMA y OBJECT. En la l´ınea 7 de la figura 5.8 se declara la variable PREDICATE que retornar´a el predicado extra.
A continuaci´on en la figura 5.8, l´ınea 9 y 10 se valida si el usuario que est´a accesan- do a la tabla protegida, es un usuario administrador (cuenta ADMINISTRATOR) o el due˜no del esquema al que pertenece la tabla (SCHEMA).
• Recuerde que la sentenciaSYS CONTEXT(’USERENV’,’SESSION USER’)se puede saber qu´e usuario conectado, est´a tratando de accesar a la tabla protegida. Para simplificar el proceso, de ahora en adelante, esta sentencia ser´a susti- tuida por el USERIDdel usuario empleado en cada secci´on del resultados de la implementaci´on del control de acceso.
En la l´ınea 11 (figura 5.8) se est´a dando el valor a la variablePREDICATE de 1 = 1. Esto significa, que si el usuario que est´a intentando accesar a la tabla protegida es el usuario ADMINISTRATOR o el due˜no del esquema al que pertenece esta tabla (par´ametroSCHEMA), el predicado extra contendr´a una condici´on v´alida y har´a que el query original se ejecute sin ning´un problema, pr´acticamente sin modificaci´on. Esto se decidi´o implementar as´ı por razones de operabilidad, ya que por lo menos el due˜no del esquema de la tabla debe tener acceso a ella sin restricci´on.
Si el usuario no es el due˜no del esquema ni ADMINISTRATOR, entonces se dispone a construir el predicado extra. En la l´ınea 13 (figura 5.8) se est´a vali- dando si la tabla protegida que se est´a intentando accesar es ADMAPPL, si es as´ı entonces se procede a lo siguiente:
• En la l´ınea 14 (figura 5.8), se puede verificar que el predicado se est´a con- struyendo usando la misma forma que en los ejemplos del cap´ıtulo 4, es decir con la instrucci´on OBJECT || ’ CAMPUS IN ’ || que arrojar´a el resul- tado ADMAPPL CAMPUS IN (que es el campo de la tabla de admisiones ADMAPPL que se refiere al atributo de clasificaci´on CAMPUS) el cu´al es- pera obtener los valores del subquery comprendido entre las l´ıneas 14 y 16 (figura 5.8)
• En resumen el subquery mencionado con anterioridad est´a buscando en la tabla de clasificaci´on ACCESSUSR, a qu´e campus pertenece el usuario que est´a intentando accesar a la tabla ADMAPPL.
Antes de finalizar, el predicado extra construido, es retornado de la funci´on en la l´ınea 19 (figura 5.8).
Ahora, para generar c´odigo e implementar de la pol´ıtica ACCESS DCS POLICY se proporcionan los siguientes par´ametros en la consola de generaci´on incluido el tem- plate de la tabla 5.4:
Tabla: ADMDCSN Owner: STUDENTSCH Atributo: CAMPUS
Tabla Clasificaci´on: ACCESSUSR
Nombre Pol´ıtica: ACCESS DCS POLICY Cta. Administradora 1: ADMINISTRATOR Nombre Paquete: DECISION ACCESS PKG
Funci´on de Acceso: ACCESS DCS DML: Insert, Update, Delete
El c´odigo generado es el mostrado en la siguiente figura 5.9:
1 CREATE OR REPLACE PACKAGE DECISION_ACCESS_PKG IS
2 FUNCTION ACCESS_DCS(SCHEMA IN VARCHAR2, OBJECT IN VARCHAR2) RETURN VARCHAR2; 3 END DECISION_ACCESS_PKG;
4 /
5 CREATE OR REPLACE PACKAGE BODY DECISION_ACCESS_PKG IS
6 FUNCTION ACCESS_DCS(SCHEMA IN VARCHAR2, OBJECT IN VARCHAR2) RETURN VARCHAR2 IS 7 PREDICATE VARCHAR2(2000);
8 BEGIN
9 IF SCHEMA = SYS_CONTEXT(’USERENV’,’SESSION_USER’)
10 OR SYS_CONTEXT(’USERENV’,’SESSION_USER’) = ’ADMINISTRATOR’ THEN 11 PREDICATE := ’1 = 1’;
12 ELSE
13 IF OBJECT = ’ADMDCSN’ THEN 14 PREDICATE := ’EXISTS(
15 SELECT 1
16 FROM ADMAPPL
17 WHERE ADMAPPL_ID = ADMDCSN_ID
18 AND ADMAPPL_PERIOD = ADMDCSN_PERIOD 19 AND ADMAPPL_CAMPUS IN 20 ( 21 SELECT ACCESSUSR_CAMPUS 22 FROM ACCESSUSR 23 WHERE ACCESSUSR_USERID = SYS_CONTEXT(’’USERENV’’,’’SESSION_USER’’)))’; 24 END IF; 25 END IF; 26 RETURN PREDICATE; 27 END; 28 END DECISION_ACCESS_PKG; / EXEC DBMS_RLS.ADD_POLICY(’STUDENTSCH’,’ADMDCSN’,’ACCESS_DCS_POLICY’,’SYSTEM’, ’DECISION_ACCESS_PKG.ACCESS_DCS’,’INSERT,UPDATE,DELETE’,TRUE);
En la figura 5.9, entre las l´ıneas 1 y 3 se puede notar la creaci´on del encabezado del paquete. Como se puede ver el paquete contiene la declaraci´on de la funci´on de acceso ACCESS DCS.
Como se puede observar, la funci´on de acceso est´a recibiendo los par´ametros que se describieron en el cap´ıtulo 4; estos par´ametros son SCHEMA y OBJECT. En la l´ınea 7 de la figura 5.9 se declara la variable PREDICATE que retornar´a el predicado extra.
A continuaci´on en la figura 5.9, l´ınea 9 y 10 se valida si el usuario que est´a accesan- do a la tabla protegida, es un usuario administrador (cuenta ADMINISTRATOR) o el due˜no del esquema al que pertenece la tabla (SCHEMA).
• Recuerde que la sentenciaSYS CONTEXT(’USERENV’,’SESSION USER’)se puede saber qu´e usuario conectado, est´a tratando de accesar a la tabla protegida. Para simplificar el proceso, de ahora en adelante, esta sentencia ser´a susti- tuida por el USERIDdel usuario empleado en cada secci´on del resultados de la implementaci´on del control de acceso.
En la l´ınea 11 (figura 5.9) se est´a dando el valor a la variablePREDICATE de 1 = 1. Esto significa, que si el usuario que est´a intentando accesar a la tabla protegida es el usuario ADMINISTRATOR o el due˜no del esquema al que pertenece esta tabla (par´ametroSCHEMA), el predicado extra contendr´a una condici´on v´alida y har´a que el query original se ejecute sin ning´un problema, pr´acticamente sin modificaci´on. Esto se decidi´o implementar as´ı por razones de operabilidad, ya que por lo menos el due˜no del esquema de la tabla debe tener acceso a ella sin restricci´on.
Si el usuario no es el due˜no del esquema ni ADMINISTRATOR, entonces se dispone a construir el predicado extra. En la l´ınea 13 (figura 5.9) se est´a vali- dando si la tabla protegida que se est´a intentando accesar es ADMAPPL, si es as´ı entonces se procede a lo siguiente:
• En la l´ınea 14 (figura 5.9), se puede ver c´omo el predicado est´a siendo con- struido a partir de la tabla padre ADMAPPL, ya que la tabla ADMDCSN no tiene en su estructura el atributo de clasificaci´on CAMPUS. Lo primero que se hace es obtener el atributo de clasificaci´on del usuario en el subquery de las l´ıneas 21 a 23.
• Ya que se tiene es atributo del usuario, entonces se busca (usando las llaves for´aneas) que para el registro de la tabla ADMDCSN que se est´a accesando, exista un registro en la tabla padre ADMAPPL que corresponda al mismo atributo del usuario (l´ıneas 15 a 19 figura 5.9).
Antes de finalizar, el predicado extra construido, es retornado de la funci´on en la l´ınea 26 (figura 5.9).