organised on coding considerations then config start with easy to verify configuration parameters:
MG>$JRE_HOME/lib/security/java.security entries verification : > MG>can you verify > Context.SECURITY_AUTHENTICATION="DIGEST-MD5" ? MG>can you verify authentication Principal is set to EITHER u as in > Context.SECURITY_PRINCIPAL="u: cuser" > MG>OR authentication Principal is set to DistinguishedName > Context.SECURITY_PRINCIPAL="dn: cn=C. User, ou=NewHires, o=JNDITutorial" ? MG>what is value of zookeeper.sasl.client.username System Property ? Martin ______________________________________________ ________________________________ From: Andor Molnar <[email protected]> Sent: Tuesday, February 13, 2018 1:58 PM To: [email protected] Subject: Re: SASL jaas.conf principal="*" problem Sorry Marvin, I'm afraid I don't really get your point. Unfortunately I'm not a Kerberos expert either. :( I think the best would be to put together a Jira about your suggested changes explaining them in an organized fashion and I'd be able to dig a little bit deeper. Thanks, Andor On Thu, Feb 8, 2018 at 9:16 PM, Martin Gainty <[email protected]> wrote: > Boton/Andor > > MG>a few questions on modifying Subject Principals > > MG>security manager must grant > AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION > for your login > > MG>assume $JRE_HOME/lib/security/java.policy contains something like: > grant { > // There is no restriction to any algorithms. > permission javax.crypto.CryptoAllPermission; > //no restrictions to modifying Principals > permission AuthPermissionHolder.MODIFY_PRINCIPALS_PERMISSION; > ... > > MG>then ZK should pass SecurityManager MODIFY_PRINCIPALS_PERMISSION > > java.lang.SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > switch (which) { > case Subject.PRINCIPAL_SET: > sm.checkPermission(AuthPermissionHolder.MODIFY_ > PRINCIPALS_PERMISSION); > > > MG>assuming you have -Djava.security.debug=ALL have you seen permission > errors? > > MG>Zookeeper implementation consideration: > MG>if ZK session is quiesced you may lose Principal credentials (as there > is no serialization for credentials) > > "credentials associated with the <code>Subject</code> are not. Note > that the " > "< code>java.security.Principal</code> class does not implement > <code>Serializable</code>. " > "Therefore ALL concrete <code>Principal</code> implementations > associated with Subjects MUST" > "IMPLEMENT <code>Serializable</code>." > > MG>Zookeeper devs where are Zookeeper Principal concrete classes (which > implement Serializable)? > > MG>Jaas.conf CallbackHandlers are *usually* one of predefined LoginModules: > > - JndiLoginModule > > <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/JndiLoginModule.html> JndiLoginModule (Java Authentication and Authorization ...<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/JndiLoginModule.html> docs.oracle.com The module prompts for a username and password and then verifies the password against the password stored in a directory service configured under JNDI. > - KeyStoreLoginModule > > <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/KeyStoreLoginModule.html> KeyStoreLoginModule (Java Authentication and Authorization ...<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/KeyStoreLoginModule.html> docs.oracle.com Provides a JAAS login module that prompts for a key store alias and populates the subject with the alias's principal and credentials. Stores an X500Principal for the ... > - Krb5LoginModule > > <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html> Krb5LoginModule (Java Authentication and Authorization ...<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html> docs.oracle.com This LoginModule authenticates users using Kerberos protocols. The configuration entry for Krb5LoginModule has several options that control the authentication process ... > - NTLoginModule > > <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/NTLoginModule.html> NTLoginModule (Java Authentication and Authorization Service )<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/NTLoginModule.html> docs.oracle.com This LoginModule renders a user's NT security information as some number of Principals and associates them with a Subject. This LoginModule recognizes the debug option. > - UnixLoginModule > > <https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/UnixLoginModule.html> UnixLoginModule (Java Authentication and Authorization ...<https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/UnixLoginModule.html> docs.oracle.com This LoginModule imports a user's Unix Principal information (UnixPrincipal, UnixNumericUserPrincipal, and UnixNumericGroupPrincipal) and associates them with the ... > > MG>questions on Zookeeper org.apache.zookeeper.server.auth.DigestLoginModule > > > MG>org.apache.zookeeper.server.auth.DigestLoginModule implements > LoginModule > > public void initialize(Subject subject, CallbackHandler > callbackHandler, Map<String,?> sharedState, Map<String,?> options) { > //assume options is JAAS options > > if (options.containsKey("username")) { > // Zookeeper client: get username and password from JAAS conf > (only used if using DIGEST-MD5). > this.subject = subject; > String username = (String)options.get("username"); > this.subject.getPublicCredentials().add((Object)username); > String password = (String)options.get("password"); > > MG>since following is NOT overridden by ZK concrete class.. can we can > lose credentials during session quiesce? > this.subject.getPrivateCredentials().add((Object)password); > } > return; > } > > public boolean login() { > //Unlike Krb5LoginModule, we don't do any actual login or credential > passing here: > //authentication to Zookeeper is done later, through the SASLClient > object. > > return true; > } > > MG>DigestLoginModule::login authentication would happen @ > MG>ZooKeeperSaslClient.ZooKeeperSaslClient(final String > serverPrincipal) which calls to createSaslClient below: > > MG>createSaslClient reference from ZK > .\org\apache\zookeeper\client\ZooKeeperSaslClient.java > synchronized private SaslClient createSaslClient(final String > servicePrincipal, > final String > loginContext) throws LoginException { > try { > if (login == null) { > if (LOG.isDebugEnabled()) { > LOG.debug("JAAS loginContext is: " + loginContext); > } > // note that the login object is static: it's shared amongst > ALL zookeeper-related connections. > // createSaslClient() must be declared synchronized so that > login is initialized only once. > login = new Login(loginContext, new > ClientCallbackHandler(null)); > MG>where ClientCallbackHandler is inner class > login.startThreadIfNeeded(); > } > Subject subject = login.getSubject(); > MG>Regular/Public/Private Principals *should* be contained with Subject (from > login > SaslClient saslClient; > // Use subject.getPrincipals().isEmpty() as an indication of > which SASL mechanism to use: > // if empty, use DIGEST-MD5; otherwise, use GSSAPI. > if (subject.getPrincipals().isEmpty()) { > // no principals: must not be GSSAPI: use DIGEST-MD5 > mechanism instead. > LOG.info("Client will use DIGEST-MD5 as SASL mechanism."); > String[] mechs = {"DIGEST-MD5"}; > MG>Login *contains* Subject *which contains* > PublicCredentials/PrivateCredentials > String username = > (String)(subject.getPublicCredentials().toArray()[0]); > String password = > (String)(subject.getPrivateCredentials().toArray()[0]); > // "zk-sasl-md5" is a hard-wired 'domain' parameter shared > with zookeeper server code (see ServerCnxnFactory.java) > saslClient = Sasl.createSaslClient(mechs, username, > "zookeeper", > "zk-sasl-md5", null, new ClientCallbackHandler(password)); > return saslClient; > > > MG>instead of obtaining thru Private Creds via (String)(subject. > getPrivateCredentials().toArray()[0])MG>confused on reason 4 hardcoded > 'zookeeper' password referenced from above Sasl.createSaslClient? > > MG>$JRE_HOME/lib/security/java.security entries verification : > MG>can you verify > Context.SECURITY_AUTHENTICATION="DIGEST-MD5" > > MG>can you verify authentication Principal is set to EITHER u as in > Context.SECURITY_PRINCIPAL="u: cuser" > MG>OR authentication Principal is set to DistinguishedName > Context.SECURITY_PRINCIPAL="dn: cn=C. User, ou=NewHires, o=JNDITutorial" > > MG>ZooKeeperSaslClient considerations: > > ZooKeeperSaslClient(final String serverPrincipal) is instantiated in > org.apache.zookeeper.ClientCnxn.java > > String principalUserName = System.getProperty("zookeeper. > sasl.client.username", "zookeeper"); > if(principalUserName!=null) zooKeeperSaslClient = > new ZooKeeperSaslClient( > principalUserName+"/"+addr. > getHostString()); > > MG>what is value of zookeeper.sasl.client.username System Property > ? > Martin > > > ------------------------------ > *From:* Martin Gainty <[email protected]> > *Sent:* Wednesday, February 7, 2018 12:03 PM > *To:* [email protected] > *Subject:* Re: SASL jaas.conf principal="*" problem > > MG>i agree.. DIGEST-MD5 (and not kerberos) seems to be default > authentication for zookeeper > > SaslServer saslServer = Sasl.createSaslServer("DIGEST- > MD5","zookeeper","zk-sasl-md5",null, login.callbackHandler) > > MG>to ask a dumb question..where is DIGEST-MD5.conf located in zookeeper > binary distro? > MG>or is it sufficient to supply DIGEST-MD5.conf parameters in jaas.conf? > > ________________________________ > From: Andor Molnar <[email protected]> > Sent: Wednesday, February 7, 2018 10:29 AM > To: [email protected] > Subject: Re: SASL jaas.conf principal="*" problem > > Hi Botond, > > I believe the guy who originally implemented this (Rakesh) can give some > color to your question, but until that you could dig the original Jira: > https://issues.apache.org/jira/browse/ZOOKEEPER-1045 [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045> issues.apache.org ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers. > [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ... > <https://issues.apache.org/jira/browse/ZOOKEEPER-1045> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045> issues.apache.org ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers. > issues.apache.org > ZOOKEEPER-938 addresses mutual authentication between clients and servers. > This bug, on the other hand, is for authentication among quorum peers. > > > [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...< > https://issues.apache.org/jira/browse/ZOOKEEPER-1045> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045> issues.apache.org ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers. > [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ... > <https://issues.apache.org/jira/browse/ZOOKEEPER-1045> [ZOOKEEPER-1045] Support Quorum Peer mutual authentication ...<https://issues.apache.org/jira/browse/ZOOKEEPER-1045> issues.apache.org ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers. > issues.apache.org > ZOOKEEPER-938 addresses mutual authentication between clients and servers. > This bug, on the other hand, is for authentication among quorum peers. > > > issues.apache.org > ZOOKEEPER-938 addresses mutual authentication between clients and servers. > This bug, on the other hand, is for authentication among quorum peers. > > > > for more information. > > Other than that, if you believe that you can either fix the issue or > implement it in a better way, your contribution will be highly > appreciated and it would be very kind of you to open new Jira and new pull > request on GitHub. > > We can discuss further details there. > > Thanks, > Andor > > > > > > On Mon, Feb 5, 2018 at 7:21 PM, Botond Hejj <[email protected] > > > wrote: > > > Hi, > > > > Java 8 introduced the possibility to use * for the principal in treadmill > > which is great and would allow us to run treadmill behind multiple > > interfaces and SASL would pick the right keytab. > > > > Unfortunately this doesn't work in ZooKeeper I have dived in the code a > bit > > and what I have found is that ZooKeeper is using DIGEST-MD5 in that case > > even though I don't use the DigestLoginModule. The reason for that is > line > > 251 here: > > https://github.com/apache/zookeeper/blob/master/src/ [https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/> apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/> github.com zookeeper - Mirror of Apache Hadoop ZooKeeper > java/main/org/apache/ > <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/> [https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/> apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/> github.com zookeeper - Mirror of Apache Hadoop ZooKeeper > apache/zookeeper > <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/> [https://avatars3.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/> apache/zookeeper<https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/> github.com zookeeper - Mirror of Apache Hadoop ZooKeeper > github.com > zookeeper - Mirror of Apache Hadoop ZooKeeper > > > [https://avatars3.githubusercontent.com/u/47359? > s=400&v=4]<https://github.com/apache/zookeeper/blob/master/ > src/java/main/org/apache/> > > apache/zookeeper<https://github.com/apache/zookeeper/ > blob/master/src/java/main/org/apache/> > <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/> > apache/zookeeper > <https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/> > github.com > zookeeper - Mirror of Apache Hadoop ZooKeeper > > > github.com > zookeeper - Mirror of Apache Hadoop ZooKeeper > > > > > zookeeper/util/SecurityUtils.java > > > > It falls back to Digest if the principal list is empty which is the case > > when * is specified. > > Why is that and why not the login type is checked? > > Anyway this can only be fixed in a nonbackward compatible way or with a > > flag in a backward compatible way. > > > > I could prepare a patch. > > I would just like to understand the reason behind the implementation. Is > > there any particular reason why this fallback is there? What would the > > implication if I remove that? If I understand the reason maybe I could > > patch it without breaking backward compatibility. > > > > There is also a comment: TODO: use 'authMech=' value in zoo.cfg. > > > > Is there any jira or patch for that? > > > > Regards, > > Botond Hejj > > Morgan Stanley | Technology > > Lechner Odon fasor 8 | Floor 07 > <https://maps.google.com/?q=Lechner+Odon+fasor+8+%7C+Floor+07+%0D+%3E+Budapest&entry=gmail&source=g> > > Budapest > <https://maps.google.com/?q=Lechner+Odon+fasor+8+%7C+Floor+07+%0D+%3E+Budapest&entry=gmail&source=g>, > 1095 > > Phone: +36 1 881-3962 <+36%201%20881%203962> > > [email protected] > > >
