Page History

...

Form-based Authentication with the KnoxSSO application - knoxauth.

Tutorial

This paper illustrates the use of Okta’s SSO with SAML option for an existing Hadoop ecosystem application called Apache Ambari. The following figure shows how Ambari only ever needs to be aware of KnoxSSO. The underlying authentication mechanism is isolated from the participating application. In this case, KnoxSSO negotiates an authentication with Okta via the SAML 2 protocol.

Image Removed

Note that the above figure includes 3.b for Hadoop UIs. This option is not covered in this paper and requires each of the UIs to be configured properly for SSO as well. Again, each of them only need to be configured for KnoxSSO and the underlying authentication mechanism is isolated from them.

The knoxauth application depends on the ShiroProvider and its LDAP/AD integration for authenticating HTTP Basic Auth credentials. It also requires certain configuration settings on the ShiroProvider that are not normally used for Shiro. We will cover those in detail in the sections that follow.

As always with KnoxSSO, participating applications need only ever configure the URL to the KnoxSSO/websso endpoint - ie. https://gatewayhost:8443/gateway/knoxsso/api/v1/websso. The ShiroProvider needs to be configured to redirect an incoming request with no Authorization header to the URL configured for the redirectToUrl provider param. This will be the relative url to the knoxauth application within the knoxsso topology - /gateway/knoxsso/knoxauth/login.html. Again, this URL is hidden from the configuration of the participating applications in order to simplify changes from one IDP to another without having to change the world. The out-of-box knoxsso.xml topology is already configured for this redirect and other nuances required for the KnoxSSO Default IDP.

Tutorial

Prerequisites

Follow the Ambari Vagrant Quick Start guide (https://cwiki.apache.org/confluence/display/AMBARI/Quick+Start+Guide) to create a three node cluster with Centos 6.4 using Ambari 2.2 4 (trunk) or greater
Unzip the Apache Knox v0.9.0 release candidate to the {AMBARI_VAGRANT_HOME}/centos-6centos6.4 directory which is a shared volume inside the vagrant machine /vagrant
vagrant ssh into c6401
Stop the Apache Knox instance that is already running (if there is one)
Deploy the The knoxsso.xml topology file from the doc into your local knox instance. You can do this by copying the contents of the sample knoxsso.xml in this document into a new should be deployed by default and can be found at {GATEWAY_HOME}/conf/topologies/knoxsso.xml file. The LDAP/AD configuration will need to be changed to match your deployment scenario. By default it is configured for the Knox Demo LDAP server - just as sandbox.xml is.
Change the knoxsso.cookie.secure.only param in knoxsso.xml to false. Ambari does not have SSL enabled by default and if we set the cookie to secure only it will not be presented to Ambari by the browser. NOTE: THIS IS INSECURE AND ONLY USED FOR TESTING
Change the knoxsso.token.ttl parameter to something like 30 secs (30000) - the default value of -1 will not work with Ambari until
Jira
server ASF JIRA
serverId 5aa69414-a9e9-3523-82ec-879b028fb15b
key AMBARI-15479
is resolved.
Start your v0.9.0 version of Knox via: /usr/jdk64/jdk1.8.0_60/bin/java -jar {GATEWAY_HOME}/bin/gateway.jarsh start - ensure that you are using Java 7 or 8 by exporting JAVA_HOME appropriately
Configure Ambari for SSO with KnoxSSO through the SSO Wizard via the ambari-server CLI

Get the gateway-identity public key from Apache Knox {GATEWAY_HOME}/data/security/keystores/gateway.jks via keytool or portecle (see Extracting Knox Public Key for SAML section for details)
Get the SSO provider URL for the KnoxSSO websso endpoint
su to root {pw: vagrant}
start the sso wizard:

[root@c6401 knox-0.89.0]# ambari-server setup-sso

...

Restart Ambari server:

[root@c6401 knox-0.89.0]# ambari-server restart

...

The following will use keytool and openssl to first extract a der encoded cert and then to convert DER to PEM encoding:

 [vagrant@c6401 knox-0.89.0]$ keytool -export -keystore data/security/keystores/gateway.jks -alias gateway-identity -file gateway.cer

...

Now convert the cer file into pem encoding via openssl:

[vagrant@c6401 knox-0.89.0]$ openssl x509 -inform der -in gateway.cer -out gateway.pem

...

1. Open Apache Ambari in a broser at http://c6401.ambari.apache.org:8080 - you will initially be presented the Ambari login page but quickly redirected to the Okta KnoxSSO login.

Image Modified

Image Added

Image Removed

2. When presented with a login form, fill it out with these credentials (guest/Gu3stp@asswordguest-password) and submit it to the Okta serverKnoxSSO. This will result in a SAML protocol HTTP Basic Auth credentials POST to the callback URL for KnoxSSO/websso endpoint. The SAML assertion credentials will be processed verified against the configured LDAP/AD identity store via the pac4j shiro provider and the authenticated identity normalized into a Java Subject. The successful authentication continues the processing through the provider 's chain and the identity assertion provider must may use appropriate principal mapping to establish the effective username. The effective username is what the KnoxSSO service will put into the JWT token to be presented as a Cookie to all participating applications.

Image Removed

4. After a brief signing in "Loading..." page you should be redirected back to Ambari. If you are interested you may find the hadoop-jwt cookie using Chrome’s developer tools - since the cookie is configured to not be secure only. It should be a session cookie set as HttpOnly and (normally) Secure. The service parameter knoxsso.cookie.secure.only for the KnoxSSO service in the knoxsso.xml topology controls the secure only setting of the cookie.

...

The knoxsso.xml topology describes the manner in which a client acquires a KnoxSSO websso cookie/token. The pac4j federation provider allows the integration of a number of authentication solutions. In this case, the openid connect capability is being leveraged to integration the cloud based Privakey identity service.

<topology>

    <gateway>

      <provider>

          <role>federation</role>

          <name>pac4j</name>

          <enabled>true</enabled>

          <param>

            <name>pac4j.callbackUrl</name>

            <value>https://c6401.ambari.apache.org:8443/gateway/knoxsso/api/v1/websso</value>

          </param>

          <param>

            <name>clientName</name>

            <value>SAML2Client</value>

          </param>

          <param>

            <name>saml.identityProviderMetadataPath</name>

            <value>https://dev-122415.oktapreview.com/app/exk5quib9pnb5hW5S0h7/sso/saml/metadata</value>

          </param>

          <param>

            <name>saml.serviceProviderEntityId</name>

            <value>https://c6401.ambari.apache.org:8443/gateway/knoxsso/api/v1/websso?pac4jCallback=true&amp;client_name=SAML2Client</value>

          </param>

      </provider>

      <provider>

          <role>identity-assertion</role>

          <name>Default</name>

          <enabled>true</enabled>

          <param>

            <name>principal.mapping</name>

            <value>guest@example.com=guest;</value>

          </param>

      </provider>

    </gateway>

    <service>

        <role>KNOXSSO</role>

        <param>

          <name>knoxsso.cookie.secure.only</name>

          <value>false</value>

       </param>

       <param>

         <name>knoxsso.token.ttl</name>

         <value>100000</value>

       </param>

       <param>

          <name>knoxsso.redirect.whitelist.regex</name>

<role>webappsec</role>

<name>WebAppSec</name>

<param>

<name>xframe.options.enabled</name>

<value>true</value>

</param>

</provider>

<role>authentication</role>

<name>ShiroProvider</name>

<param>

<name>sessionTimeout</name>

</param>

<param>

<name>redirectToUrl</name>

<value>/gateway/knoxsso/knoxauth/login.html</value>

</param>

<param>

<name>restrictedCookies</name>

<value>rememberme,WWW-Authenticate</value>

</param>

<param>

<name>main.ldapRealm</name>

<value>org.apache.hadoop.gateway.shirorealm.KnoxLdapRealm</value>

</param>

<param>

<name>main.ldapContextFactory</name>

<value>org.apache.hadoop.gateway.shirorealm.KnoxLdapContextFactory</value>

</param>

<param>

<name>main.ldapRealm.contextFactory</name>

<value>$ldapContextFactory</value>

</param>

<param>

<name>main.ldapRealm.userDnTemplate</name>

<value>uid={0},ou=people,dc=hadoop,dc=apache,dc=org</value>

</param>

<param>

<name>main.ldapRealm.contextFactory.url</name>

<value>ldap://localhost:33389</value>

</param>

<param>

<name>main.ldapRealm.authenticationCachingEnabled</name>

<value>false</value>

</param>

<param>

<name>main.ldapRealm.contextFactory.authenticationMechanism</name>

<value>simple</value>

</param>

<param>

<value>authcBasic</value>

</param>

</provider>

<role>identity-assertion</role>

<name>Default</name>

</provider>

<role>hostmap</role>

<name>static</name>

<param><name>localhost</name><value>sandbox,sandbox.hortonworks.com</value></param>

</provider>

</gateway>

<application>

<name>knoxauth</name>

</application>

<role>KNOXSSO</role>

<param>

<name>knoxsso.cookie.secure.only</name>

<value>false</value>

</param>

<param>

<name>knoxsso.token.ttl</name>

<value>30000</value>

</param>

<param>

<name>knoxsso.redirect.whitelist.regex</name>

...

<value>^https?:\/\/(

localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*

...

$</

...

       </param>

value>

</param>

</service>

...

</

...

topology>

Space shortcuts

Child pages

Versions Compared

Old Version 1

New Version 2

Key

Tutorial

Tutorial

Prerequisites