Kibana code seems to go to great lengths to prevent the creation of a custom authentication provider (via a 3rd party plugin)
The existing "providers" map is a hard-coded const in code
Code checks that any used provider actually exists in the const map
You can't get your hands on the sessionProviderFactory; you can't create another one
There is an authentication handler, but only one can be registered (and it is registered by the internal security plugin).
Is this something that Elastic wants to prevent third-party developers from doing? What is the reasoning behind that? It's strange since one can do a third-party authentication provider in Elasticsearch, and it works fine... but it seems to be effectively impossible to use it for creating a Kibana session. Not without patching the Kibana source code itself, anyway.
Hey @virgilp, the authentication provider code within Kibana has been going through rather drastic changes in recent versions, and we didn't consider it stable enough to expose to third-party plugins. We're tracking the request to add this in https://github.com/elastic/kibana/issues/18190.
Do you already have a realm written for Elasticsearch? If you can elaborate upon its internal mechanics, we might be able to provide a work-around which wouldn't require a custom authentication provider in Kibana itself.
The authentication realm in Elastic is fairly basic - it works by reading a signed jwt token from a custom header. Based on the claims there the user is assigned to a special role name and there's a custom role provider that sets permissions based on the role naming convention.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.