Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. 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.4 (trunk) or greater

  2. Unzip the Apache Knox v0.9.0 release candidate to the {AMBARI_VAGRANT_HOME}/centos6.4 directory which is a shared volume inside the vagrant machine /vagrant

  3. vagrant ssh into c6401

  4. Stop the Apache Knox instance that is already running (if there is one)

  5. The knoxsso.xml topology file 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.

  6. 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

  7. Change the knoxsso.token.ttl parameter to something like 30 secs (30000) - the default value of -1 will not work with Ambari until 

    Jira
    serverASF JIRA
    serverId5aa69414-a9e9-3523-82ec-879b028fb15b
    keyAMBARI-15479
     is resolved.

  8. Ensure that the knoxsso.redirect.whitelist.regex parameter for KNOXSSO includes the c6401.ambari.apache.org host in the set of acceptable hosts. See the example at the end of this article.
  9. Start your v0.9.0 version of Knox via:  {GATEWAY_HOME}/bin/gateway.sh start - ensure that you are using Java 7 or 8 by exporting JAVA_HOME appropriately

  10. Configure Ambari for SSO with KnoxSSO through the SSO Wizard via the ambari-server CLI

    1. 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 IdP Configuration section for details)

    2. Get the SSO provider URL for the KnoxSSO websso endpoint (i.e. https://c6401.ambari.apache.org:8443/gateway/knoxsso/api/v1/websso)

    3. su to root {pw: su to root {pw: vagrant}

    4. start the sso wizard:

...

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

Extracting Knox Public Key for

...

IdP Configuration

There are multiple ways that you can do this.

The following will use keytool and openssl to first extract a der PEM encoded cert and then to convert DER to PEM encodingfrom the gateway keystore:

 [vagrant@c6401 knox-0.9.0]$ keytool -exportexportcert -keystore data/security/keystores/gateway.jks -alias gateway-identity -file gateway.cer
Enter keystore password:{master secret}
Certificate stored in file <gateway.cer>
Now convert the cer file into pem encoding via openssl:
 gateway-identity -rfc -file gateway.pem
Enter keystore password:{master secret}
Certificate stored in file <gateway.pem>[vagrant@c6401 knox-0.9.0]$ openssl x509 -inform der -in gateway.cer -out gateway.pem

 

For the Ambari SSO wizard the content between

...

To demonstrate the integration between KnoxSSO and Okta for the new Default IDP (form-based IDP) for existing KnoxSSO aware Hadoop applications, Ambari will be used. This demonstrates Ambari’s ability to acquire and validate KnoxSSO tokens/cookies as a means to authenticate to its management capabilities and custom views.

...

Once logged in through KnoxSSO the resulting hadoop-jwt cookie is used to create an Ambari session. Apache Ambari only knows that it is relying on KnoxSSO and nothing about the underlying SSO provider (in this case OktaLDAP/AD and the Default IDP).

Test Integration with

...

Default IDP


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 KnoxSSO login.

...

The knoxsso.xml topology describes the manner in which a client acquires a KnoxSSO websso cookie/token. The pac4j federation shiro 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 serviceLDAP/AD with HTTP Basic Auth credentials.


<topology>

    <gateway>

      <provider>

...

            <value>30000</value>

        </param>

        <param>

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

           <value>^https?:\/\/(c64\d\d\.ambari\.apache\.org|localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*$</value>

        </param>

    </service>

</topology>