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.
Related
If I have a large list of users, how can I return a list of the ones that exist in Azure AD via the Graph without a huge performance hit?
Let's say the Azure Tenant has 30,000 users
And we want to check a list of 1,000 users to see if they exist
I see two ways to do this:
Iterate over each user and check if that user exists, passing in a filter to the graph on the UPN
Query Azure for all users and intersect on that set. This results in 30,000 users being returned which requires paging (~30 pages) on the Azure side. This significantly reduces performance.
Is there a POST request where you can pass in users to match on? Is there a limit to the amount of data you can put in the filter on the GET request?
I have tried to Repro to GET only the List of user from the bulk users in AD.
Use endsWith or startsWith below query
https://graph.microsoft.com/v1.0/users?$count=true&$search="displayName:room"&$filter=endsWith(mail, '#XXXXXXX.onmicrosoft.com')&$orderBy=displayName&$select=id,displayName,mail&$top=2
Make Sure ConsistencyLevel:eventual is added gives me the below result, which has search only top 2 as per the required data.
In our company when I navigate to https://www.bing.com/ I can login with my AAD account and able to perform a search specific to my Company. Meaning, I can filter my search results based on my organization.
I see something like "Show results from XyZ Corporation...."
This makes me think that we have Corporate version of Bing search or I might call it Enterprise Bing and some how its connected to my AAD account so it can fetch corporate search results for me.
However, I am trying to get similar search results by 'Bing Web Search API v7 reference'
I see Web browser search results are different (when I'm logged in )that what I get using REST API.
If I search for 'holidays 2019' on web search I see some results but also see and option to filter them by my company name.
When I do same search using an API
https://api.cognitive.microsoft.com/bing/v7.0/search?q=holidays 2019
I am definitely not sending user context, so I do get search results as if I was not logged in or same results I will get if I was not logged in.
Is there any way to get search results specific to my organization since I can do that on the browser I am trying to do the same programatically.
I think the best solution in your scenario is using Bing Custom Search API as it gives you full control over the search results.
It allows you to specify a URL and whether to include subpages of the URL, add active entries to include results from specific websites or URLs, and much more!
You could also use Microsoft Search in Bing since that customizes results based on your logged in email AD which you mentioned in your question.
In Azure Search we can create multiple indexes for different search results, and we have two types of api-key. One is for administation and other one is for querying. But with same api-key users can search all indexes.
In my solution I need to design a system so that different users that use the system will get different results by their previleges. I thought this could be solved with dedicated indexes for each role but still users can query other indexes if they want to.
How can I be sure that every user can ONLY be able to search on particular a index.
Out of the box it is not possible to restrict the key usage for a specific index. You would need to do something on your own.
Other possibility would be to create different search service accounts and then creating indexes in them instead of having one account. You can then grant access to your users to appropriate search service account.
UPDATE
Based on your comments, you're actually looking to restrict search results (documents) by user's role i.e. going one level deeper than indexes. To achieve this, what you could do is dynamically append this role criteria to your search query as OData Filter. For example, let's say your index has boolean fields for each role type (Administrator, User etc. etc.) and the user searches for some keyword. Then what you could do is create an OData Filter $filter where you check for these conditions. So your search URL would look something like:
https://<search-service-name>.search.windows.net/indexes/<index-name>/docs?search=<search-string>&$filter=Administrator%20eq%20true
That way Search Service is doing all the filtering and you don't have to do anything in your code.
You can learn more about query options here: https://msdn.microsoft.com/en-us/library/azure/dn798927.aspx.
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.
I'm working with Azure ACS and incorporating it into an SSO strategy for my .NET 4.0 website. I see on the Rule Groups page that a bunch of different claims can be stored and passed back to the RP (e.g. country, streetaddress, phone, etc.). It looks like you can also return back any claim type you want to create. This got me thinking about many questions relating to storing information for users:
Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
Could you grab bulk information for reporting purposes off of ACS?
The short answer is generally "yes", but of course there's a longer answer :-).
Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
Yes it could make sense. But for optimization purposes you might keep a copy of some of the user profile information somewhere else (local to the app). ACS rules information would be the "master record" you would update the values in your local store whenever you get a token and check whether there've been changes or not.
It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
No, "unlimited" is a big number. There are limits in the number of namespaces, relying parties and rules. Check the documentation. ACS also supports "cascading" transformations, which can help you reduce the number of rules.
For example:
email: eugeniop#mail.com -> company:Contoso
Company: Contoso -> Language: English
The 2nd rule will be triggered whenever a claim of type "Company", value "Contoso" is issued.
Then you can have:
email: rob#othermail.com -> company: Contoso
The "language" claim will be automatically added.
I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
In a multi-tenant environment, it might be better to have a Relying Party per tenant. This is what we do in sample 7 (Federation With Multiple Partners) available here: http://claimsid.codeplex.com
It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
Yes
Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
It is possible. However, there's no concept of "user" in ACS. So yuou would have to decode that from the rules. You can't have a call like "GetUserprofile( string user)"
Could you grab bulk information for reporting purposes off of ACS?
The API supports bulk info, but for reporting it might be better to have replicated information on your own database.
One last thought: ACS rules engine today is very simple and only does simple transformations (plus cascading), but nothing compared to what ADFS can do today, where rules can be really complex (e.g. db lookups, etc)