In 'kibana' we can restrict specific user to access specific indices. e.g. user 'A' can access only 'logs-*' indices.
I want to know the way how to implement such access for document level instead of indices level.
I searched lot but I did not get any solution for document level authorization. Could you please help me in this.
I am not sure whether it works but you can just give a try. In roles.yml, create a different roles specific to document level authorization. For example,
roleA:
'.kibana':
indices: 'indexA'
privileges: read
fields:
- fieldA
- fieldB
in the rolemapping.yml, map the authenticated user to this respective role. Then only the selected fields will be applicable to Kibana from the elastic search.
Try out this option.
in elasticsearch container
usr/share/elasticsearch/bin/shield ./esusers useradd user1 -p userpass -r rolename
after that
add role in /etc/elasticsearch/shield/roles.yml
rolename:
cluster:
- cluster:monitor/nodes/info
- cluster:monitor/health
indices:
'logs*':
privileges: indices:admin/mappings/fields/get, indices:admin/validate/query, indices:data/read/search, indices:data/read/msearch, indices:data/read/field_stats, indices:admin/get
'.kibana':
privileges: indices:admin/exists, indices:admin/mapping/put, indices:admin/mappings/fields/get, indices:admin/refresh, indices:admin/validate/query, indices:data/read/get, indices:data/read/mget, indices:data/read/search, indices:data/write/delete, indices:data/write/index, indices:data/write/update
Related
In my application the users are split in 2 macro categories: Customer and Backoffice, every category has a subset of role, for example MANAGER and USER for Customer type and different ones for the Backoffice type.
So a user could be a Customer with a MANAGER role or a Backoffice with, for example, a SALES role.
Every Spring + Cognito guide on web uses cognito:groups to map the Spring ROLE, but for my case I would need to nest groups which is not possible on Cognito.
I've been thinking to use 2 custom attributes ( writable only by the admin) to set the category and role of the user respectively.
My question is, is there any disadvantage to using attributes instead of the groups?
One major concern is, those custom attributes won't be available as claims in the access token. But groups are available. So If you plan to use acces_token you may have to consider that.
There are some other minor considerations that I can think of, which may or may not be related your implementation:
Maximum number of custom attributes per user pool is 50.
Once created, you can not edit the name, min/max length and mutable property of the custom attribute. Also we can not delete that.
Even though nested groups are not supported in Cognito, is it not an option to create groups like: category_role? example: Customer_ MANAGER?
Out of the box Laravel authorizes users by matching email (default - can be overridden) and password.
Is it possible to authorize user using 3 fields, e.g:
email
password
group
... where 'group' is some additional field from 'users' database.
In other words, user can belong to group:1 and can login to group:1 resources only, but not to group:2 using his group:1 credentials.
If user belongs to group:1 and group:2, then he needs different credentials to login to either group.
Additionally, user can use same email for both groups. In such case it is group number that would act as additional identifier. And of course passwords would be different.
I am thinking setting a database multiple column index on fields 'id' and 'group' would be a good start, but I fail to grasp (yet), what would be required to make Laravel authorization process sensitive to 3 fields, instead of 2.
I would appreciate some pointers.
This sounds like you're trying to achieve a form of tenancy on data belonging to certain groups only. Have a look at this package:
https://github.com/HipsterJazzbo/Landlord
In essence, you would add a group_id field to the tables where you wish to restrict access and then using middleware, apply an additional where('group_id', Auth::user()->group_id) clause to any database queries. This works very well for retrieving subsets of data belonging to specific users by their role, for example.
I have an index with many documents. In my app, a login happens under a username. For a user only a group of data should be visible, that is I want to restrict each user to a set of documents. Can somebody offer a solution of how to implement this using elasticsearch?.
Suppose my index contain the follwing documents
record1
record2
record3
record4
And I have say 2 users, user1 and user2
When the user1 is logged in, he should have access to "record1","record2" and "record3". Where for user2 , the access should only be to "record4".
Probably you can add one more column to the index where in you can persist the intended user for the record and while querying the index you can check if the logged in user in among the users specified in the column.
I would advise you to use a index aliases.
Index aliases has the capability to add filter to them.
So create 2 aliases , one for each user.
Now for each alias , create a filter which restricts the user to his own set of documents. ( Just use a document ID search )
Restrict these users to use only these aliases using a proxy.
That should do the trick
We're considering using Elasticsearch for our webservice. Since ES operates at a low level, for authentication and authorization there has to be some layer above it. I see Shields which apparently can control on a roles-based level what a user, and admin, a developer etc. can do in the search index. What I could not find, however, is how to control data access on a user level: Every user has to have access to all public documents plus his/her private ones.
Is there an ES plugin/paradigm that handles this?
The idea with Shield is to have a user group in the indexed document:
{
"text":"Document 1 is public",
"user_group": ["public"]
}
{
"text":"Document 2 is restricted",
"user_group": ["restricted"]
}
Then you can force a filter to be applied for a specified user group
# For users in group public
{"term" : {"user_group" : "public"}}
# For users in group restricted (can see public as well)
{"terms" : {"user_group" : ["public","restricted"]}}
Elasticsearch 2.0 / Shield 2.0 has improved Document level security. Prior to that you were forced to use Index Aliases.
SearchGuard (a Shield alternative) behaves likes Shield: dlsfilter binds a user group with filter.
In both cases, binding a user to a document might be a difficult (impossible?) task, because everything is based on user groups/roles, not individual users. You could generate a group specific to each user though. Each time you add a user, it will force you to add a user group, and configure its specific grants.
This question is really made of two parts.
Using Parse, I'd like to have the following [simplified] scheme, where I have Users who are part of secret groups, and there are discussion that can appear across a few groups at one. That is Users who are part of Group A also are added to the GroupA role, and have access to discussions in Group A.
My trouble is, when I create a new discussion and tell it the groups it should appear in, how do I query for the roles and add them to the Discussion as well? I'm really fuzzy on this roles/ACLs business, even after reading extensively.
User(firstname, lastname)
Group(members, secrets)
Discussion (groups, note, comments)
Create a Role when you create a Group. Assign a pointer from the Group to the Role. Set the ACL for the Group to the Role (for write, it can be public read or whatever you want). When you add users to the Group, add them to the Role so they have access through the ACL.
For your Discussion you need to add all of the appropriate Roles from all of the Groups to the ACL list so that all of the users in all of those Roles have access.