This repository has been archived by the owner. It is now read-only.

[3.0] Gh 0035 Oozie authentication module #330

wants to merge 4 commits into


None yet
1 participant

angeloh commented Jan 7, 2011

GH-35 Oozie authentication module


angeloh commented on 095ca96 Jan 25, 2011

Thanks for the write-up. I have a couple of questions:

  • would it be more practicable if supports() returns the auth token right away? and null if it is not supported? I seems that getAuthenticationToken would have do a lot of the same things as supports() such as checking for existence of some header field etc.
  • how does the server authenticate if there are multiple providers? Say the first provider's support() returns true, but then authenticate() fails. Will the server reject the request, or will it try the remaining providers?
  • how are authentication providers initialized by the server? A provider should only be created once statically, and not for every request that comes in. If that static instance requires some configuration, how is that provided?

Thanks -Andreas.


angeloh replied Jan 25, 2011

The write makes things more clear, thanks.

  • Why the user is set as a request attribute instead using an HttpServletResponseWrapper overriding the getRemoteUser() and getUserPrincipal() methods? This seems more natural.
  • How does the client side work, specification speaking? (you indicated the code will come later)
  • The posted code does not have any Javadocs (except for ~5 classes/methods), it is not possible to easily know what is the API contract.
  • There are only 2 testcases (cookie-signer and ugi-cache) and none of the authentication framework is being tested.


angeloh commented Jan 26, 2011


  1. The token is not required to be there. It can be null.
  2. It will pick only one provider and do the authenticate(). If it fails, return exception. A server could contain many providers and client's connection might hang if continue to try rest of providers.
  3. Yes, providers are created statically. The configuration can be defined in oozie-site.xml and read it within the provider. For example, you can put one configuration '' in oozie-site.xml, when this provider is instantiated by AuthenticationProviderFactory, the value can be read from the argument 'Configuration'.

angeloh commented Jan 27, 2011

Hi Tucu,

Comments for your questions:

  1. OozieAuthFilter is getting the value by calling HttpServletResponseWrapper.getUserPrincipal(). I am not sure if I answer your question correctly?
  2. wiki is created here.
    Also, it is in Oozie docs too.

3&4 are addressed in last two commits. Client code too.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.