Proposal: HTTPS Requirement about extensions-api HOT 5 CLOSED

Great demo today! Very excited to see what's to come with extensions.

TL;DR - I think the options for https requirement and disallowing of redirects should be managed on and extention-by-extension basis as part of the TREX config. The ability to enforce these rules are great, but should be optional. Perhaps have them default as you suggest, but allow overrides in config. Or if that's not possible, maybe you could make it a Global server config option.

We have lots of plans for extensions where I work but it seems like some of these options favor security over flexibility. In one use case, I would want to implement extensions on a small intranet where SSL isn't part of the current environment. (Yes, I wish everything was SSL but it's not always my call) In other cases I would absolutely want to enforce the above rules such as in internet environments facing clients.

As for redirects, I see that as less of an issue - especially with allowing oAuth in a dialogue, but I'd still love to have the flexibility if the need arose.

Thanks again!

from extensions-api.

Disabling redirects would drop support for systems using SAML.

from extensions-api.

What makes you assume tableau server being connected directly to the internet or even to the intranet?

Bad idea without any advantages for us. Suggest you leave the implementation of https/redirection to your clients and focus on your API.

Our load balancers take care of ssl. We are running multiple domains. Our tableau server is unreachable without load balancer. I don't want to configure all the certificate stuff in tableau server and I fear that your restrictions will require a lot of (unecessary) work or end up being incompatible with our setup. Disabling redirects is the same.

For other clients it may be interesting but please give us the freedom to opt-out in the server config.

from extensions-api.

Hi all, ( @sharif-zakhary @austinderrick @rulrich1 )
Thank you so much for the feedback. The main thing we're hearing is that restricting redirects will limit flexibility and prevent SAML authentication. Due to that, we have a new proposal that we think we provide admins with the correct amount of security but also allow flexibility for redirects.
We have a meeting with our security team this afternoon to review that proposal. Pending that meeting, we will present our new proposal tomorrow (Wed) at our Spring Demos. I will also create a new issue with the proposal and will link to it when I have that up.

We also hear that forcing https could cause some deployment issues and perhaps isn't necessary for internal deployments of Server. The challenge is that, based on our conversations with various admins, we need to at least start with the default of forcing https. Allowing admins to turn that restriction off is a pretty good idea, but it might actually be a decent amount of work for us so we plan on adding it to our backlog and think it's unlikely that we will ship our first version of Extensions with that ability.

If any of you three (or anyone else) would be up for talking about the deployment scenarios of Extensions, please email me at mkovner at tableau.

from extensions-api.

Here is the new proposal
Summary: Redirects allowed but the api will only communicate with pages from the origin registered in the extension manifest.

I am closing this proposal, because of the opening of the new proposal. We are looking forward to more productive conversation on that issue.

from extensions-api.