[
https://issues.apache.org/jira/browse/OOZIE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158913#comment-13158913
]
[email protected] commented on OOZIE-77:
----------------------------------------------------
bq. On 2011-11-24 01:42:37, Angelo K. Huang wrote:
bq. > /trunk/docs/src/site/twiki/DG_CommandLineTool.twiki, line 92
bq. > <https://reviews.apache.org/r/2875/diff/2/?file=59629#file59629line92>
bq. >
bq. > We should let user decide what kind of auth he/she wants to use. Ex.
bq. >
bq. > -auth simple
bq. > -auth kerberos
bq.
bq. Alejandro Abdelnur wrote:
bq. The client does not decide the authentication of the server.
bq.
bq. For example, out of the box the client handles both kerberos and
simple and it will do what the server responds.
bq.
bq. If you see the KerberosAuthenticator implementation delegates to the
SimpleAuthenticator.
bq.
bq. If you have a custom mechanism you could do the same, delegating to
KerberosAuthenticator which in turn will delegate to SimpleAuthenticator.
bq.
bq.
Actually, there is one case which could be tricky to implement. If I want to
implement one password authenticator which allow users type their unix
password, according to what you described above, this authenticator has to
delegate to kerberos authenticator. That means a user has to always type
password first and then fall back to kerberos even he/she intents to use
kerberos in the beginning. What if the password auth also allows users to
retype three times? If a user intents to use kerberos, he/she has to type three
times of wrong password to make it failed and then fall back to kerberos.
- Angelo K.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2875/#review3498
-----------------------------------------------------------
On 2011-11-24 16:45:59, Alejandro Abdelnur wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/2875/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-11-24 16:45:59)
bq.
bq.
bq. Review request for oozie.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. Using hadoop-auth (Alfredo) 0.23.0.
bq.
bq. Currently using SNAPSHOT because 0.23.0 artifacts have not be published to
Apache Maven repo yet.
bq.
bq.
bq. This addresses bug OOZIE-77.
bq. https://issues.apache.org/jira/browse/OOZIE-77
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. /trunk/client/pom.xml 1205923
bq. /trunk/client/src/main/bin/oozie 1205923
bq. /trunk/client/src/main/java/org/apache/oozie/cli/OozieCLI.java 1205923
bq. /trunk/client/src/main/java/org/apache/oozie/client/AuthOozieClient.java
PRE-CREATION
bq. /trunk/core/pom.xml 1205923
bq. /trunk/core/src/main/conf/oozie-log4j.properties 1205923
bq. /trunk/core/src/main/conf/oozie-site.xml 1205923
bq. /trunk/core/src/main/java/org/apache/oozie/servlet/AuthFilter.java
PRE-CREATION
bq. /trunk/core/src/main/resources/oozie-default.xml 1205923
bq.
/trunk/core/src/test/java/org/apache/oozie/servlet/DagServletTestCase.java
1205923
bq.
/trunk/core/src/test/java/org/apache/oozie/servlet/TestAuthFilterAuthOozieClient.java
PRE-CREATION
bq. /trunk/docs/src/site/twiki/AG_Install.twiki 1205923
bq. /trunk/docs/src/site/twiki/DG_CommandLineTool.twiki 1205923
bq. /trunk/pom.xml 1205923
bq. /trunk/webapp/pom.xml 1205923
bq. /trunk/webapp/src/main/webapp/WEB-INF/web.xml 1205923
bq.
bq. Diff: https://reviews.apache.org/r/2875/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq.
bq. Thanks,
bq.
bq. Alejandro
bq.
bq.
> Oozie should support Kerberos authentication on its HTTP REST API
> -----------------------------------------------------------------
>
> Key: OOZIE-77
> URL: https://issues.apache.org/jira/browse/OOZIE-77
> Project: Oozie
> Issue Type: Bug
> Reporter: Hadoop QA
> Assignee: Roman Shaposhnik
>
> Original Issue: GH-35
> The correct way of doing this would be using an SPNEGO filter on the server
> side.
> Ideally authentication should be plugglable, allowing support for cookie
> based auth, certs, etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
