Knox SSO redirects contain the EC2 host's private IP (obviously not working in browser)

[lhoss]

@abajwa-hw this issue is about your fork (latest master from today), which does not allow to create issues

---

In short: Unless we missed something in the Setup Doc, we assume this might be a/the bug, that the
(SSOCookieProvider) sso.authentication.provider.url setting is using the Knox host's private IP.

We deployed the hortoniabank demo on AWS, trying 2 different strategies:

• "Option 1" (today) using 'setup.sh' on an official AWS centos-7.5 ami
• "Option 2" (yesterday) using the "HDP 3.0 without NiFi or Knox SSO" AMI

Both setups worked well..
by following the steps as documented (the latest version, recently updated! ):
https://community.hortonworks.com/articles/151939/hdp-securitygovernance-demo-kit.html

11. For Knox SSO, you will need to create a entry for demo.hortonworks.com (pointing to the Public IP from above) in your local laptop's hosts file.
12. After 5-10 minutes, open the below URL in your browser to access Ambari’s console:
    If you selected an AMI that has Knox SSO, use either Firefox or Incognito Chome window to navigate to http://demo.hortonworks.com:8080 where you will be shown the Knox sign-on login page. Enter user:admin password:BadPass#1

• We did that (adding the entry to /etc/hosts)

• Then going to http://demo.hortonworks.com:8080 in Google Chrome (Incognito Mode), it redirects too (I masked the IPs with xxx strings):
  https://ip-172-31-xxx-xxx.us-west-1.compute.internal:8443/gateway/knoxsso/api/v1/websso?originalUrl=http%3A%2F%2Fdemo.hortonworks.com%3A8080%2F%23%2Flogin?redirected=true

• After manually replacing the internal IP, it works:
  https://demo.hortonworks.com:8443/gateway/knoxsso/api/v1/websso?originalUrl=http%3A%2F%2Fdemo.hortonworks.com%3A8080%2F%23%2Flogin?redirected=true

• The same issue, entering the Zeppelin UI: https://demo.hortonworks.com:8443/gateway/ui/zeppelin/
  that redirects again too https://ip-172-31-xxx-xxx.us-west-1.compute.internal:8443/...

• and again, here's a manually fixed working URL to Knox'ed Zeppelin:
  https://demo.hortonworks.com:8443/gateway/knoxsso/api/v1/webssogateway/knoxsso/knoxauth/login.html?originalUrl=https://demo.hortonworks.com:8443/gateway/ui/zeppelin/

Still new to this demo, and also Knox in general, I'm wondering if it's good idea to use the hostname cmd� (which indeed returns the private network IP) to set the "knox_sso_url" in:
https://github.com/abajwa-hw/masterclass/blob/master/ranger-atlas/HortoniaMunichSetup/10-SSOSetup.sh#L82

hostname=$(hostname -f)
knox_sso_url="https://$hostname:8443/gateway/knoxsso/api/v1/websso"

Finally in the Knox UI I found following setting, which AFAIU is used to generate the redirect URLs,
but trying to change it to use the public IP did not succeed
(when hitting save button, I get redirected to the Knox login, and after login in the config is still the old one. It seems the 'save' request was redirected, and so did not complete)

• knox UI URL: https://demo.hortonworks.com:8443/gateway/manager/admin-ui
  In Knox UI, Menu "Provider Configs"/cookieprovider/federation/params
  Try changing "sso.authentication.provider.url"
  FROM: https://ip-172-31-xxx-xxx.us-west-1.compute.internal:8443/gateway/knoxsso/api/v1/websso
  TO: https://ec2-54-x-x-x.us-west-1.compute.amazonaws.com:8443/gateway/knoxsso/api/v1/websso

We really want to understand if we missed something, or the Doc. is incomplete
or if this is even expected .. but then you would also need the browser to be able to handle the private (AWS) IP, for ex. by using Socks Proxy tricks etc

[abajwa-hw]

@lhoss thanks for your detailed note. This is the first time we've added Knox SSO feature so am sure there are improvements we can make (esp when deploying on public cloud). Could we discuss over webex? Would you mind emailing me at abajwa@hortonworks.com with some open slots this week? Am based in Pacific timezone

[lhoss]

thx @abajwa-hw for your quick reply (and I will soon contact you by mail, also about other ideas we have, like if it's possible to better separate the demo setup from the pure HDP/HDF installation, which we prefer todo using ansible and the great role https://github.com/hortonworks/ansible-hortonworks !)

---

About the issue here:
After studying some Knox Docs, the proper solution quickly jumped into our eyes:
Adding a Hostmap provider as shown in this example, which is exactly our use-case !:

• https://knox.apache.org/books/knox-1-1-0/user-guide.html#Hostmap+Provider+Example+-+EC2
• or p25 in https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.0.0/configuring-proxy-knox/sec_configuring_proxy_knox.pdf

[lhoss]

We started adding a static hostmap provider (we did several trials, adding to multiple topologies including topologies ui, admin) but it still did not work as expected:
After entering the user/pass in Knox, it redirects to the UI, p.eg. YARN UI, but quickly again back to Knox (as if the auth. did not fully work)
Also with Zeppelin, it still redirected to a private IP URL, until we fixed following (then Zeppelin has the same problem then described just before)

• Zeppelin config fix (done in Ambari)
  Section: Advanced "Zeppelin-shiro-ini " following param needs to use the public-IP in setting:

knoxJwtRealm.providerUrl = https://ec2-xxx-xxx-xxx-xxx.us-west-1.compute.amazonaws.com:8443/gateway/knoxsso/api/v1/websso

• Source code reference:
  https://github.com/abajwa-hw/masterclass/blob/master/ranger-atlas/HortoniaMunichSetup/12-enable-zeppelin_SSO.sh#L22

[lhoss]

We got it working, incl. following gateway'ed URLs:
https://demo.hortonworks.com:8443/gateway/ui/zeppelin/
https://demo.hortonworks.com:8443/gateway/ui/ambari
https://demo.hortonworks.com:8443/gateway/ui/ranger
https://demo.hortonworks.com:8443/gateway/ui/atlas
https://demo.hortonworks.com:8443/gateway/ui/yarnuiv2
FAILS: https://demo.hortonworks.com:8443/gateway/ui/yarn
( with http 400, not sure why .. but not a big issue)

after having applied following patches: https://github.com/jnowakowski/masterclass/commits/patch-1
In short, in the provider/SSO related configs we used demo.hortonworks.com as hostname (instead of the former private-IP. ps: We also tried the public-IP, which wasn't working, due to endless redirect to KnoxSSO login.. )
Note: This is without using any static hostmap providers, which I'ld have expected to be the clean solution (but could not figure the exact combination where to configure static hostmaps and where to use internal vs public hostnames)