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.
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.
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.
I need to query Azure via the Graph API to find which Groups I own (or am one of multiple owners). The closest query I've been able to find is:
/users/{userId}/ownedObjects
This returns different types of objects, including Groups. However, it appears to return items that are NOT in fact owned by user {userId}.
Is there a better way to do this?
I have a rather very know Solr issue. The index contain a group of docs of employee records that has a set of public access fields and a set of secure fields. Based on the user's security credentials (which may be indexed in the doc as one field), if a document matched, all its public fields and some of the secured fields which he has access. This list of secure fields varies document to document in the same index. Example: a manage of a department (belonging to one company) can view all secure fields of employees (doc) under him but not for those who do not work under him (whether in the same company or not). But he can still see ALL the public fields of ALL the of the employees (matched and filtered docs).
So being manager, I can see all (public + secure) fields of every one working under me but my asst can see only some of the secure fields who are under him. How to implement this in Solr. Thanks.
The documentation states that Solr does not concern itself with security at the document level.
Solr is designed to be an index of your data, not a replacement for your database (Access control is an important DB feature, only adds complexity to an index)
My suggestions:
Remove all sensitive data from the index. Each Solr document could include a reference (or link) to a 3rd party system/database holding the sensitive data requiring access control.
Encrypt the sensitive content within the index Using public/private key encryption, you can control who is able to decrypt the sensitive fields of a Solr document. (This solution wouldn't scale very well, nor does it allow searching of encrypted fields)
Create a sensitive search index, for each manager: Use the web server's authentication mechanism to control access to the index and load sensitive data there.
I would suggest to take the following steps:
separate out the public and secure content, you can use two separate cores.
add a ServletFilter that sits between User and SOLR webapp and then you can use some basic ACL based security on top of SOLR results to filter out the content as per your application requirements.