Motivation
Okta is used by my employer (and many others, maybe some other OpenID server) for authenticating employees in the organization. Due to various security requirements, we lock down access to all Druid nodes except for router. Hence, the proposal to add a security extension with implementation of Authenticator interface that supports the standard OpenID Connect protocol supported by Okta. That allows us to give group of admins/employees access to router web console.
Proposed changes
A new druid extension would be added with implementation of Authenticator interface. We will use pac4j as the oauth client library . Choosing pac4j due to its coverage of various other protocols, active community, apache license, used by Apache Knox and also that we have it working already. Actually, I would envision this extension to eventually support much more than just OpenID Connect and pac4j is very rich as it supports SAML, LDAP and many more.
In addition to the new security extension, /unified-console.html would be removed from "unsecured paths" so that redirect for login is appropriately handled by browser to send user to okta (or whatever auth server) login page. Adjustment would be made to PreResponseAuthorizationCheckFilter to skip "authorization done" check for a configured set of paths and /unified-console.html would be added to that.
Operational impact
If some users need /unified-console.html in unsecured paths then they would have to add it to the druid.auth.unsecuredPaths property.
Test plan (optional)
I am testing the code using public okta dev server to test that it works.
Future work (optional)
At this point I am not planning to add the Escalator impl that could be added later if community has use cases around using OpenID for auth in all of Druid nodes rather than at the edge/router .
Extension introduced could also be enhanced to support LDAP, SAML etc as pac4j could handle them as well.
Motivation
Okta is used by my employer (and many others, maybe some other OpenID server) for authenticating employees in the organization. Due to various security requirements, we lock down access to all Druid nodes except for router. Hence, the proposal to add a security extension with implementation of
Authenticatorinterface that supports the standard OpenID Connect protocol supported by Okta. That allows us to give group of admins/employees access to router web console.Proposed changes
A new druid extension would be added with implementation of
Authenticatorinterface. We will use pac4j as the oauth client library . Choosing pac4j due to its coverage of various other protocols, active community, apache license, used by Apache Knox and also that we have it working already. Actually, I would envision this extension to eventually support much more than just OpenID Connect and pac4j is very rich as it supports SAML, LDAP and many more.In addition to the new security extension,
/unified-console.htmlwould be removed from "unsecured paths" so that redirect for login is appropriately handled by browser to send user to okta (or whatever auth server) login page. Adjustment would be made toPreResponseAuthorizationCheckFilterto skip "authorization done" check for a configured set of paths and/unified-console.htmlwould be added to that.Operational impact
If some users need
/unified-console.htmlin unsecured paths then they would have to add it to thedruid.auth.unsecuredPathsproperty.Test plan (optional)
I am testing the code using public okta dev server to test that it works.
Future work (optional)
At this point I am not planning to add the
Escalatorimpl that could be added later if community has use cases around using OpenID for auth in all of Druid nodes rather than at the edge/router .Extension introduced could also be enhanced to support LDAP, SAML etc as pac4j could handle them as well.