Feature possibility: Metadata-based security

Jan 3, 2012 at 6:44 PM

Hello, I work for a private communications hardware company in Carlsbad, CA.  We are exploring SPSerivces' cascaded drop-downs feature as an alternative to more clunky proprietary solutions and are impressed with what we've seeing so far.  One additional feature, besides cascaded drop-downs, that we're interested in implementing on our SharePoint site is metadata based security similar to Titus Metadata Security plugin for SharePoint.  We had a bad experience trying to get this proprietary plugin to work and were looking at alternatives.  Would it be possible to implement such a feature using a pure JavaScript solution like SPServices?

The way I understand Metadata security works is a list is filtered based on the content of a specific column(s).  So a specific user and/or group is only allowed to view specific content based on what's specified in that column.  It seems like it should be a straightforward solution, JavaScript would just take the user and/or group information and match it against some rules list that determines which rows that specific user/group is allowed to see in the list.

Jan 3, 2012 at 7:03 PM

The short answer in my opinion is yes, you can do this with SPServices. The long winded answer is that it will take several checks to pull off. In your scenario, you are requesting a permission based on the contents of an item. My first question would be "Do you have access to the server and could you write server side code?", and if so. doing it there is much easier. Keep in mind this is just my opinion. If you still want to go the client side route, which is fine, remember that webservices still run in the context of the user, and as such they will need to have some permission to items in a list regardless of the metadata. This solution would not prevent a clever enough user from editing an item they shouldn't unless you take a lot of extra steps. Still doable, but requires some effort. Post back if you would like to know more!

Coordinator
Jan 3, 2012 at 7:09 PM

Client side script is rarely acceptable for security implementations. It really depends on what you mean by security. If you're fine with obscurity, then client side script is great.

Another thing to think of using is a Data View Web Part (DVWP). Since these are XSL-driven and execute on the server, you can implement true security with them; the content never makes it to the client browser.

M.

Jan 3, 2012 at 7:53 PM
Edited Jan 3, 2012 at 7:58 PM

@spevilgenius & sympmarc - Thank you both for the prompt responses, I am interested in knowing more.  Unfortunately I do not have full access to the server side code, I am only the administrator for the specific site that was setup for my group; although I am in direct contact with the primary SharePoint server farm administrator, so server side code is also an option.  We've been trying to come up with a way to implement something like this for the last couple of months but have not had any success.  

As symparc mentions, we could start with an obscurity approach to simply hide the content a user sees, basically an automated filter that acts based on the user's credentials.  So for example, by default Site Owners see everything in the list, while any Site Visitors group members will trigger SPServices to filter the content Site Visitors are not allowed to see using specific values from the specified metadata column(s).  What are drawbacks to the obscurity approach?  How could a savvy user circumvent this?  In your opinion(s), what additional steps would be required to make this a complete security-based solution using either server or client side code?

Although server-side code is possible, a client-side solution would also preferred to eliminate the IT middleman.  I'm the primary developer in my group for our specific SharePoint site, so removing the need to contact IT for any required changes would be great.

I'm not very familiar with the Data View Web Part (DVWP), could my scenario above be implemented using just this web part?  Or would a JS solution be better suited?

Coordinator
Jan 4, 2012 at 4:01 PM
Edited Jan 4, 2012 at 6:09 PM

The simple circumvention is to just turn off script. Then your 'masking" won't run and the content will be visible. That's the basic reason why client side, script-based security falls down. They can also simply hack the URL to go to a view of the list which doesn't have the script on it. Basically, a resonable savvy SharePoint user could beat it.

As for the DVWP-based approach, absolutely. Take a look at some of my blog posts about DVWPs, specifically my series whcih starts with Unlocking the Mysteries of Data View Web Part XSL Tags – Part 1: Overview

M.

Jan 4, 2012 at 8:01 PM
Edited Jan 4, 2012 at 9:13 PM

Thanks again sympmarc.  I read through the article and it is a great start.  Is there a Part 2 available?  I searched your site and got the hint that DVWPs are created and edited within Sharepoint Designer.  I'm starting by using the official Microsoft Office tutorial to create prrof-of-concept DVWP in Sharepoint Designer 2007 for my test list.  If there are any other tutorials you recommend, I'd appreciate it.

For my scenario above, I'm imagining creating several DVWPs for each group, i.e. a DVWP for Site Visitors and Site Testers; Site Owners won't need a DVWP since they are allowed to see everything.  I added the Site Testers group to show that there will be more than one sub group, besides Site Visitors, below Site Owners in my scenario.  So in the scenario, each group is assigned its own DVWP which displays only the list content they're allowed to see, the source list itself will be denied access to all groups but the Site Owners.  Am I correct in assuming that DVWPs will accommodate this scenario nicely? Is this the best approach toward a metadata style of security in SharePoint?  Would there still be a way to circumvent DVWPs such that the entire list of data is view able?

Another, more critical, issue is the requirement that a non-Site Owner user can be a member of more than one sub group, i.e. user1 can be a member of Site Visitors and Site Testers.  In this case, user1 should be allowed to see the content designated for both Site Visitors and Site Testers, is SharePoint smart enough to determine what user1 is allowed to see?  The scenario I'm imagining is that SharePoint, somehow, merges the DVWPs for Site Visitors and Site Testers so that user1 can see the content that both sub-groups are allowed to see.  Any suggestions or feedback on this approach is appreciated.

Jan 5, 2012 at 12:45 AM
Edited Jan 5, 2012 at 12:45 AM

I spent sometime today trying to see if I can get a proof-of-concept going starting with the Site Testers group.  I was able to get a simple page with Data View Web Part going to only show certain items and it looks to be working as expected.  

Just a few questions, is it possible to make it so users can only add items to a source list from the DVWP without giving them access to the source list itself?  I assigned write permissions to the DVWP and source master list to the Site Testers group.  The group can view the content of the list from the DVWP just fine and they are denied access to the source list as expected.  But when I try to add a new item to the list from the DVWP, as a Site Tester, it says access denied.  Is this because the NewForm.aspx of the source list has limited permissions?  If so, how can I add a custom list form for the DVWP so that Site Testers can add new items?

Coordinator
Jan 9, 2012 at 2:33 PM

In order to be able to add or edit items in a list, the user has to have Contributor permission. (Contributor is actually a bundle of specific permissions, but it's the easiest way to explain it.)

Forms or Web Parts don't have the permissions, users do.

M.