Feature Request: Implicit user creation w/header auth

[schenksj]

Current userNameHeader capabilities allow externalizing authentication to an intercepting proxy web server. Our intercepting proxy is capable of providing both authentication and authorization services.

I'd be interested in making a contribution to allow user creation to be performed on the fly when the intercepting proxy allows a user through and the system is so configured. I'm thinking of adding an appropriate call to Db.setUser followed by a call to Db.setUserCache in the eventuality where the first call to Db.setUserCache fails and the system is configured to perform implicit user creation in these locations:

https://github.com/aol/moloch/blob/292674230e21aafba7d34936e1ae573cdea5d08a/viewer/viewer.js#L268-L273

and

https://github.com/aol/moloch/blob/292674230e21aafba7d34936e1ae573cdea5d08a/viewer/viewer.js#L240-L258

And also proxying an indication that header auth occurred here:

https://github.com/aol/moloch/blob/292674230e21aafba7d34936e1ae573cdea5d08a/viewer/viewer.js#L617-L626

Would appreciate any feedback on appropriateness of the feature and correctness of the proposed solution. (Related to #1083)

[awick]

I would only do it for the first getUserCache, since the second is server2server and I would wait until the user hit the app before auto creating. I would probably have a setting that is the json to send up to create the user, minus username.

I do find this feature semi scary, are you really adding users that often that it has become a burden? Is the issue you have many clusters, if so I would first look at the usersElasticsearch setting and share users across all your clusters.

[schenksj]

@awick Thanks for the feedback! I assumed the second one was necessary as with multi-viewer you can't pull pcaps unless the user exists on the cluster where the pcap resides.

We have quite a few clusters, and prefer that all our provisioning activities are fully automated as part of our IAM system. Basically if AD says they have access, they should have access. Less moving parts is better. The other option might be to just create a temporary user object on the fly that never hits ES?

[awick]

Yep, if you wanted to support multiviewer without usersElasticsearch then you would need that. But again if you used usersElasticsearch (which you probably really should so views, settings, ...) are the same across all clusters then you would only have to add once.

I know you have the AD issue open too.

[schenksj]

Yes, thank you. I think elastic search users are a good idea too, though I'm pretty sure you have to set up users separately in each cluster's elastic instance when using multies -- maybe I'm doing something wrong... This might replace our need for the AD issue (#1083) to be addressed for now (not that I'm not willing to help out with the other one at some point too).

[awick]

Setting usersElasticsearch in all viewers (set in multiviewer too) makes it so you only need 1 users db, and the users are shared across all clusters, even with multies.

[schenksj]

Got it. Let me work on this and get you a PR to review.

[schenksj]

Speaking of usersElasticSearch, it looks like we missed client-auth for that capability. Can I bundle that fix with this PR, or do you want to keep it a separate bug fix.

https://github.com/aol/moloch/blob/292674230e21aafba7d34936e1ae573cdea5d08a/viewer/db.js#L93-L107

[awick]

separate would be better. Can I convince you to come over to slack yet?

[schenksj]

I'll need to drag a personal device into the office for slack. I'll get on that.