You can create an application session using the DBMS_XS_SESSIONS.CREATE_SESSION procedure in PL/SQL or using the createSession method of the XSSessionManager class in Java. To create an application session, the invoking user needs CREATE_SESSION application privilege. This privilege can be obtained through XS_SESSION_ADMIN Database role or by XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE API call (see "GRANT_SYSTEM_PRIVILEGE Procedure" for more information). CREATE_SESSION procedure populates the unique identifier of the newly created session in sessionid out parameter. This unique identifier can be used to refer to the session in future calls. The DBA_XS_SESSIONS data dictionary view displays all the application sessions in the database.

You can also specify a list of namespaces to be created when the session is created. If you specify namespaces during creation of the session, the caller must have application privileges MODIFY_NAMESPACE or MODIFY_ATTRIBUTE on the namespaces, or the ADMIN_NAMESPACE system privilege.

Example 3-1 shows how to create an application session with lwuser1.

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
END;

You can also create an anonymous application session using the DBMS_XS_SESSIONS.CREATE_SESSION procedure in PL/SQL or using the createAnonymousSession method of the XSSessionManager class in Java. To create an anonymous session through the PL/SQL API, you must specify the predefined user name XSGUEST.

Example 3-2 shows how to create an anonymous session with the predefined user XSGUEST.

After creating an anonymous application session, you can assign a named user to the session.

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('XSGUEST', sessionid);
END;

To use an application session, it must be associated with a database session. This operation is called attach. You can attach an application session to a traditional database session using the DBMS_XS_SESSIONS.ATTACH_SESSION procedure in PL/SQL or the attachSession method of the XSSessionManager class in Java. A database session can only attach one application session at a time. The DBA_XS_ACTIVE_SESSIONS dynamic data dictionary view displays all attached application sessions in the database.

To execute this procedure, the traditional session user must have the ATTACH_SESSION application privilege. This privilege can be obtained through the XS_SESSION_ADMIN Database role or by the XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE API call. If you specify namespaces, then the user is required to have the application privileges MODIFY_NAMESPACE or MODIFY_ATTRIBUTE on the namespaces, or ADMIN_NAMESPACE system privilege.

Example 3-3 shows how to attach an application session to a database session.

Beginning with Oracle Database 12c Release 2 (12.2), Oracle Label Security supports Real Application Security users. This means that Oracle Label Security context is established in the Real Application Security session during the attach operation, so that Oracle Label Security authorization can be exercised in the Real Application Security user session. Oracle Label Security provides the ability to define data labels, assign user labels and protect sensitive application data within the Oracle database.

For example, using Oracle Label Security data labels allows each row of a table to be labeled based on its level of confidentiality. Data labels consist of 3 components: levels, compartments, and groups. So a given data label should have one level, zero or more compartments and zero or more groups associated with it. Compartments allow defining finer granularity within a level – all data belonging to a particular project can be labeled with the same compartment. Groups are hierarchical and a group can thus be associated with a parent group.

In addition, using Oracle Label Security user labels, each user can be assigned labels that constrain access to labeled data. Each user is assigned a range of levels, compartments, and groups, and each session can operate within that authorized range to access labeled data within that range.

Furthermore, using privileges, Oracle Label Security privileges are policy specific and used to provide users specific rights to perform special operations or to access data beyond their label authorizations. The list of all policy specific privileges is: FULL, READ, COMPACCESS, PROFILE_ACCESS, WRITEUP, WRITEDOWN, and WRITEACROSS.

Using Oracle Label Security, trusted stored programs can be used. A trusted stored program unit is a stored procedure, function, or package that has been granted one or more label security privileges. Trusted stored program units are used to let users perform privileged operations in a controlled manner, or update data at several labels. By granting privileges to a program unit, the privileges required for users can be effectively reduced.

Using Oracle Label Security, a policy is applied to a table or an entire schema after defining data labels or user labels or both and assigning appropriate privileges to users. When a policy is applied on a table, label security creates a policy specific NUMBER column on the table to store numeric equivalent of the data labels defined before for the policy. The column can be created as a user visible column or as a hidden column. The user can specify various enforcement options when the policy is applied on the table. The READ_CONTROL enforcement option for example protects the table from queries and WRITE_CONTROL protects it from DML operations.

Establishing Oracle Label Security context in a Real Application Security session therefore lets SELECT and DML operations return results authorized for the Real Application Security user.

To attach a session with dynamic roles, a list of dynamic roles can be passed in the PL/SQL ATTACH_SESSION procedure.

DECLARE
  sessionid raw(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
END;

You can associate a specific cookie with an application session using the DBMS_XS_SESSIONS.SET_SESSION_COOKIE procedure in PL/SQL or the setCookie method of the XSSessionManager class in Java. The cookie can also be associated at the time of creation of the session through the CREATE_SESSION PL/SQL API. A cookie is a token embedded in a user’s session by a web site during an application session. So the next time the same user requests something from that web site, it sends the cookie to the application session, which allows the server to associate the session with that user.

To execute this procedure, the user must be granted the MODIFY_SESSION application privilege. This privilege can be obtained through the XS_SESSION_ADMIN Database role or by the XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE API call.

Example 3-4 shows how to set a cookie for an application session.

DECLARE
  sessionid raw(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.SET_SESSION_COOKIE('Cookie1', sessionid);
END;

You can assign a named application user to a currently attached anonymous application session using the DBMS_XS_SESSIONS.ASSIGN_USER procedure in PL/SQL or the assignUser method of the XSSessionManager class in Java. Assigning a user changes the user session from anonymous to a named user.

To execute this procedure, the dispatcher or connection user must have the ASSIGN_USER application privilege. This privilege can be obtained through the XS_SESSION_ADMIN Database role or by the XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE API call. If you specify namespaces, then the user is required to be granted application privileges MODIFY_NAMESPACE or MODIFY_ATTRIBUTE on the namespaces, or ADMIN_NAMESPACE system privilege. A list of dynamic roles can also be enabled using the DBMS_XS_SESSIONS.ASSIGN_USER procedure.

Beginning with Oracle Database 12c Release 2 (12.2), Oracle Label Security supports Real Application Security users. If the Real Application Security user is authorized in any Oracle Label Security policy then, during an assign_user call, the corresponding label security authorization is established for the named Real Application Security user session. Establishing Oracle Label Security context in a Real Application Security session therefore lets SELECT and DML operations return results authorized for the Real Application Security user.

Example 3-5 shows how to assign the application user lwuser1 to an application session.

DECLARE
  sessionid raw(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('XSGUEST', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.ASSIGN_USER('lwuser1');
END;

You can switch or proxy the security context of the current application session to a newly initialized security context for a specified application user using the DBMS_XS_SESSIONS.SWITCH_USER procedure in PL/SQL or the switchUser method of the Session interface in Java. To proxy another application user, the current application session user must be set up as a proxy user for the target user before performing the switch operation. This is performed through the XS_PRINCIPAL.ADD_PROXY_USER PL/SQL API.

Switching a user changes the user session between two named users.

If the target application user of the proxy operation has a list of filtering roles (proxy roles) set up for the proxy user, they are enabled in the session.

Beginning with Oracle Database 12c Release 2 (12.2), Oracle Label Security supports Real Application Security users. This means that Oracle Label Security context of the target_user will be established on switching from the proxy_user session to the target_user session.

You can either retain or clear the application namespace and attributes after a switch operation. When the keep_state parameter is set to TRUE, all application namespaces and attributes are retained; otherwise, all previous state in the session is cleared.

If you specify namespaces, then the user is required to be granted application privileges MODIFY_NAMESPACE or MODIFY_ATTRIBUTE on the namespaces, or the ADMIN_NAMESPACE system privilege.

Example 3-6 shows how to switch the application user lwuser1 to application user lwuser2 in the current application session. Note that namespace templates ns1 and ns2 should have already have been created by SYSDBA.

DECLARE
  sessionid RAW(16);
  nsList DBMS_XS_NSATTRLIST;
BEGIN 
  nsList := DBMS_XS_NSATTRLIST(DBMS_XS_NSATTR('ns1'),DBMS_XS_NSATTR('ns2'));
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.SWITCH_USER(username => 'lwuser2',
                               keep_state => TRUE,
                               namespaces => nsList);
END;

A global callback event handler is a predefined PL/SQL procedure that can be invoked to inspect, log, and modify the session state when certain session events of interest occur. You can add multiple global callback event handlers on a session event. After you create the PL/SQL procedure, you can register or deregister, or enable or disable it using these procedures, respectively:

• DBMS_XS_SESSIONS.ADD_GLOBAL_CALLBACK

  Use this procedure to register a callback event handler.

• DBMS_XS_SESSIONS.DELETE_GLOBAL_CALLBACK

  Use this procedure to deregister a global callback.

• DBMS_XS_SESSIONS.ENABLE_GLOBAL_CALLBACK

  Use this procedure to enable or disable a global callback procedure by specifying a value of TRUE for enable or FALSE for disable.

To execute these APIs the user must have the CALLBACK application privilege. This can be obtained through the XSPROVISIONER application role or by calling the XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE API. You can configure one or more global callback event handlers for use in an application session. If you configure multiple callback event handlers, Oracle Database executes the handlers in the order in which they were created.

Optionally, you can follow these steps to change the execution order:

BEGIN
  SYS.DBMS_XS_SESSIONS.ADD_GLOBAL_CALLBACK 
   (DBMS_XS_SESSIONS.CREATE_SESSION_EVENT, 
   'CALLBACK_SCHM','CALLBACK_PKG','CALLBACK_PROC');
END;
/

You can save the current user application session using the DBMS_XS_SESSIONS.SAVE_SESSION procedure in PL/SQL or the saveSession method of the XSSessionManager class in Java. Use the save operation when session changes need to be propagated immediately to other sessions using the same session as this one. If the save operation is not used, then the session changes would be reflected in other sessions only after this session is detached.

The calling user requires no privileges to perform this operation.

Example 3-8 shows how to save the current user application session.

BEGIN
 SYS.DBMS_XS_SESSIONS.SAVE_SESSION;
END;

You can detach an application session from the traditional database session using either of these procedures:

• DBMS_XS_SESSIONS.DETACH_SESSION(abort => FALSE)

  Use this procedure to detach the session and commit any changes that were made since the last time session changes were saved. When you specify the abort parameter as FALSE (the default value), all changes performed in the current session are persisted. The currently attached user can perform this operation without any additional privileges.

  DETACH_SESSION is always performed on the currently attached session.

• DBMS_XS_SESSIONS.DETACH_SESSION(abort => TRUE)

  Use this procedure to detach the session without saving the changes. When you specify the abort parameter as TRUE, it rolls back the changes performed in the current session. The role and namespace changes made to the session since the attach are discarded.

Example 3-9 shows how to detach an application session from a database session and commit the changes. Note that you can call DETACH_SESSION anywhere to detach the currently attached session.

You can use the detachSession method of the XSSessionManager class in Java.

Example 3-10 shows how to detach a database session from an application session without saving any changes.

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
...
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
...
END;

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
...
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION(TRUE);
END;

You can terminate an application session using the DBMS_XS_SESSIONS.DESTROY_SESSION procedure in PL/SQL or using the destroySession method of the XSSessionManager class in Java. This procedure also detaches all traditional sessions from the application session.

To execute this procedure, the invoking user must have the TERMINATE_SESSION application privilege. This privilege can be obtained through the XS_SESSION_ADMIN Database role or by the XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE API call.

Example 3-11 shows how to destroy an application session.

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;

A namespace can be initialized, using a namespace template, during any of the following events, as described in this section:

You can set the value of a specific session attribute using the DBMS_XS_SESSIONS.SET_ATTRIBUTE procedure in PL/SQL or the setAttribute method of the SessionNamespace interface method in Java.

The calling user is required to be granted the MODIFY_ATTRIBUTE application privilege on the namespace or the ADMIN_NAMESPACE system privilege.

Example 3-18 shows how to set a value, val1, for an attribute, attr1, of the application session.

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.SET_ATTRIBUTE('ns1', 'attr1', 'val1');
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

You can retrieve the value of a specific session attribute using the DBMS_XS_SESSIONS.GET_ATTRIBUTE procedure in PL/SQL or using the getAttribute method of the SessionNamespace interface method in Java.

The calling user is not required to be granted any privileges to get attributes using the DBMS_XS_SESSIONS.GET_ATTRIBUTE procedure.

Example 3-19 shows how to retrieve an attribute, attr1, of the application session.

DECLARE
  sessionid RAW(16);
  attrib_out_val VARCHAR2(4000);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.SET_ATTRIBUTE('ns1', 'attr1', 'val1');
  SYS.DBMS_XS_SESSIONS.GET_ATTRIBUTE('ns1', 'attr1', attrib_out_val);
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

You can create custom attributes in a namespace using the DBMS_XS_SESSIONS.CREATE_ATTRIBUTE procedure in PL/SQL or the createAttribute method of the SessionNamespace interface method in Java.

Custom attributes differ from template attributes. Template attributes are part of the namespace template, and are automatically created in the session when the namespace is created. Custom attributes are programmatically created in a namespace, using the CREATE_ATTRIBUTE procedure.

The calling application is required to be granted the MODIFY_ATTRIBUTE application privilege on the namespace or the ADMIN_NAMESPACE system privilege.

Example 3-20 shows how to create a custom attribute, customattr, in a namespace of the application session.

DECLARE
  sessionid RAW(16);
  attrib_out_val VARCHAR2(4000);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.CREATE_ATTRIBUTE('ns1','customattr','default_value_custom',NULL);
  SYS.DBMS_XS_SESSIONS.SET_ATTRIBUTE('ns1','customattr','newvalue');
  SYS.DBMS_XS_SESSIONS.GET_ATTRIBUTE('ns1', 'customattr', attrib_out_val);
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

You can delete a namespace and all attributes identified by it from an application session using the DBMS_XS_SESSIONS.DELETE_NAMESPACE procedure in PL/SQL or the deleteAttribute method of the SessionNamespace interface method in Java.

The calling user must have the MODIFY_NAMESPACE application privilege on the namespace or the ADMIN_NAMESPACE system privilege.

Example 3-21 shows how to delete a namespace ns1 from an application session.

DECLARE
  sessionid RAW(16);
  out_value VARCHAR2(4000);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.SET_ATTRIBUTE('ns1', 'attr1', 'val1');
  SYS.DBMS_XS_SESSIONS.GET_ATTRIBUTE('ns1', 'attr1', out_value);
  SYS.DBMS_XS_SESSIONS.DELETE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

You can enable only directly granted regular application roles of an application session user using the DBMS_XS_SESSIONS.ENABLE_ROLE procedure in PL/SQL or the enableRole method of the Session interface in Java.

The DBA_XS_SESSION_ROLES dynamic data dictionary view lists application roles enabled in all application sessions. The V$XS_SESSION_ROLES dynamic data dictionary view lists application roles enabled in the currently attached application session.

Example 3-22 shows how to enable a role in an application session.

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.ENABLE_ROLE('auth1_role');
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

You can disable application roles for a specific session using the DBMS_XS_SESSIONS.DISABLE_ROLE procedure in PL/SQL or the disableRole method of the Session interface in Java.

Example 3-23 shows how to disable a role in an application session.

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.ENABLE_ROLE('auth1_role');
  SYS.DBMS_XS_SESSIONS.DISABLE_ROLE('auth1_role');
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/