You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Eugene Koontz (JIRA)" <ji...@apache.org> on 2012/07/05 20:42:34 UTC

[jira] [Commented] (ZOOKEEPER-1497) Allow server-side SASL login with JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407377#comment-13407377 ] 

Eugene Koontz commented on ZOOKEEPER-1497:
------------------------------------------

Hi Matteo, 
It looks like a good design overall. 

It's good that we now have (with this patch) zookeeper.sasl.serverconfig as well as the existing zookeeper.sasl.clientconfig (from ZOOKEEPER-1373).

I think ServerCnxnFactory.configureSaslLogin() could use some documentation about why we throw a caught exception or ignore it.

Some logging at ERROR or WARN level where appropriate, to help ZK admins diagnose configuration problems (for example, what if zookeeper.sasl.serverconfig references a non-existent JAAS configuration section? or, what if java.security.auth.login.config points to a non-existent file, but Configuration has been set programmatically and is valid, should we ignore the non-existent file and login with the valid Configuration?)

Some additional tests would be good as the QA bot mentioned. See SaslAuthDesignatedClientTest.java from ZOOKEEPER-1373 for how I added more configuration testing on the Client side. 

Would be nice to test programmatically-set JAAS configuration. Rather than writing a string to a temporary file and then setting java.security.auth.login.config to point to it, instead, we'd build a javax.security.auth.login.Configuration in code in the tests and then call Configuration.setConfiguration() (if I understand the API correctly).


                
> Allow server-side SASL login with JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-1497
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1497
>             Project: ZooKeeper
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 3.4.3, 3.3.5
>            Reporter: Matteo Bertozzi
>            Assignee: Matteo Bertozzi
>              Labels: security
>         Attachments: ZOOKEEPER-1497-v1.patch
>
>
> Currently the CnxnFactory checks for "java.security.auth.login.config" to decide whether or not enable SASL.
> * zookeeper/server/NIOServerCnxnFactory.java
> * zookeeper/server/NettyServerCnxnFactory.java
> ** configure() checks for "java.security.auth.login.config"
> *** If present start the new Login("Server", SaslServerCallbackHandler(conf))
> But since the SaslServerCallbackHandler does the right thing just checking if getAppConfigurationEntry() is empty, we can allow SASL with JAAS configuration to be programmatically just checking weather or not a configuration entry is present instead of "java.security.auth.login.config".
> (Something quite similar was done for the SaslClient in ZOOKEEPER-1373)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira