This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Ambari via KnoxSSO and Default IDP

Versions Compared

Key

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

...

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

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

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

  3. vagrant ssh into c6401

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

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

  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:  /usr/jdk64/jdk1.8.0_60{GATEWAY_HOME}/bin/java -jar bin/gateway.jargateway.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: vagrant}

    4. start the sso wizard:

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

...

  1. Restart Ambari server:

[root@c6401 knox-0.89.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.89.0]$ keytool -exportexportcert -keystore data/security/keystores/gateway.jks -alias gateway-identity -rfc -file gateway.cerpem
Enter keystore password:{master secret}
Certificate stored in file <gateway.cer>
Now convert the cer file into pem encoding via openssl:
[vagrant@c6401 knox-0.8.0]$ openssl x509 -inform der -in gateway.cer -out gateway.pem
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 Okta KnoxSSO login.

Image Modified


Image RemovedImage Added

 

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

LDAP/AD with HTTP Basic Auth credentials.


<topology>

    <gateway>

      <provider>

        <role>webappsec</role>

        <name>WebAppSec</name>

        <enabled>true</enabled>

        <param>

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

            <value>true</value>

        </param>

      </provider> 

        <provider>

            <role>authentication</role>

            <name>ShiroProvider</name>

            <enabled>true</enabled>

            <param>

                <name>sessionTimeout</name>

                <value>30</value>

            </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>

                <name>urls./**</name>

                <value>authcBasic</value>

            </param>

        </provider> 

        <provider>

            <role>identity-assertion</role>

            <name>Default</name>

            <enabled>true</enabled>

        </provider>

        <provider>

            <role>hostmap</role>

            <name>static</name>

            <enabled>true</enabled>

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

        </provider>

    </gateway>

 

    <application>

      <name>knoxauth</name>

    </application>

 

    <service>

        <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?:\/\/(c64\d\d\.ambari\.apache\.org|localhost|127\.0\.0\.1|0:0:0:0:0:0:0:1|::1):[0-9].*

...

$</

...

       </param>

...

value>

        </param>

    </service>

</

...

topology>