This is a diff between 1.2 and 1.3 revisions:

* [[VAL_OAuthACLs][VAL OAuth Application ACLs]] * [[VAL_CuriACLs][ACLs for Access to the Compressed URI Support]] * [[VAL_SqlACLs][SQL ACLs - Control SPARQL Access in SQL Connections (ODBC)]] * [[VAL_HttpRestrictions][ACL Restrictions for the Virtuoso HTTP engine]]You can find more VAL tutorials here:---++ Additional VAL Tutorials * [[VAL_ValCustomization][VAL Customization]]For more information, see:VAL also supports the setting of a custom page footer for any VSP page. * the named graphs used to store rules, groups, and restrictions * whether the authentication dialog is displayed automatically when access is denied * the logos displayed on the VAL authentication dialogLimited customization of VAL is possible. Aspects of VAL which can be customized include:---++ Customizing VAL * [[VAL_AuthenticateVspTutorial][VAL VSP Authentication Tutorial]]For more information, see:VAL provides an easy means by which to add authentication and ACL support to new or existing VSP-based applications. It provides authentication and log-out pages to support simple log-in and log-out links. The authentication page can be embedded in a cus---+++ Protecting a Web Service with the VAL Authentication UI * [[VAL_SparqlACLs][ACL rules applicable to named graphs and SPARQL in general]]For more information, see:Virtuoso uses the VAL ACL system to control access to named graphs, and to SPARQL in general. These rules, when enabled, are enforced on <code>/sparql</code> endpoints as well as any other application which tries to access those named graphs directly or ---+++ Controlling Access to Named Graphs and the SPARQL Processor with VAL * [[http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtConfigureCartridges][Sponger Cartridge Configuration and Implementation Notes]] * [[http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/SpongerOAuthSupport][Sponger OAuth Support]] (including [[http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/SpongerOAuthSupport#Configuring%20Cartridges%20to%20use%20VAL%20OAuth][ * [[VAL_SpongerACLs][ACL rules applicable to the Sponger]]For more information, see:The Virtuoso Sponger can be controlled via ACL rules, defining who is allowed to Sponge, and who is not. Additionally it is possible to define who is allowed to use which Sponger cartridges. VAL authentication also provides a mechanism by which users may---+++ Controlling Access to the Sponger with VAL---++ Using VALNote once VAL is installed/enabled all graphs are protected by default and ACL rules need to be specifically created to allow access.VAL is shipped with the Virtuoso commercial installers. If not already installed as part of ODS, VAL is available as a [[http://docs.openlinksw.com/virtuoso/vaddistr/][VAD (Virtuoso Application Distribution)]] archive and can be installed via the Virtuos---++ Installing VALSimilar considerations apply when the resource being protected implicitly requires access to graphs. For instance the /describe service. A VAL rule for this service grants <code>acl:accessTo &lt;urn:virtuoso:access:sponger:describe&gt;</code> and does noIn cases where the resource being protected by a VAL rule is an RDF graph, the permissions granted by the VAL rule must be consistent with the base permissions granted by the RDF graph security. Virtuoso's [[http://docs.openlinksw.com/virtuoso/rdfgraphse---+++VAL vs RDF Graph SecurityVAL provides a framework for creating and managing access control lists. Its core function is to <em>report</em> a user's permissions when they attempt to access a resource. It does not <em>enforce</em> the reported permissions. The act of enforcing them---+++Permission Reporting, Not EnforcementVAL defines resource <code>&lt;urn:virtuoso:access:sql&gt;</code> to allow users to perform SQL commands in addition to SPARQL, and to enforce request rate and result size limits on SQL clients. <code>&lt;urn:virtuoso:access:sql&gt;</code> is used in con---++++SQL Clients - Resource URI
>img style="display: block; border: 1px solid #dddddd; margin-left: auto; margin-right: auto; padding: 30px;" src="%ATTACHURLPATH%/acl_checking_layers_with_disabled_scopes.png"/>
>br/>
>img style="display: block; border: 1px solid #dddddd; margin-left: auto; margin-right: auto; padding: 30px;" src="%ATTACHURLPATH%/acl_checking_layers.png"/>
The diagrams below illustrate how VAL is capable of supporting layered fine-grained access control. In this illustration, different access policies could be enforced depending on the route taken to access the Sponger. Also shown is how disabling certain In the case of the /describe and /about scopes, the corresponding resources are the service endpoints identified by URI <code>&lt;urn:virtuoso:access:sponger:describe&gt;</code> and <code>&lt;urn:virtuoso:access:sponger:about&gt;</code>. The /sparql endp---++++/sparql, /about & /describe Services - Resource URIsWhile the scope identifies the <em>type</em> of the protected resource; the <em>specific resource</em> being protected is identified through the <code>acl:accessTo</code> property. Graphs, both public and private, are identified by their URL, as are indi---+++Resources
>img style="display: block; margin-left: auto; margin-right: auto;" src="%ATTACHURLPATH%/ACL_Configuration_UI.png"/>
>div style="text-align: center; width: 100%;"><b>Conductor's VAL Configuration UI</b></div>
Conductor's VAL Configuration UI can be accessed by navigating to the System Admin &gt; Packages panel, then clicking on the 'Configure' link for the VAL VAD.;
>/verbatim>
{ oplacl:DefaultRealm oplacl:hasEnabledAclScope oplacl:Query } INSERT { oplacl:DefaultRealm oplacl:hasDisabledAclScope oplacl:Query } DELETE WITH <urn:virtuoso:val:config>PREFIX oplacl: <http://www.openlinksw.com/ontology/acl#>SPARQL
>verbatim>
Scopes can easily be enabled and disabled using the VAL Configuration UI in the Virtuoso Conductor, or by setting the corresponding value directly in the scope graph. For example: Scopes can be in one of two states, enabled or disabled. This provides an easy means of enabling or disabling all ACL rules in that scope. Disabling a scope disables all ACL permissions checking on the corresponding resources, in effect making them publiThese and other predefined Virtuoso scopes are defined by the [[http://www.openlinksw.com/ontology/acl][Virtuoso ACL ontology]]. Because scopes can be any arbitrary URI an application chooses to use, adding a scope for a new service is simple. * contains all ACL rules granting access to specific Sponger Cartridges * Sponger cartridges scope: <nowiki><code>&lt;http://www.openlinksw.com/ontology/acl#SpongerCartridges&gt;</code></nowiki> * contains all ACL rules controlling access to the /about endpoint providing a basic entity description service. * /about service scope: <code>&lt;urn:virtuoso:val:scopes:sponger:about&gt;</code> * contains all ACL rules controlling access to the /describe entity description service supporting follow-your-nose exploration and inferencing. * /describe service scope: <code>&lt;urn:virtuoso:val:scopes:sponger:describe&gt;</code> * contains all ACL rules granting access to specific private named graphs. * Private graphs scope: <nowiki><code>&lt;http://www.openlinksw.com/ontology/acl#PrivateGraphs&gt;</code></nowiki> * contains all ACL rules granting permission to perform SQL or SPARQL operations * Query scope: <nowiki><code>&lt;http://www.openlinksw.com/ontology/acl#Query&gt;</code></nowiki>VAL defines some standard scopes for Virtuoso resources, including:Each ACL rule has a scope property, for instance: <nowiki><code>oplacl:hasScope oplacl:PrivateGraphs</code></nowiki>. The scope identifies the type of resource being protected and allows setting of default permissions for that resource type.---+++ScopesPublic access to a resource is granted using <code>acl:agentClass foaf:Agent</code>.
>/verbatim>
oplacl:hasRealm oplacl:DefaultRealm . oplacl:hasScope oplacl:PrivateGraphs ; acl:agent <#groupBasicNetID> ; acl:accessTo <http://OpenPermID-bulk-organization-20151111_095807.ttl> ; oplacl:hasAccessMode oplacl:Read ; foaf:maker <http://kingsley.idehen.net/dataspace/person/kidehen#this> ;
>#PrivateNamedGraphRule1> a acl:Authorization ;
] . <http://www.openlinksw.com/ontology/acl#hasValue> 1 <http://www.openlinksw.com/ontology/acl#hasComparator> <http://www.openlinksw.com/ontology/acl#IsNotNull> ; <http://www.openlinksw.com/ontology/acl#hasCriteria> <http://www.openlinksw.com/ontology/acl#NetID> ; a <http://www.openlinksw.com/ontology/acl#GroupCondition>, <http://www.openlinksw.com/ontology/acl#GenericCondition> ; <http://www.openlinksw.com/ontology/acl#hasCondition> [ <http://xmlns.com/foaf/0.1/name> "Identities Denoted using a NetID based Identifier" ;
>#groupBasicNetID> a <http://www.openlinksw.com/ontology/acl#ConditionalGroup> ;
>b>Example: Private graph access limited to a conditional group</b>
>verbatim>
Simple groups are lists of members. Conditional groups remove the need to enumerate every member, and instead define a set of conditions. These conditions typically test attributes of the X.509 client certificate provided by the authenticated user's <nowGroups are usually stored in graph <code><nowiki>&lt;http://HOST/acl/graph/groups/http%3A%2F%2Fwww.openlinksw.com%2Fontology%2Facl%23DefaultRealm&gt;</nowiki></code>.In addition to simple ACLs granting access to an individual, rules can be written to grant access to a simple group, a conditional group, or everyone (i.e., make a resource public). ---+++GroupsEach permission granted through oplacl:hasAccessMode should be stated explicitly. A broader permission does not implicitly grant a more restrictive permission; so oplacl:Sponge does not also grant oplacl:Read, for example. To allow sponging to a graph, tRules are stored in a private graph matching the realm the rules apply to, typically graph <nowiki><code>&lt;http://HOST/acl/graph/rules/http%3A%2F%2Fwww.openlinksw.com%2Fontology%2Facl%23DefaultRealm&gt;</code></nowiki>. oplacl:hasScope <urn:myscope> .
>/verbatim>
acl:accessTo <http://www.fusepool.eu/p3/assets> ; acl:agent <http://www.facebook.com/jsmith> ; oplacl:hasAccessMode oplacl:Read ; a acl:Authorization ;@prefix acl: <http://www.w3.org/ns/auth/acl#> .
>#rule>
@prefix oplacl: <http://www.openlinksw.com/ontology/acl#> .Below is a basic example of an ACL rule granting <code>READ</code> access to a user authenticating through their Facebook account, <code><nowiki>&lt;http://www.facebook.com/jsmith&gt;</nowiki></code>, to resource <code><nowiki>&lt;http://www.fusepool.eu/
>verbatim>
ACL rules grant permissions to a <nowiki>ServiceID</nowiki> either directly or indirectly through an ACL group, both via the <code>acl:agent</code> property.---+++Rules
>nowiki><code>oplacl:DefaultRealm</code></nowiki> is for use in ACLs targeting SPARQL clients. VAL defines realm <nowiki><code>oplacl:Sql</code></nowiki> for ACLs controlling SQL clients, i.e. isql, ODBC, JDBC, ADO.NET, OLE DB clients etc. (SPARQL ACL rules defined in the default realm do not apply in SQL connections. Refer to [[VAL_SqlACLs][SQL ACLs - Control SPARQL Access in SQL Connections (ODBC)]] for more details.)
Each ACL rule and group is defined in a specific application realm which is stored with the rule or group using the <code>oplacl:hasRealm</code> property. Each application realm defines a distinct set of rules and groups. The default realm is <nowiki><co---+++RealmsA <i><nowiki>ServiceID</nowiki></i> is a personal URI of some kind and may be one of two types: a <nowiki>NetID</nowiki>, or a <nowiki>WebID</nowiki>. A <nowiki>NetID</nowiki> is a URI returned by one of the numerous third-party authentication services sVAL enforces data access policies on the basis of <i><nowiki>ServiceIDs</nowiki></i>. A <nowiki>ServiceID</nowiki> uniquely identifies the resource requestor. A user (aka agent) trying to access to a non-public VAL protected resource or service will usua---+++Service IDs
>i>Rules</i> and <i>groups</i> are stored in private named graphs within the triple store, as are resource ownership details. The rules may grant <code>READ</code>, <code>WRITE</code>, or <code>SPONGE</code> permission on a resource, or the ability to <code>GRANT</code> these permissions. Custom permissions can also be defined.
A <i>resource</i> is any entity identified by a URI. This could be a DAV folder, a SPARQL endpoint, or a Sponger extractor cartridge, among other things. VAL manages and reports the permissions on the resource, but the application logic supporting the reThe ACL rule system allows any authenticated person (including any third-party <nowiki>ServiceIDs</nowiki> which have no corresponding Virtuoso SQL account) to create ACL rules for any resource they own or for which they have <code>GRANT</code> rights. The following section outlines some of the core concepts underpinning VAL ACLs. The intent is to provide a brief overview. More detailed discussions of the various topics introduced here are provided elsewhere in the VAL documentation.---++ The VAL ACL Rule System - Core ConceptsVAL's generic ACL layer is fully RDF-based, storing rules and groups in private graphs in the triple store, and describing rules using the [[http://www.w3.org/ns/auth/acl#][W3C ACL ontology]] and the [[http://www.openlinksw.com/ontology/acl#][<nowiki>Ope * Not all OAuth services require a Virtuoso SSL endpoint. * Before a third-party OAuth service can be used by VAL, it must be registered with Virtuoso. See <a href="http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/SpongerOAuthSupport#Registering%20OAuth%20Application%20Keys%20In%20Virtuoso">R * Note: * Numerous services including Facebook, Twitter, <nowiki>LinkedIn</nowiki>, and Google * Third-party OAuth services * <nowiki>WebID</nowiki> + TLS * <nowiki>OpenID</nowiki> * <nowiki>BrowserID</nowiki> * Basic PKI * HTTP authentication (for users with a Virtuoso SQL user account)The supported authentication methods are:
>img style="display: block; margin-left: auto; margin-right: auto;" alt="VAL authentication dialog" src="%ATTACHURLPATH%/authenticate.vsp.png"/>
>div style="text-align: center; width: 100%;"><b>VAL authentication dialog</b></div>
Typically, users attempting to access a VAL-protected resource must authenticate themselves through a VAL-supplied authentication dialog. After establishing a VAL session, their access permissions on the resource are checked.VAL provides both *authentication* and *access control services* to Virtuoso through an internal Virtuoso API and two externally accessible HTTP APIs, one a "standard" HTTP API and the other a RESTful variant, which manage rules and groups via their URLsHowever, our recommended and preferred <i>generic</i> access control mechanism for Virtuoso is VAL, the Virtuoso Authentication Layer. VAL provides a *generic ACL layer* which can be used to protect many Virtuoso resources, including SPARQL endpoints or * [[http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtRDFGraphsSecurity][Graph level security]] allows the setting of permission bit masks to set the read/write (and sponge) permissions on specific RDF graphs to control public or specific * [[http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtTipsAndTricksGuideSPARQLAssignRoleToUser][SPARQL roles]] restrict the types of SPARQL commands a database user may perform. * [[http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtTipsAndTricksGuideSPARQLEndpoints][Protected SPARQL endpoints]] are associated with specific authentication methods, e.g., <code>/sparql-auth</code>, <code>/sparql-oauth</code>, <code>Virtuoso provides numerous options for access control, some specific to particular realms. For instance:---++ VAL In a Nutshell---%TOC%---Developers wanting more in-depth coverage of how VAL integrates into Virtuoso, or how to integrate VAL into their own Virtuoso applications, should refer to the [[http://docs.openlinksw.com/val/index.html][VAL API documentation]].These pages provide an overview of VAL for system administrators, with a focus on how to configure the VAL ACL system. *See also*: [[ValWhatWhyHow][Virtuoso Authentication Layer - What, Why and How]]---+ Virtuoso Authentication Layer - ACL System Quickstart Guide%META:TOPICPARENT{name="ValWhatWhyHow"}%