The SEM_RDFSA package contains subprograms (functions and procedures) for providing fine-grained access control to RDF data, using either a virtual private database (VPD) or Oracle Label Security (OLS). To use the subprograms in this chapter, you should understand the conceptual and usage information in Chapter 1, "RDF Semantic Graph Overview" and Chapter 5, "Fine-Grained Access Control for RDF Data".
This chapter provides reference information about the subprograms, listed in alphabetical order.
SEM_RDFSA.ADD_VPD_CONSTRAINT(
policy_name IN VARCHAR2,
constr_name IN VARCHAR2,
match_pattern IN VARCHAR2,
apply_pattern IN VARCHAR2,
constr_group IN VARCHAR2 DEFAULT NULL);
Name of an existing VPD policy.
Unique case-insensitive name for the constraint to be defined in the VPD policy.
Match pattern that determines the target of the constraint.
The constraint's apply pattern that enforces the access restriction.
Case-insensitive name for the group to which the constraint belongs.
This procedure adds a data access constraint to a VPD policy. Only the owner of a VPD policy can add a new constraint to the policy. The newly added constraint comes into effect immediately and it is enforced for queries on all RDF models associated with the VPD policy.
A constraint group may be specified for each policy such that they can be selectively activated and deactivated at runtime based on the application context (as explained in Section C.1.1). A constraint with no constraint group is always active. See Section C.1.3 for details about the match and apply patterns passed to this procedure.
See also the MDSYS.RDFVPD_POLICY_CONSTRAINTS view, which is described in Section C.1.6.
For information about support for VPD, see Appendix C.
The following example adds data access constraint for the RDF Class Contracts to the VPD policy and assigns it a constraint group named user:
begin
sem_rdfsa.add_vpd_constraint(
policy_name => 'contracts_policy',
constr_name => 'andy_constraint_1',
match_pattern =>'{?contract rdf:type
<http://www.myorg.com/classes/Contract>}',
apply_pattern => '{?contract pred:hasMember
"sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }',
constr_group => 'user');
end;
/
The preceding example makes use of secure application context to identify the user issuing the query and binds its value in the apply pattern to ensure that the user has access to a specific contract. The secure application context with the namespace sa$appctx is expected to initialize the value for the attribute app_user_uri to the URI identifying the user logged in.
The following example adds a data access constraint for the RDF property hasContractValue to the same VPD policy and assigns it to a constraint group named vp.
begin
sem_rdfsa.add_vpd_constraint(
policy_name => 'contracts_policy',
constr_name => 'vp_access_to_contr_value',
match_pattern => '{?contract pred:hasContractValue ?cvalue }',
apply_pattern => '{?contract pred:drivenBy ?dept .
?dept pred:hasVP
"sys_context('sa$appctx','app_user_uri'}"^^orardf:instruction }',
constr_group => 'vp');
end;
/
SEM_RDFSA.APPLY_OLS_POLICY(
policy_name IN VARCHAR2,
rdfsa_options IN NUMBER DEFAULT SEM_RDFSA.SECURE_SUBJECT,
table_options IN VARCHAR2 DEFAULT 'ALL_CONTROL',
label_function IN VARCHAR2 DEFAULT NULL,
predicate IN VARCHAR2 DEFAULT NULL);
Name of an existing OLS policy.
Options specifying the mode of fine-grained access control to be enabled for RDF data. The default option for securing RDF data involves assigning sensitivity labels for the resources appearing the triples' subject position. You can override the defaults by using the rdfsa_options parameter and specifying one of the constants defined in Table 15-1 in the Usage Notes.
Policy enforcement options. The default value (ALL_CONTROL) is the only supported value for this procedure.
A string invoking a function to return a label value to use as the default.
An additional predicate to combine with the label-based predicate.
The OLS policy specified with this procedure must be created with CTXT1 as the column name, and it should use default policy options. For information about policy options, see Oracle Label Security Administrator's Guide.
This procedure invokes the sa_policy_admin.apply_table_policy procedure on multiple tables defined in the MDSYS schema. The parameters table_options, label_function, and predicate for the SEM_RDFSA.APPLY_OLS_POLICY procedure have same semantics as the parameters with same names in the sa_policy_admin.apply_table_policy procedure.
For the rdfsa_options parameter, you can specify the package constant for the desired option. Table 15-1 lists these constants and their descriptions.
Table 15-1 SEM_RDFSA Package Constants for rdfsa_options Parameter
| Constant | Description |
|---|---|
|
SEM_RDFSA.SECURE_SUBJECT |
Assigns sensitivity labels for the resources appearing the triples' subject position. |
|
SEM_RDFSA.SECURE_PREDICATE |
Assigns sensitivity labels for the resources appearing the triples' predicate position. |
|
SEM_RDFSA.SECURE_OBJECT |
Assigns sensitivity labels for the resources appearing the triples' object position. |
|
SEM_RDFSA.TRIPLE_LEVEL_ONLY |
Applies triple-level security. Provides good performance, and eliminates the need to assign labels to individual resources. (Requires that Patch 9819833, available from My Oracle Support, be installed.) |
|
SEM_RDFSA.OPT_DEFINE_BEFORE_USE |
Restricts the use of an RDF resource in a triple before the sensitivity label is defined for the resource. If this option is not specified, the user's initial row label is used as the default label for the resource upon first use. |
|
SEM_RDFSA.OPT_RELAX_TRIPLE_LABEL |
Relaxes the dominating relationship that exists between the triple label and the labels associated with all its components. With this option, a triple can be defined if the user has READ access to all the triple components and the triple label may not bear any relationship with the component labels. Without this option, the triple label should at least cover the label for all its components. |
You can specify a function in the label_function parameter to generate custom labels for newly inserted triples. The label function is associated with the MDSYS.RDF_LINK$ table, and the columns in this table may be configured as parameters to the label function as shown in the following example:
fgac_admin.new_triple_label(:new.model_id,
:new.start_node_id,
:new.p_value_id,
:new.canon_end_node_id)'
Because the OLS policy is applied to more than one table with different structures, the only valid column reference in any predicates assigned to the predicate parameter is that of the label column: CTXT1. If OLS is enabled for a semantic data store with existing data, you can specify a predicate of the form 'OR CTXT1 is null' to be able to continue using this data with no access restrictions.
An OLS-enabled semantic data store uses sensitivity labels for all the RDF triples organized in multiple models. User access to such triples, through model views and SEM_MATCH queries, is restricted by the OLS policy. Additionally, independent of a user owning the application table, access to the triple column (of type SDO_RDF_TRIPLE_S) in the table is restricted to users with FULL access privileges with the OLS policy.
The triples are inserted into a specific RDF model using the INSERT privileges on the corresponding application table. A sensitivity label for the new triple is generated using the user's session context (initial row label) or the label function. The triple is validated for any RDF policy violations using labels associated with the triple components. Although the triple information may not be accessed trough the application table, the model view may be queried to access the triples, while enforcing the OLS policy restrictions. If you have the necessary policy privileges (such as writeup, writeacross), you can update the CTXT1 column in the model view to reset the label assigned to the triple. The new label is automatically validated for any RDF policy violations involving the triple components. Update privilege on the CTXT1 column of the model view is granted to the owner of the model, and this user may selectively grant this privilege to other users.
If the RDF models are created in schemas other than the user with FULL access, necessary privileges on the model objects -- specifically, read/write access on the application table, read access to the model view, and write access to the CTXT1 column in the model view -- can be granted to such users for maintenance operations. These operations include bulk loading into the model, resetting any sensitivity labels assigned to the triples, and creating entailments using the model.
To disable the OLS policy, use the SEM_RDFSA.DISABLE_OLS_POLICY procedure.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".
The following example enable secure access to RDF data with secure subject and secure predicate options.
begin
sem_rdfsa.apply_ols_policy(
policy_name => 'defense',
rdfsa_options => sem_rdfsa.SECURE_SUBJECT+
sem_rdfsa.SECURE_PREDICATE);
end;
/
The following example extends the preceding example by specifying a Define Before Use option, which allows a user to define a triple only if the triple components secured (Subject, Predicate or Object) are predefined with an associated sensitivity label. This configuration is effective if the user inserting the triple does not have execute privileges on the SEM_RDFSA package.
begin
sem_rdfsa.apply_ols_policy(
policy_name => 'defense',
rdfsa_options => sem_rdfsa.SECURE_SUBJECT+
sem_rdfsa.SECURE_PREDICATE+
sem_rdfsa.OPT_DEFINE_BEFORE_USE);
end;
/
Name of an existing VPD policy.
Name of the model to which to apply the VPD policy.
This procedure applies a VPD policy to an RDF model. The owner of a VPD policy can apply it to any model in the database instance. The owner must also have EXECUTE privileges on the SYS.DBMS_RLS package.
After a policy is applied to an RDF model, the data stored in the model and the data inferred from this model can be accessed only using SPARQL query patterns within a SEM_MATCH operation. All other forms of data access (such as through model views or using classic graph pattern syntax in a SEM_MATCH query) are not permitted.
A VPD policy may not applied to a model participating in a virtual model. Similarly, a virtual model may not be defined to include any VPD-enabled models
See also the MDSYS.RDFVPD_POLICIES view, which is described in Section C.1.4.
For information about support for VPD, see Appendix C.
SEM_RDFSA.CREATE_VPD_POLICY(
policy_name IN VARCHAR2,
namespace_map IN RDF_ALIASES DEFAULT NULL,
policy_context IN VARCHAR2 DEFAULT NULL);
Name for the VPD policy.
A mapping of namespaces and their prefixes to be used in the VPD constraints.
Name of the context created specifically to manage constraint groups defined in the VPD policy.
You must have EXECUTE privileges on the SYS.DBMS_RLS package.
The namespace map associated with the policy may be used to define namespace prefixes that are subsequently used in the policy's metadata statements added using the SEM_RDFSA.MAINT_VPD_METADATA procedure and the policy's data access constraints defined using the SEM_RDFSA.ADD_VPD_CONSTRAINT procedure.
The name of the application context assigned to the policy_context parameter is used to manage the constraint groups dynamically at runtime. Such context must be created using the CREATE CONTEXT command before associating it with the VPD policy. Each data access constraint defined in the VPD policy may specify the name of a constraint group to which it belongs. At runtime, the name of the constraint group is matched with the name of the policy_context value to selectively activate the group. (For more information, see Section C.1.1).
See also the MDSYS.RDFVPD_POLICIES view, which is described in Section C.1.4.
For information about support for VPD, see Appendix C.
The following example creates a VPD policy with a namespace map and also associates a policy context to manage constraint groups.
create context contracts_appctx using sec_admin.contracts_appctx; begin sem_rdfsa.create_vpd_policy( policy_name => 'contracts_policy', namespace_map => mdsys.rdf_aliases( mdsys.rdf_alias('','http://www.myorg.com/classes/'), mdsys.rdf_alias('pred','http://www.myorg.com/pred/'), mdsys.rdf_alias('emp','http://www.myorg.com/employee/')), policy_context => 'contracts_appctx'); end; /
Name of an existing VPD policy.
Unique case-insensitive name for the constraint to be deleted from the VPD policy.
This procedure deletes a data access constraint from a VPD policy. Only the owner of a VPD policy can delete a constraint from the policy.
See also the MDSYS.RDFVPD_POLICY_CONSTRAINTS view, which is described in Section C.1.6.
For information about support for VPD, see Appendix C.
Disables the OLS policy that has been previously applied to or enabled on the semantic data store.
You can use this procedure to disable temporarily the OLS policy that had been applied to or enabled for the semantic data store. The user disabling the policy should have the necessary privileges to administer OLS policies and should also have access to the OLS policy applied to RDF data.
The sensitivity labels assigned to various RDF resources and triples are preserved and the OLS policy may be re-enabled to enforce them. New resources with specific labels can be added, or labels for existing triples and resources can be updated when the OLS policy is disabled.
To apply an OLS policy, use the SEM_RDFSA.APPLY_OLS_POLICY procedure; to enable an OLS policy that had been disabled, use the SEM_RDFSA.ENABLE_OLS_POLICY procedure.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".
This procedure permanently drops an unused VPD policy along with its metadata and constraints. You must be the owner of a VPD policy or a user with a DBA role to perform this operation.
For information about support for VPD, see Appendix C.
You can use this procedure to enable the OLS policy that had been disabled for the semantic data store. The user enabling the policy should have the necessary privileges to administer OLS policies and should also have access to the OLS policy applied to RDF data.
To disable an OLS policy, use the SEM_RDFSA.DISABLE_OLS_POLICY procedure.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".
SEM_RDFSA.MAINT_VPD_METADATA(
policy_name IN VARCHAR2,
t_subject IN VARCHAR2,
t_predicate IN VARCHAR2,
t_object IN VARCHAR2,
action IN VARCHAR2 DEFAULT 'ADD');
Maintains the VPD metadata by accepting RDF schema statements with their subject, predicate, and object terms.
Name of an existing VPD policy.
Subject of the metadata triple.
Predicate of the metadata triple.
Object of the metadata triple.
Maintenance operation to be performed: ADD (add the specified triple to the metadata) or DELETE (delete the specified triple from the metadata).
This procedure maintains the metadata associated with the VPD policy by accepting RDF Schema statements and performing appropriate actions on its dictionary. Only the owner of the VPD policy or a user with FULL access to the VPD policy can maintain its metadata.
The types metadata statements that you can add using this procedure are determined by the terms assigned to the t_predicate parameter. The accepted values for this parameter are:
http://www.w3.org/2000/01/rdf-schema#domain http://www.w3.org/2000/01/rdf-schema#range http://www.w3.org/2000/01/rdf-schema#subClassOf http://www.w3.org/2000/01/rdf-schema#subPropertyOf http://www.w3.org/2002/07/owl#equivalentProperty
MDSYS.RDFVPD_PREDICATE_MDATA and MDSYS.RDFVPD_RESOURCE_REL views, which are described in Section C.1.7 and Section C.1.8, respectively.
For information about support for VPD, see Appendix C.
The following example specifies Contract as a subclass of Project and adds domain information for the hasContractValue property:
begin
sem_rdfsa.maint_vpd_metadata(
policy_name => 'contracts_policy',
t_subject => '<http://www.myorg.com/classes/Project>',
t_predicate => '<http://www.w3.org/2000/01/rdf-schema#subClassOf>',
t_object => '<http://www.myorg.com/classes/Contract>',
action => 'add');
end;
begin
sem_rdfsa.maint_vpd_metadata(
policy_name => 'contracts_policy',
t_subject => '<http://www.myorg.com/property/hasConfValue>',
t_predicate => 'rdfs:domain',
t_object => '<http://www.myorg.com/classes/Contract>');
end;
You should have the necessary privileges to administer OLS policies, and you should also have access to the OLS policy applied to RDF data. Once the OLS policy is detached from the semantic data store, all the sensitivity labels previously assigned to the triples and resources are lost.
This operation drops objects that are specifically created to maintain the RDF security policies.
To apply an OLS policy, use the SEM_RDFSA.APPLY_OLS_POLICY procedure.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".
Name of an existing VPD policy.
Name of the model to which to apply the VPD policy.
This procedure permanently removes or detaches a VPD policy from an RDF Model. You must be the owner of the VPD policy or a user with a DBA role to perform this operation.
After a VPD policy is removed, fine-grained access control for the specific model is turned off and the users with SELECT privileges on the model view can access all the data in the model.
For information about support for VPD, see Appendix C.
Resets the labels associated with a model or with global resources; requires that the associated model or models be empty.
Name of the model for which the labels should be reset, or the string RDF$GLOBAL to reset the labels associated with all global resources.
If you specify a model name, the model must be empty. If you specify RDF$GLOBAL, all the models must be empty (that is, no triples in the RDF repository).
You must have FULL access privilege with the OLS policy applied to the semantic data store.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".
SEM_RDFSA.SET_PREDICATE_LABEL(
model_name IN VARCHAR2,
predicate IN VARCHAR2,
label_string IN VARCHAR2);
Sets a sensitivity label for a predicate at the model level or for the whole repository.
Name of the model to which the predicate belongs, or the string RDF$GLOBAL if the same label should applied for the use of the predicate in all models.
Predicate for which the label should be assigned.
OLS row label in string representation.
If you specify a model name, you must have read access to the model and execute privileges on the SEM_RDFSA package to perform this operation. If you specify RDF$GLOBAL, you must have FULL access privilege with the OLS policy applied to RDF data.
You must have access to the specified label and OLS policy privilege to overwrite an existing label if a label already exists for the predicate. The SECURE_PREDICATE option must be enabled for RDF data.
If an existing predicate label is updated with this operation, the labels for the triples using this predicate must all dominate the new predicate label. The only exception is when the OPT_RELAX_TRIPLE_LABEL option is chosen for the OLS-enabled RDF data.
If you specify RDF$GLOBAL, a global predicate with a unique sensitivity label across models is created. If the same predicate is previously defined in one or more models, the global label dominates all such labels and the model-specific labels are replaced for the given predicate.
After a label for a predicate is set, new triples with the predicate can be added only if the triple label (which may be initialized from user's initial row label or using a label function) dominates the predicate's sensitivity label. This dominance relationship can be relaxed with the OPT_RELAX_TRIPLE_LABEL option, in which case the user should at least have read access to the predicate to be able to define a new triple using the predicate.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".
The following example sets a predicate label for Contracts model and another predicate label for all models in the database instance.
begin
sem_rdfsa.set_predicate_label(
model_name => 'contracts',
predicate => '<http://www.myorg.com/pred/hasContractValue>',
label_string => 'TS:US_SPCL');
end;
/
begin
sem_rdfsa.set_predicate_label(
model_name => 'rdf$global',
predicate => '<http://www.myorg.com/pred/hasStatus>',
label_string => 'SE:US_SPCL:US');
end;
/
OLS row label in string representation, to be used as the sensitivity label for all RDF schema constructs.
OLS row label to be used as the override for generating labels for inferred triples.
This procedure sets or resets the sensitivity label associated with the RDF schema resources, often recognized by http://www.w3.org/1999/02/22-rdf-syntax-ns# and http://www.w3.org/2000/01/rdf-schema# prefixes for their URIs. You can assign a sensitivity label with restricted access to these resources, so that operations such as creating new RDF classes and adding new properties can be restricted to users with higher privileges.
You must have FULL access privilege with policy applied to RDF data.
RDF schema elements implicitly use the relaxed triple label option, so that the triples using RDFS and OWL constructs for subject, predicate, or object are not forced to have a sensitivity label that dominates the labels associated with the schema constructs. Therefore, a user capable of defining new RDF classes and properties must least have read access to the schema elements.
When RDF schema elements are referred to in the inferred triples, the system-defined and custom label generators consider the inference override label in determining the appropriate label for the inferred triples. If a custom label generator is used, this override label is passed instead of the actual label when an RDF schema element is involved.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".
The following example sets a label with a unique compartment for all RDF schema elements. A user capable of defining new RDF classes and properties is expected to have an exclusive membership to the compartment.
begin
sem_rdfsa.set_rdfs_label(
label_string => 'SE:RDFS:',
inf_override => 'SE:US_SPCL:US');
end;
/
SEM_RDFSA.SET_RESOURCE_LABEL(
model_name IN VARCHAR2,
resource_uri IN VARCHAR2,
label_string IN VARCHAR2,
resource_pos IN VARCHAR2 DEFAULT 'S');
Sets a sensitivity label for a resource that may be used in the subject and/or object position of a triple.
Name of the model to which the resource belongs, or the string RDF$GLOBAL if the same label should applied for using the resource in all models.
URI for the resource that may be used as subject or object in one or more triples.
OLS row label in string representation.
Position of the resource within a triple: S, O, or S,O. You can specify up to two separate labels for the same resource, one to be considered when the resource is used in the subject position of a triple and the other to be considered when it appears in the object position. The values 'S', 'O' or 'S,O' set a label for the resource in subject, object or both subject and object positions, respectively.
If you specify a model name, you must have read access to the model and execute privileges on the SEM_RDFSA package to perform this operation. If you specify RDF$GLOBAL, you must have FULL access privilege with the OLS policy applied to RDF data.
You must have access to the specified label and OLS policy privilege to overwrite an existing label if a label already exists for the predicate. The SECURE_PREDICATE option must be enabled for RDF data.
If an existing resource label is updated with this operation, the labels for the triples using this resource in the specified position must all dominate the new resource label. The only exception is when the OPT_RELAX_TRIPLE_LABEL option is chosen for the OLS-enabled RDF data.
If you specify RDF$GLOBAL, a global resource with a unique sensitivity label across models is created. If the same resource is previously defined in one or more models with the same triple position, the global label dominates all such labels and the model-specific labels are replaced for the given resource in that position.
After a label for a predicate is set, new triples using the resource in the specified position can be added only if the triple label dominates the resource's sensitivity label. This dominance relationship can be relaxed with OPT_RELAX_TRIPLE_LABEL option, in which case, the user should at least have read access to the resource.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".
The following example sets sensitivity labels for multiple resources based on their position.
begin
sem_rdfsa.set_resource_label(
model_name => 'contracts',
resource_uri => '<http://www.myorg.com/contract/projectHLS>',
label_string => 'SE:US_SPCL:US',
resource_pos => 'S,O');
end;
/
begin
sem_rdfsa.set_resource_label(
model_name => 'rdf$global',
resource_uri => '<http://www.myorg.com/contract/status/Complete>',
label_string => 'SE:US_SPCL:US',
resource_pos => 'O');
end;
/
SEM_RDFSA.SET_RULE_LABEL(
rule_base IN VARCHAR2,
rule_name IN VARCHAR2,
label_string IN VARCHAR2);
Name of an existing RDF rulebase.
Name of the rule belonging to the rulebase.
OLS row label in string representation.
The sensitivity label assigned to the rule is used to generate the label for the inferred triples when an appropriate label generator option is chosen.
You must have access have access to the rulebase, and you must have FULL access privilege with the OLS policy can assign labels for system-defined rules in the RDFS rulebase.
There is no support for labels assigned to user-defined rules.
For information about support for OLS, see Chapter 5, "Fine-Grained Access Control for RDF Data".