I need to implement sharepoint search using query web service in javascript. I am able to do it but the results I am getting are not security trimmed. Users can see even those files which are not accessible to them (i.e. they dont have permission to view those files).
My questions are:
How to get security trimmed results when using query web service in javascript?
Is there any other way to perform search and get security trimmed results?
Many thanks.
As long as the query is being made from the users account/role (user is logged in and accesses a page with a query webpart, etc), that query should only return the security trimmed results. SharePoint's webservice handles the security trimming by default.
However,if you write a custom query and elevate privileges in your code, such as using the SPSETUP account, then you will get non-user specific results. This is bad practice for the majority of scenarios.
Related
I have a web-application secured with Keycloak. To keep the description of the service short, we have Users and Documents as entities in the service. The users may have access to none or more documents and may edit or read the document.
Currently we have roles such as Admin, EndUser, Developer etc. We then keep a database table outside of Keycloak that maps the documents to users and what user has what access level to what document. All our end-users have the EndUser role in Keycloak. Every single time an EndUser tries to read/edit a Document, we have to make a lookup in the database table for authorization.
We would like to migrate that table to Keycloak. As I understand it I basically have two options:
Create a lot of roles, two for each document with names such as doc_read_[DOCUMENT-ID] and doc_edit_[DOCUMENT-ID] and so on. Then assign the correct role to the correct user. The downside here is that the number of roles will grow A LOT. Also, the number of roles attached to a user will be very large.
Create a group for each document, with the name of the document id. Have different sub-groups for read/write and then add the users in the correct groups. The downside is that the number of groups will be very large. Also, I will rely Authorization on group names, so the list of group names has to be mapped to the token.
I do not want to add a user-attribute with the document-ids to each user. With this approach I can not get an overview of a document and see what users have access to a given Document.
What is the best practice here? Are there any other solutions to solve this issue? This must be a very common setup.
This is just my opinion.
From what I understand both solutions are suboptimal, adding a role per document is unnatural and too finer grain. And as you already mention this would lead to too many roles that probably you will have to add them into the token.
I would personally use Keycloak just for the authentication part and do the authorization part in the backend. I would also try to group the documents in a way that reflect which user roles are allowed to manipulate them.
Alternatively you might try to use Keycloak's Authorization features to handle that use-case, however I have never used it, so there is not much that I can say about this option.
In my opinion what you want to achieve is something that is very tied to your business logic, I wouldn't recomend depending on keycloak to do it. Your token would constantly grow and management would be a nightmare really.
I see no problem in having a service with good cache to lookup permissions, the bulk of the data won't change much over time.
We would like Azure Search to be able to restrict search results for certain users by some means – we are considering using the filter (https://learn.microsoft.com/en-us/azure/search/search-filters) option for this.
So far, we understand that the search query and the search results from Azure Search would be public and unencrypted.
Is there a way that the search query can be encrypted so that a user cannot meddle with the filter values and see data he is not authorized to see?
Similarly, for the results, in there a way to prevent an unauthorized person from seeing the results returned from Azure Search?
There's encryption at rest an in transit, but ideally you should implement your own authorization mechanism to handle what users can see. There's no ready to use feature for it.
Was not able to find a way to discover all the sites of an organization:
creating a site with user2
approving the app with an admin
using 'https://graph.microsoft.com/v1.0/sites?search=' does not show the new site.
Only once i add the admin to the site group I find the new site.
how can I find all the sites?
Do I need to get an access token for each user?
For example with this token I can access all the drives but can't find the sites.
There are a couple things going on related to what you're asking and I'll try to address each of them:
1) We don't have an officially supported way to discover all of the sites and site collections in a given tenant today. The "search=*" query may give you the results you're after but it is not guaranteed in all scenarios. We're looking at this scenario but do not have formal support in the product today.
2) Search results are security trimmed, when using delegated permissions the search API will only return sites that the logged in user has access to. This could explain why you needed to add the Admin first before it showed up.
3) To use search in scenarios where you do not want security trimmed results you will need to user Application permissions and have the Tenant Admin perform the application consent flow for the entire tenant. This is a fairly broad permission but is required for some scenarios.
I am trying to find out if the currently logged on user has a certain security role. I've looked on Google (couldn't find an answer) and the SDk examples (they seemed way too complicated). So, if you know the name of the security role and the user ID, how do you check to see if the user has that role?
If you browse the folder structure of the CRM 2011 SDK (link: https://www.microsoft.com/en-us/download/details.aspx?id=24004) to this location you will find what you are looking for:
.\SDK\SampleCode\CS\BusinessDataModel\UsersAndRoles\DoesUserBelongToRole.cs
It provides a sample built as a C# Console application. The code will work in ASP.NET as long as the app pool user is authorized to access the CRM Organization that you are trying to connect to.
Hope this helps
You should be able to find lots of examples out there. However to get the current users roles in JavaScript you can use:-
Xrm.Page.context.getUserRoles()
That however will return a list of GUID's which you then need to compare with roles in the system. This part is a bit trickier however here is an article that shows pretty clearly how to do it
http://www.infinite-x.net/2010/11/16/retreiving-user-roles-in-crm-2011/
At a high level you need to do an OData query (against RoleSet) to return the role (or roles) that you are wanting to compare. Then you compare the GUID's of those roles against the GUID's returned by the getUserRoles() function and you're good to go!
I have a web application which consumes the SharePoint 2007 search web service (http://localhost/_vti_bin/search.asmx). My scope contains several content sources, all of them contain business data (content is crawled via SQL queries on external databases). I need one of these content sources to provide me security trimmed results. To put it simple, I have two tables:
Table A with contents: NodeId, Title, Content
Table B with permissions: NodeId, Username
Now, the crawler indexes table A with no problems. My problem is though, that when doing a search with the query web service, I cannot find a solution to do a security trimming of the results. The web service is consumed with a service account, no impersonation of logged in user. Is there a possibility to pass somehow the username to the querypacket object, or any other way that would check the Table B, whether the username has access to the NodeId?
Since I'm planning to migrate onto SP2013, maybe some of you also know a solution for this Sharepoint version, if there is no way in MOSS2007?
There are a few 3 main options for doing security trimming of SharePoint search results. They include:
ISecurityTrimmerPre - New in SharePoint 2013. Allows adding additional claims for the user before a search query is executed
ISecurityTrimmerPost - Also known as ISecurityTrimmer2 in earlier versions of SharePoint. Allows trimming search results on a 1 by 1 basis after a search query is executed
Business Connectivity Services Indexing Connectors - Allows you to supply ACLs to the search indexer when it is crawling the content source
There is a great set of blog articles that show how to implement each option.
Also, here's a great video of a SharePoint Conference 2012 session on custom security trimming.
HTH
-Eugene