You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Robert Kanter (JIRA)" <ji...@apache.org> on 2012/11/29 04:26:59 UTC
[jira] [Created] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Robert Kanter created OOZIE-1103:
------------------------------------
Summary: Create example using AltKerberosAuthenticationHandler
Key: OOZIE-1103
URL: https://issues.apache.org/jira/browse/OOZIE-1103
Project: Oozie
Issue Type: New Feature
Components: security
Affects Versions: trunk
Reporter: Robert Kanter
Assignee: Robert Kanter
Fix For: trunk
HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
There are two main components:
(1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
(2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
More detailed information is in the documentation in the patch.
ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Kanter updated OOZIE-1103:
---------------------------------
Attachment: OOZIE-1103.patch
The new patch fixes the 2 lines that were too long. It also disables the 2 failed tests from TestExampleAltAuthenticationHandler because instantiating ExampleAltAuthenticationHandler requires a keytab file even though these tests don't actually use it. I've double checked and the tests both work on my machine.
{code}
javax.servlet.ServletException: Keytab does not exist: /home/jenkins/oozie.keytab
{code}
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Kanter updated OOZIE-1103:
---------------------------------
Attachment: OOZIE-1103.patch
When double checking the tests before committing it, I saw that there's an issue with the dependencies causing the tests to fail. Long story short, the order of the dependencies makes a difference; so the new patch simply changes the order of the {{apacheds-server-unit}} and {{oozie-hadoop-test}} dependencies in the login pom.
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507538#comment-13507538 ]
Hadoop QA commented on OOZIE-1103:
----------------------------------
Testing JIRA OOZIE-1103
Cleaning local svn workspace
----------------------------
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
. {color:green}+1{color} the patch does not introduce any @author tags
. {color:green}+1{color} the patch does not introduce any tabs
. {color:green}+1{color} the patch does not introduce any trailing spaces
. {color:red}-1{color} the patch contains 1 line(s) longer than 132 characters
. {color:green}+1{color} the patch does adds/modifies 5 testcase(s)
{color:green}+1 RAT{color}
. {color:green}+1{color} the patch does not seem to introduce new RAT warnings
{color:green}+1 JAVADOC{color}
. {color:green}+1{color} the patch does not seem to introduce new Javadoc warnings
{color:green}+1 COMPILE{color}
. {color:green}+1{color} HEAD compiles
. {color:green}+1{color} patch compiles
. {color:green}+1{color} the patch does not seem to introduce new javac warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
. {color:green}+1{color} the patch does not change any JPA Entity/Colum/Basic/Lob/Transient annotations
. {color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
. Tests run: 925
. Tests failed: 2
. Tests errors: 0
. The patch failed the following testcases:
. testUnpauseBundleAndCoordinator(org.apache.oozie.service.TestPauseTransitService)
. testPauseBundleAndCoordinator(org.apache.oozie.service.TestPauseTransitService)
{color:green}+1 DISTRO{color}
. {color:green}+1{color} distro tarball builds with the patch
----------------------------
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/224/
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Kanter updated OOZIE-1103:
---------------------------------
Attachment: OOZIE-1103.patch
Newest patch fixes the build issue.
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506230#comment-13506230 ]
Hadoop QA commented on OOZIE-1103:
----------------------------------
Testing JIRA OOZIE-1103
Cleaning local svn workspace
----------------------------
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
. {color:green}+1{color} the patch does not introduce any @author tags
. {color:green}+1{color} the patch does not introduce any tabs
. {color:green}+1{color} the patch does not introduce any trailing spaces
. {color:red}-1{color} the patch contains 2 line(s) longer than 132 characters
. {color:green}+1{color} the patch does adds/modifies 4 testcase(s)
{color:green}+1 RAT{color}
. {color:green}+1{color} the patch does not seem to introduce new RAT warnings
{color:green}+1 JAVADOC{color}
. {color:green}+1{color} the patch does not seem to introduce new Javadoc warnings
{color:green}+1 COMPILE{color}
. {color:green}+1{color} HEAD compiles
. {color:green}+1{color} patch compiles
. {color:green}+1{color} the patch does not seem to introduce new javac warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
. {color:green}+1{color} the patch does not change any JPA Entity/Colum/Basic/Lob/Transient annotations
. {color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
. Tests run: 924
. Tests failed: 0
. Tests errors: 2
. The patch failed the following testcases:
.
{color:green}+1 DISTRO{color}
. {color:green}+1{color} distro tarball builds with the patch
----------------------------
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/210/
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Kanter updated OOZIE-1103:
---------------------------------
Attachment: OOZIE-1103.patch
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Kanter updated OOZIE-1103:
---------------------------------
Attachment: OOZIE-1103.patch
The new patch should not properly skip the two tests. The 1 lines that is too long is because of twiki formatting so it has to be that way.
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506363#comment-13506363 ]
Hadoop QA commented on OOZIE-1103:
----------------------------------
Testing JIRA OOZIE-1103
Cleaning local svn workspace
----------------------------
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
. {color:green}+1{color} the patch does not introduce any @author tags
. {color:green}+1{color} the patch does not introduce any tabs
. {color:green}+1{color} the patch does not introduce any trailing spaces
. {color:red}-1{color} the patch contains 1 line(s) longer than 132 characters
. {color:green}+1{color} the patch does adds/modifies 4 testcase(s)
{color:green}+1 RAT{color}
. {color:green}+1{color} the patch does not seem to introduce new RAT warnings
{color:green}+1 JAVADOC{color}
. {color:green}+1{color} the patch does not seem to introduce new Javadoc warnings
{color:green}+1 COMPILE{color}
. {color:green}+1{color} HEAD compiles
. {color:green}+1{color} patch compiles
. {color:green}+1{color} the patch does not seem to introduce new javac warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
. {color:green}+1{color} the patch does not change any JPA Entity/Colum/Basic/Lob/Transient annotations
. {color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
. Tests run: 924
. Tests failed: 0
. Tests errors: 2
. The patch failed the following testcases:
.
{color:green}+1 DISTRO{color}
. {color:green}+1{color} distro tarball builds with the patch
----------------------------
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/214/
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507734#comment-13507734 ]
Hadoop QA commented on OOZIE-1103:
----------------------------------
Testing JIRA OOZIE-1103
Cleaning local svn workspace
----------------------------
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
. {color:green}+1{color} the patch does not introduce any @author tags
. {color:green}+1{color} the patch does not introduce any tabs
. {color:green}+1{color} the patch does not introduce any trailing spaces
. {color:red}-1{color} the patch contains 1 line(s) longer than 132 characters
. {color:green}+1{color} the patch does adds/modifies 5 testcase(s)
{color:green}+1 RAT{color}
. {color:green}+1{color} the patch does not seem to introduce new RAT warnings
{color:green}+1 JAVADOC{color}
. {color:green}+1{color} the patch does not seem to introduce new Javadoc warnings
{color:green}+1 COMPILE{color}
. {color:green}+1{color} HEAD compiles
. {color:green}+1{color} patch compiles
. {color:green}+1{color} the patch does not seem to introduce new javac warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
. {color:green}+1{color} the patch does not change any JPA Entity/Colum/Basic/Lob/Transient annotations
. {color:green}+1{color} the patch does not modify JPA files
{color:green}+1 TESTS{color}
. Tests run: 925
{color:green}+1 DISTRO{color}
. {color:green}+1{color} distro tarball builds with the patch
----------------------------
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/225/
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Kanter updated OOZIE-1103:
---------------------------------
Attachment: OOZIE-1103.patch
The new patch addresses Alejandro's suggestions:
- Moved ExampleAltAuthenticationHandler, AltKerberosAuthenticationHandler, and associated tests to login module, which now produces a WAR and a JAR
- Removed addition to oozie-default.xml
- Updated documentation to reflect changes
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Kanter updated OOZIE-1103:
---------------------------------
Description:
HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
There are two main components:
(1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
(2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
More detailed information is in the documentation in the patch.
ExampleAltAuthenticationHandler, LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war and oozie-login.jar when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it and create a JIRA to delete it later.
was:
HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
There are two main components:
(1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
(2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
More detailed information is in the documentation in the patch.
ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler, LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war and oozie-login.jar when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Alejandro Abdelnur (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507737#comment-13507737 ]
Alejandro Abdelnur commented on OOZIE-1103:
-------------------------------------------
+1
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Alejandro Abdelnur (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506826#comment-13506826 ]
Alejandro Abdelnur commented on OOZIE-1103:
-------------------------------------------
Overall looks good, there are NIT to address, example code (ie ExampleAltAuthenticationHandler.java) should not be in CORE.
We could do the following: move all this to the login module, and make the login module to produce a JAR in addition to a WAR. The JAR would be distroed next to to the WAR and the instructions would indicate to put that JAR in the libext/ for deployment.
Also, no additions to oozie-default.xml for examples. that should be part of the docuemntation that goes into oozie-site.
Other than that looks good.
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507075#comment-13507075 ]
Hadoop QA commented on OOZIE-1103:
----------------------------------
Testing JIRA OOZIE-1103
Cleaning local svn workspace
----------------------------
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
. {color:green}+1{color} the patch does not introduce any @author tags
. {color:green}+1{color} the patch does not introduce any tabs
. {color:green}+1{color} the patch does not introduce any trailing spaces
. {color:red}-1{color} the patch contains 1 line(s) longer than 132 characters
. {color:green}+1{color} the patch does adds/modifies 5 testcase(s)
{color:green}+1 RAT{color}
. {color:green}+1{color} the patch does not seem to introduce new RAT warnings
{color:green}+1 JAVADOC{color}
. {color:green}+1{color} the patch does not seem to introduce new Javadoc warnings
{color:green}+1 COMPILE{color}
. {color:green}+1{color} HEAD compiles
. {color:green}+1{color} patch compiles
. {color:green}+1{color} the patch does not seem to introduce new javac warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
. {color:green}+1{color} the patch does not change any JPA Entity/Colum/Basic/Lob/Transient annotations
. {color:green}+1{color} the patch does not modify JPA files
{color:green}+1 TESTS{color}
. Tests run: 922
{color:red}-1 DISTRO{color}
. {color:red}-1{color} distro tarball fails with the patch
----------------------------
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/222/
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506701#comment-13506701 ]
Hadoop QA commented on OOZIE-1103:
----------------------------------
Testing JIRA OOZIE-1103
Cleaning local svn workspace
----------------------------
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
. {color:green}+1{color} the patch does not introduce any @author tags
. {color:green}+1{color} the patch does not introduce any tabs
. {color:green}+1{color} the patch does not introduce any trailing spaces
. {color:red}-1{color} the patch contains 1 line(s) longer than 132 characters
. {color:green}+1{color} the patch does adds/modifies 4 testcase(s)
{color:green}+1 RAT{color}
. {color:green}+1{color} the patch does not seem to introduce new RAT warnings
{color:green}+1 JAVADOC{color}
. {color:green}+1{color} the patch does not seem to introduce new Javadoc warnings
{color:green}+1 COMPILE{color}
. {color:green}+1{color} HEAD compiles
. {color:green}+1{color} patch compiles
. {color:green}+1{color} the patch does not seem to introduce new javac warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
. {color:green}+1{color} the patch does not change any JPA Entity/Colum/Basic/Lob/Transient annotations
. {color:green}+1{color} the patch does not modify JPA files
{color:green}+1 TESTS{color}
. Tests run: 922
{color:green}+1 DISTRO{color}
. {color:green}+1{color} distro tarball builds with the patch
----------------------------
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/oozie-trunk-precommit-build/216/
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506636#comment-13506636 ]
Robert Kanter commented on OOZIE-1103:
--------------------------------------
That should be "*now* properly skip"
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Robert Kanter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507545#comment-13507545 ]
Robert Kanter commented on OOZIE-1103:
--------------------------------------
As before, the 1 line longer than 132 characters is required by twiki formatting.
The 2 test failures seem unrelated.
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OOZIE-1103) Create example using
AltKerberosAuthenticationHandler
Posted by "Alejandro Abdelnur (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OOZIE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507591#comment-13507591 ]
Alejandro Abdelnur commented on OOZIE-1103:
-------------------------------------------
+1, nice job, this will definitely help users running a Kerberos enabled cluster who don't want to use Kerberos for browser authentication.
> Create example using AltKerberosAuthenticationHandler
> -----------------------------------------------------
>
> Key: OOZIE-1103
> URL: https://issues.apache.org/jira/browse/OOZIE-1103
> Project: Oozie
> Issue Type: New Feature
> Components: security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch, OOZIE-1103.patch
>
>
> HADOOP-9054 adds AltKerberosAuthenticationHandler which allows non-browsers to use Kerberos authentication while allowing browsers to use some alternative authentication (to be implemented by the subclass). This is particularly useful for users of Oozie who want to use Kerberos for the Oozie client but allow access to the web UI using some other means of authentication, such as LDAP. To encourage this, we should create an example implementation of AltKerberosAuthenticationHandler and a login server example to work with it. This example isn't designed to be secure, but to make it easier for users to integrate their own authentication systems with Oozie.
> There are two main components:
> (1) ExampleAltAuthenticationHanlder extends the AltKerberosAuthenticationHandler: The AltKerberosAuthenticationHandler deals with determining if the user-agent is a browser or not and with falling back to KerberosAuthenticationHandler, so all the ExampleAltAuthenticationHandler has to do is create the AuthenticationToken when it sees that the user has a cookie named "oozie.web.login.auth" in their browser (the value of the cookie is the username).
> (2) The login server example: This is where the ExampleAltAuthenticationHandler will redirect unauthenticated users to. It has two implementations, one is a very basic servlet (LoginServlet) that provides a form to get the username and password and checks if they are equal (e.g. user=foo pass=foo) and writes a cookie named "oozie.web.login.auth" with the username if so. The second implementation (LDAPLoginServlet) checks the username and password against an LDAP server before writing the cookie.
> The flow of all of this would be the user goes to the Oozie web UI in their browser, the ExampleAltAuthenticator determines that they are not authenticated so redirects them to the login server example, which authenticates the user, writes the cookie, and redirects them back to the web UI where the ExampleAltAuthenticationHandler sees from the cookie that they should now authenticated. From a non-browser, such as the Oozie client, the ExampleAltAuthenticationHandler would fall back to the KerberosAuthenticationHandler.
> More detailed information is in the documentation in the patch.
> ExampleAltAuthenticationHandler is in Oozie Core, while LoginServlet and LDAPLoginServlet are part of a new login module that builds oozie-login.war when the loginServerExample maven profile is activated (much like how the workflow generator is built). The oozie-login.war can be deployed in the same tomcat as Oozie or somewhere else. Because ExampleAltAuthenticationHandler depends on AltKerberosAuthenticationHandler, which isn't in the current Hadoop release, we can temporarily include a copy of it in Oozie Core and create a JIRA to delete it later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira