Hi @sebastianboelling ,
it seems that every content index needs his own access control index, right?
And both are reverenced by their name (.search-acl-filter-indexblah and search-indexblah). Would'nt it be easier to reference them by an field which is either included in the content index or the access control index (or maybe both)?
That would be an option, but we chose using index names to correlate them so that permissions couldn't be accidentally or maliciously disassociated. If I had my data in index
search-indexblah and permissions in
other-acl-index, and was associating them with some mapping in the
search-indexblah/_mapping, a change to that mapping for a data migration might remove or alter the association my data security relied on.
Then one acces control index could be used for more then one content index - which would be a great feature if you have always the same users for every datasource.
That is true.
Or why not bind to users to LDAP, AD, SAML etc. ?
Not all customers use LDAP, AD, or SAML. And even if all customers did, not all customers would use their SSO systems for identity management for all their sources of data.
In the long run, we'd like to ensure that if you use an LDAP, AD, or SAML realm for Elasticsearch Authentication we can help you also ensure that your authenticated users are assigned auto-generated Elasticsearch Roles that limit their access to connector-powered indices using DLS. This functionality does not exist at the time of writing this, but stay tuned to our release notes in future versions.
Even once we do have this functionality though, we will not rely solely on it, because we want to adopt a security posture that is accessible to all customers, not just ones who use certain identity management tools.
For understanding: It is really hard to manage a huge numbers of users for each access control index if you have a lot of datasources and you have always the same users (if you have an central IAM service in your enterprise)..
I understand the difficulty, and I empathize. We're taking steps to make this process easier. For example, you may have noticed that while in Workplace Search, External Identities had to be created one at a time, via API, to map users to their identities. And this had to be done before a Permissions Sync, to inform the sync on what user information should be retrieved. In the newer connectors, however, all user identities are retrieved and synced, so that they can be looked up at query time. The Elasticsearch Filter is also transparently available, to put more power in the hands of the developer.
BTW. Is the name of the access control index .search-acl-filter- as described here How DLS works | Enterprise Search documentation [8.9] | Elastic or without a prefix dot "." as shown here Leverage document-level security from connectors in Search Applications | Enterprise Search documentation [8.9] | Elastic for the SharePoint sample search-acl-filter-sharepoint .
. is correct. Thank you for flagging the mistake in our docs, I've raised a PR and should have the
. added correctly soon.