Return-Path: X-Original-To: apmail-falcon-dev-archive@minotaur.apache.org Delivered-To: apmail-falcon-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7B88D18F83 for ; Wed, 22 Jul 2015 18:44:24 +0000 (UTC) Received: (qmail 81328 invoked by uid 500); 22 Jul 2015 18:44:08 -0000 Delivered-To: apmail-falcon-dev-archive@falcon.apache.org Received: (qmail 81288 invoked by uid 500); 22 Jul 2015 18:44:08 -0000 Mailing-List: contact dev-help@falcon.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@falcon.apache.org Delivered-To: mailing list dev@falcon.apache.org Received: (qmail 81268 invoked by uid 99); 22 Jul 2015 18:44:08 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Jul 2015 18:44:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 0730518C0C0 for ; Wed, 22 Jul 2015 18:44:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.97 X-Spam-Level: X-Spam-Status: No, score=0.97 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id Ry04zNcgrdIO for ; Wed, 22 Jul 2015 18:44:06 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with SMTP id C312720F19 for ; Wed, 22 Jul 2015 18:44:05 +0000 (UTC) Received: (qmail 79497 invoked by uid 99); 22 Jul 2015 18:44:05 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Jul 2015 18:44:05 +0000 Date: Wed, 22 Jul 2015 18:44:04 +0000 (UTC) From: "Sowmya Ramesh (JIRA)" To: dev@falcon.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (FALCON-1027) Falcon REST API trusted proxy support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/FALCON-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sowmya Ramesh updated FALCON-1027: ---------------------------------- Description: In order for Falcon REST API to work securely via the Knox gateway it must be possible to setup a trust relationship between Knox and Falcon. This is commonly done in other Hadoop ecosystem components using a combination of Kerberos/SPNego and a doas URL query parameter. This provides a mechanism for Falcon to strongly authenticate Knox as a trusted proxy, ensuring that it can trust the identity assertions made via the doas query parameter. The links below provide some information describing how this is done for core Hadoop. Also note that most components utilize Hadoop core's reusable hadoop-auth module to implement this functionality. http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Proxy_Users http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SecureMode.html#Proxy_user was: In the Dal timeframe Knox would like to be able to expose the Falcon REST API via the gateway. In order for that to work securely it must be possible to setup a trust relationship between Knox and Falcon. This is commonly done in other Hadoop ecosystem components using a combination of Kerberos/SPNego and a doas URL query parameter. This provides a mechanism for Falcon to strongly authenticate Knox as a trusted proxy, ensuring that it can trust the identity assertions made via the doas query parameter. The links below provide some information describing how this is done for core Hadoop. Also note that most components utilize Hadoop core's reusable hadoop-auth module to implement this functionality. http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Proxy_Users http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SecureMode.html#Proxy_user > Falcon REST API trusted proxy support > ------------------------------------- > > Key: FALCON-1027 > URL: https://issues.apache.org/jira/browse/FALCON-1027 > Project: Falcon > Issue Type: Bug > Affects Versions: 0.6 > Reporter: kenneth ho > Assignee: Sowmya Ramesh > > In order for Falcon REST API to work securely via the Knox gateway it must be possible to setup a trust relationship between Knox and Falcon. This is commonly done in other Hadoop ecosystem components using a combination of Kerberos/SPNego and a doas URL query parameter. This provides a mechanism for Falcon to strongly authenticate Knox as a trusted proxy, ensuring that it can trust the identity assertions made via the doas query parameter. The links below provide some information describing how this is done for core Hadoop. Also note that most components utilize Hadoop core's reusable hadoop-auth module to implement this functionality. > http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Proxy_Users > http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SecureMode.html#Proxy_user -- This message was sent by Atlassian JIRA (v6.3.4#6332)