This is a requisite first step for getting to multi-user scenarios. I believe this should get discussed a little bit in terms of approach.

This is ready for review.

@rconline how would you want to discuss? Should we open a JIRA - or a JIRA parent with subtests for this multi-user auth use cases?

@prabhjyotsingh could you explain more on the reason for this change?
Also this seems like a somewhat big change - could you open a JIRA on this so it could be tracked?

@felixcheung @prabhjyotsingh The purpose of this discussion should be to get to an approach that allows us zeppelin to do a couple of things - pass user identity to the underlying spark cluster, and thereby support multi-tenancy. There is JIRA open - https://issues.apache.org/jira/browse/ZEPPELIN-645 which we could use to discuss this further. Does that make sense?

I think it make sense to let access authentication info through InterpreterContext.
But i think authentication info will be more than a user name in the future. It can have some credentials/token stuff from Authentication system (shiro), so interpreter process can reuse it without asking authentication again, when they're required.

So my suggestion is, create such class AuthenticationInfo, and pass it into InterpreterContext instead of String userName, for further extension in the future.

Thank you for the suggestion @Leemoonsoo. Have added AuthenticationInfo class, and made relevant changes.

I have tried and it works well.
One thing is, org.apache.zeppelin.display package supposed to have Display System related codes.
I think AuthenticationInfo is less related to Display System. Could you suggest other package name?

Thanks you @Leemoonsoo, that does make a lot of sense.

Thanks @prabhjyotsingh.
It looks good to me.

LGTM

Let's rebase and merge this?

Thank you for reviewing this. Have merged this with master.