I'm researching Elastic's support for SAML for SSO and RBAC. As far as I understand from the documentation, Elasticsearch's SAML auth realm can work with any SAML supported IdP, and along with role mapping based on an attribute (and Kibana Spaces) RBAC could also be integrated.
However, my use case involves multi-tenancy based on different SAML certs. Different tenants use different SAML certs to reach the IdP. This requires Kibana (or Elasticsearch) to discover which SAML cert to trust based on (in my case) the URL used to access Kibana. I couldn't find any documentation that addresses this or a similar use case.
Is this something achievable through Kibana OOTB? Appreciate any input you can provide based on similar use cases.
I don't follow this terminology.
Is it multiple IdPs? Or is each tentant configured to use different SP within the same IdP?
Talking about "SAML certs" as a tenant differentiator doesn't quite make sense to me. Certs are an implementation detail between IdPs and SP - in order to be able to answer your question precisely, I need to understand the logical configuration of your environment in terms of IdPs and SPs.
There is only one IdP at the moment. Each tenant in the IdP has its own client configuration that has a tenant specific certificate (creating a new tenant includes creating a client configuration in the IdP that would add the same Kibana ACS, so a single SP but with different Spaces). Each tenant will also have different SAML metadata configuration (ex: the POSTBind URL) for the clients.
My use case is to select an IdP configuration based on the Space URL used to access Kibana. This is one SP one IdP scenario however, from SP's point of view it could be different SAML IdPs per tenant.
To extend (or maybe isolate) the problem more, I see that 7.2 release has OIDC support. I would like to use OIDC instead of SAML for auth/auth however, a similar issue happens in that story too. Different tenants have different client_id:client_secret pairs to do oauth. Selecting which credentials to use need to happen based on the URL segment, which should be done at the SP since all request flows are SP initiated ones.
Thanks very much for your interest in Elasticsearch.
Please be patient in waiting for responses to your question and refrain from pinging multiple times asking for a response or opening multiple topics for the same question. This is a community forum, it may take time for someone to reply to your question. For more information please refer to the Community Code of Conduct specifically the section "Be patient".
To your question now:
We'd need you to try and explain your requirements in more detail as I still can't follow some of your terminology.
You talk about multi-tenancy. Is that on the IDP side or on the Elastic Stack side ? You say:
There is only one IdP at the moment. Each tenant in the IdP
What is a "tenant" for you ? Are we talking about multiple IdPs or one ?
Creating a new tenant includes creating a client configuration in the IdP that would add the same Kibana ACS, so a single SP but with different Spaces
I'm struggling to understand what "creating a new tenant" means. Is it registering a new SAML Service Provider with your IDP ? Or is it creating a new IDP instance and configuring it to trust a new Service Provider ?
Same Kibana ACS URL and also same Service Provider EntityID ?
When you say "different Spaces", you mean Kibana Spaces? if so, can you elaborate a little on what you want to achieve ?
Each tenant will also have different SAML metadata configuration (ex: the POSTBind URL) for the clients.
Each tenant where ? Do you mean that each tenant ( in your IDP ) will be its own IDP instance ? with its own EntityID and endpoints? What is the POSTBind URL? ( this is not standard SAML terminology )
My use case is to select an IdP configuration based on the Space URL used to access Kibana. This is one SP one IdP scenario however, from SP's point of view it could be different SAML IdPs per tenant.
Apologies, but I still fail to understand this. Do you want to have SP initiated SSO from Kibana ?
If so, do you want to do something like the following:
Try to access a URL in Kibana.
Get redirected to the appropriate IDP login URL based on the Kibana Space spaceID that was part of the URL you tried to access
Login to your IDP and get redirected back to Kibana
Elastic stack validates the SAML Response using the information ( certificates, Issuer etc ) of the IDP that was selected based in the kibana Space's Id
This is unfortunately not supported. We have no way of supporting a SAML Discovery Service ( what is what you want in step 2 above ). You might be able to use IDP initiated SSO flows for your use case, but I'd like to understand more about what you want to do before I can suggest something
The client_id:client_secret pairs are assigned to the Relying Party ( i.e. the Elastic Stack ), not your OP, so I can't understand how "Different tenants have different client_id:client_secret pairs" . From the SAML post above, I got the impression that "tenants" are instances of your OP .
Selecting which credentials to use need to happen based on the URL segment, which should be done at the SP since all request flows are SP initiated ones.
Again, we do not offer such a discovery service at this time.
Apologies if my explanation was unclear. I can see even myself struggling with some parts of the problem, and it's most likely that I'm approaching this in the wrong way. However, I think you have managed to untangle it.
If so, do you want to do something like the following:
Try to access a URL in Kibana.
Get redirected to the appropriate IDP login URL based on the Kibana Space spaceID that was part of the URL you tried to access
Login to your IDP and get redirected back to Kibana
Elastic stack validates the SAML Response using the information ( certificates, Issuer etc ) of the IDP that was selected based in the kibana Space's Id
This is unfortunately not supported. We have no way of supporting a SAML Discovery Service ( what is what you want in step 2 above ). You might be able to use IDP initiated SSO flows for your use case
If I understand both the use case and your answer correctly, this was the answer I was looking for. I will start researching for another way.
On a more meta note, my apologies if my earlier replies came off as being impatient. My intention was to explain the use cases I had in mind. Appreciate the community effort being done here, however (please correct me if I'm wrong) I don't think I've put in too many pings or opened multiple threads on the same topic, as this was the first topic initiated by me, ever
Apologies if that came out harsh, it's a standard reply we use to set expectations and ground rules, nothing more
At some point we might look into supporting similar use cases by adding support for a SAML Discovery Service in order to allow the use of multiple IDPs for the same Kibana instance ( primarily for the use case of a SAML Identity federation ). This would probably also cater for your use case. Truth is there hasn't been enough interest for something like that so far.
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.
