Kibana OAuth 2 flow

Hello,

I'm trying to figure out if my understanding of the implementation of OAuth2 in Kibana is correct. I've got an ES domain deployed on AWS with Cognito authentication via "Authorization code grant" flow.

My understanding of the flow is this:

  1. Browser requests https://kibana.url/_plugin/kibana
  2. Gets redirected to https://cognito.url/login?type=code&state=XXX&redirect_uri=https://kibana.url/_plugin/kibana
  3. User logs in to Cognito and gets redirected to https://kibana.url/_plugin/kibana/app/kibana/code=YYY&state=XXX
  4. Behind the scenes Kibana makes a post request to https://cognito.url/oauth2/token sending the code and getting back an access token (+refresh token) which is then used to access ES?

The last step is totally unclear to me. Not sure if this request is done by JS code running on client browser (which gets downloaded following the redirect in step 3) OR whether this request is done by Kibana Server on a separate channel.

Is there someplace where I can read more about this? I've looked in the OAuth 2.0 RFC but I don't know how Kibana decided to implement this RFC.

Welcome to our community! :smiley:

Is this the aws service, or your own cluster on ec2?

Hello,

Thank you for your reply. This is AWS stack but the problem I’m facing is the last step of the OAuth flow for Code Grant. In this step, the Cognito code is returned to Kibana alongside the state parameter and instead of getting a 200 I’m getting 302 and being redirected back to Cognito login again.

So I’m wondering whether Kibana should be exchanging this code for an access token behind the scenes in this very last step and why this could be failing for me.

I must mention that all interaction to Kibana is done via a Nginx proxy and the Cognito authentication seems fine.

@walkom's question was whether you are using the AWS product that they call "AWS Elasticsearch Service" or if you are running self-managed Elasticsearch on EC2.

The AWS ES service uses a different OAuth2 implementation, so it is impossible to answer your question without knowing which product you are using.

Hello, apologies, yes this is an Amazon managed ES deployment, called “AWS Elastic Search Service”, not something I manually installed on an EC2 instance. I wish there was some way I could read Kibana logs but I suppose that just gets traded off when you choose AWS managed solutions,

Ok in that case you will need to ask their support, as they run a fork of our product that we cannot provide support for sorry.

Right, but isn’t Kibana one of the components involved in implementing this flow? My question was specifically for Kibana’s behaviour in the last step of the OAuth flow. Does this depend on whether it’s their stack or yours given that this is spec-ed in a RFC (so the steps are clear however there is some leeway in how you decide to implement some of them).

It is disheartening to take a look on these forums and even on AWS and find a lot of people reporting issues with this. On AWS there will be no one bothering to answer the question and on here all you’ll ever get is “it’s not our stack” even though it is your product.

I do apologise for the tone here but 5 days of trying to figure out what should otherwise be a seamless integration is not cool. In all honesty, given this issue I am confronted with, how and why would a self managed deployment of ES be less hurdle to get right?

As I mentioned it's a fork, so they make unknown changes to the product to make it run on their platform.

I appreciate your frustrations, perhaps Tim can provide some more insight.

Not really.

AWS ES's implementation of OAuth/OpenIdConnect was written entirely separately and doesn't use any of Elastic's security code. We simply don't know how it works, and can't offer you any guidance on how to solve it.

Their code runs within (their fork of) Kibana, but that doesn't give us the necessary insights into how their implementation works or why it might go wrong.
I wish we could help you, but there is no one within Elastic who has the necessary expertise to debug the AWS ES implementation of OAuth.

On AWS there will be no one bothering to answer the question

We can't speak to the AWS forums. We work very hard to provide answers to questions on these forums, as well as providing options for paid support with official SLAs. But there are limits to what we can do when we're dealing with other people's products.

and on here all you’ll ever get is “it’s not our stack” even though it is your product.

As @walkom has said, the AWS ES service runs a forked version of our product. At that point it is no longer our product.

A lot of the time the difference is minor and we're able to provide helpful answers - in fact for most topics on this forum we don't ask or care whether its our service or not, if it's a question about the base product then we do our best to answer it.

But when it comes to features like security, where AWS have their own implementation that does not use our security code, there's simply no way for us to help.
It's AWS's implementation and they're the ones taking your money (none of the $ you spend on AWS ES goes to us). At some point our only option is to recommend that you to ask your questions over there.

As I mentioned above, we take our support seriously. We try hard to offer help in the forums and we also offer paid support channels. If you are running our product and have an issue we will try very hard to help you solve it. We just can't do that for other people's products.

If you're interested in a supported, hosted Elasticsearch service, we offer that. And we think our service has a lot to offer.

3 Likes

Hello Tim V,

Thanks for providing more details on this issue.

To be honest I do feel passed around from AWS to Elastic Search support. The Cognito team is saying their product is Cognito and can't help in ES/Kibana matters (their words not mine) and on this forum I'm sent back to them with the assumption they're running a fork of the product.

The OAuth flow, as described in the RFC has multiple actors. Yes, the Authorization server is an AWS owned component (i.e. Cognito), but the Client part of it is Kibana JS code. While there is a possibility that this code was changed during their fork of ES, wouldn't it be worthwhile knowing how the original Kibana code handles this last step of the auth flow?

I'm mostly interested if the request for an access token is done by backend Kibana API code or client JS code from within the browser. In the second case it would mean such a request goes through my proxy and this might be why it's breaking.

If you have two AWS products (Cognito & AWS ES Service) that aren't working together, I simply do not understand why AWS would be passing you back here. You're paying them money, you should expect more from them than that.

There is more than the possibility - it is a completely different implementation. I could walk you through how Elastic's implementation works, but it wouldn't help you at all because AWS have their own implementation of this.

I understand that this is frustrating for you, but the problem here is that you can't get AWS Cognito to work with AWS ES Service, and from what you're telling us, it seems AWS doesn't care.

We care, but we simply can't help you because we don't know the answers. I have not seen AWS's OAuth code. We didn't write it, we cannot tell you how it works.
If you were running our distribution, or using our cloud service then we would be able to work with you to resolve this, but it's simply impossible for us to support other people's forks of our products when they're running code we haven't seen.

7 Likes

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.