Re: [topbraid-users] Implementing Security in a Triple Store

[Scott Henninger]

Tim, there are actually some things you can to achieve the access controls you are looking for with TBS 4.3 (Yes, it does come up often!  And there are many solutions!). As Mark states, we are also working on an asset-based RBAC system that will allow you to define access rights for groups of users for any asset/operation.  Regardless of whether you adopt that or a variation of the example I give below, the first step is to put the secret triples in a separate graph that can be managed with different access controls. From there, options abound.  For example, you can define a SPARQLMotion script that loads data depending on access rights.  BranchByASK would be an easy example.  The query would check the user's access rights and if the ASK statement is true, load the file, otherwise don't. On getting the user's access rights, you can use the teamwork:currentUserHasPrivilege() function. To see more about this, go to Help > TopBraid Teamwork Framework Help.  It's designed for the teamwork framework, but can be used for any kind of role-based security check.  The SPARQL source is in the document, so you could specialize this as needed. Given that it is a SPARQL function that checks the current user against a role registry, it can be used in any SPARQL context to define any level of granularity for security constraints.  In EVN the registry is in the teamwork graph (.tch), and the roles are subproperties of teamwork:role, allowing one to "inherit" access rights (think about that one and ask if it's not clear).   Let's say you define the "basic recipe" in BasicRecipe.oracle and the secret parts in SecretRecipe.oracle.  You'd need a kind of registry that gave you access controls by user (or group).  For example suppose you have a Registry.ttl file:   :joe :hasReadAccess SecretRecipe.oracle .   :jane :hasWriteAccess SecretRecipe.oracle .   :hasWriteAccess rdfs:subPropertyOf :hasReadAccess . A small modification of teamwork:currentUserHasPrivilege(): :accessToRecipe ASK {  {  FILTER smf:hasCurrentUser()    }    BIND(smf:userWithName(smf:currentUserName()) AS ?user) .    GRAPH <Registry.ttl>    {  ?user ?realRole ?governedResource .       ?realRole (rdfs:subPropertyOf)* ?role    } } ...where the two arguments are arg:governedResource and arg:role.  Now you can use the following _expression_ anywhere in SPARQL.    :accessToRecipe(<SecretRecipe.oracle>, :hasReadAccess) Note that both :jane and :joe would return true, but all other users would return false.  And you passed :hasWriteAccess as the role, then only :jane would return true. For your context, where you want a query on {?recipe :contains ?ingredient} to return only those triples one has access to, one way to do this is to manage graphs through imports.  So if BasicRecipe imports SecretRecipe:   {<BasicRecipe.oracle> owl:imports <SecretRecipe.oracle>} ...and given that both SPARQLMotion and SWP have ways of loading the base graph with or without imports, then this can be used in an IF or BranchByASK context to choose whether or not to include the import.  Or you can skip the owl:imports notion and just keep adding graphs to the context you are querying. None of this is tested, BTW, but it gives you an idea of what can be done out-of-the-box.  Basically, setting up a way to define access controls, then use SPARQL to query out which graphs are used. -- Scott On 2/24/2014, 1:02 PM, Tim Smith wrote: Hi, I'm trying to understand best practices for implementing a security model within an RDF environment.  As an example, let's consider Grandma's Cookie recipe which contains a "secret ingredient". I might model a recipe as follows: Cookie Recipe contains Flour Cookie Recipe contains Chocolate Chips Cookie Recipe contains Secret Ingredient I may also drill the ingredients down an additional level by saying: Chocolate Chips contains Sugar Secret Ingredient contains Spice Secret Ingredient contains Pepper Everyone should be allowed to see the first set of triples - a Secret Ingredient is declared but not identified.  Only select people should be permitted to see the contents of the Secret Ingredient, thus access to the last two triples must be controlled. How can I systematically restrict access to certain triples in some cases but not in others? I'm guessing this is a common problem in commercial environments and I am looking for suggestions on how to solve it, including ideas that may sit at the TQ/TBL level or even in the triple store such as Oracle Label Security in the Oracle RDF Graph triple store. Thanks in advance for your input! Tim -- -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.