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

[3.0] Gh 0035 Oozie authentication module #330

Open
wants to merge 4 commits into
from

Conversation

Projects
None yet
1 participant

angeloh commented Jan 7, 2011

GH-35 Oozie authentication module

Owner

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.

Owner

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.

-tucu

angeloh commented Jan 26, 2011

Andreas,

  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 'oozie.auth.a.xxx' 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. https://github.com/yahoo/oozie/wiki/Oozie-Authentication-Specification
    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.