[
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
