[Bug 65302] Add support for setting com.sun.jndi.ldap.tls.cbtype

2021-06-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65302

Michael Osipov  changed:

   What|Removed |Added

 CC||micha...@apache.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 65302] Add support for setting com.sun.jndi.ldap.tls.cbtype

2021-05-27 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65302

--- Comment #7 from Michael Osipov  ---
(In reply to Mike Millson from comment #6)
> (In reply to Michael Osipov from comment #1)
> > The only SASL mech supporting this is GSSAPI and you can
> > request GSS-API to completely encrypt your traffic with Kerberos
> > (auth-conf), no TLS necessary.
> 
> Do you have an example of a configuration that does this that I could
> propose as an alternative?

Yes, see my DirContextSource [1] which I have been using the last eight years.
Works pefectly in Tomcat also.
In production:
ldap://ad.example.com:3268;
auth="gssapi" loginEntryName="tomcat-initiate" referral="ignore"
qop="auth-conf"
additionalProperties="com.sun.jndi.ldap.connect.timeout=1000;com.sun.jndi.ldap.read.timeout=1000"
/>

In the world's largest forest.


[1] http://dirctxsrc.sourceforge.net/dircontextsourcefactory.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 65302] Add support for setting com.sun.jndi.ldap.tls.cbtype

2021-05-27 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65302

--- Comment #6 from Mike Millson  ---
(In reply to Michael Osipov from comment #1)
> The only SASL mech supporting this is GSSAPI and you can
> request GSS-API to completely encrypt your traffic with Kerberos
> (auth-conf), no TLS necessary.

Do you have an example of a configuration that does this that I could propose
as an alternative?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 65302] Add support for setting com.sun.jndi.ldap.tls.cbtype

2021-05-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65302

--- Comment #5 from Christopher Schultz  ---
(In reply to romain.manni-bucau from comment #4)
> Assuming a new "String properties" property is added (with its setter) ... 
> Can't this issue move to a more generic properties support?

Of course. I was looking for a one-liner fix to this issue, but it looks like
maybe it can't (or shouldn't) be that simple.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 65302] Add support for setting com.sun.jndi.ldap.tls.cbtype

2021-05-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65302

--- Comment #4 from romain.manni-bucau  ---
Hi,

Maybe a side question/issue: JNDI realm is actually not a JNDI realm but more a
sun JNDI realm in the sense its configuration is quite bound to a particular
implementation.
Assuming a new "String properties" property is added (with its setter) and read
with Properties#load and appended to the getDirectoryContextEnvironment if not
null then it will enable to use any implementation (and even not yet supported
sun impl -
https://github.com/openjdk/jdk11u/blob/73eef16128417f4a489c4dde47383bb4a00f39d4/src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java#L148).
In the context of this issue it will also enable to add any other com.sun.jndi
property and avoid tomcat to be updated each time.
Can't this issue move to a more generic properties support?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 65302] Add support for setting com.sun.jndi.ldap.tls.cbtype

2021-05-13 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65302

--- Comment #3 from Michael Osipov  ---
(In reply to Christopher Schultz from comment #2)
> Would it hurt anything to unconditionally add
> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point to the properties used to
> initialize to the InitialContext? Or does this really need to be something
> controlled by configuration?

I don't think that this makes sense, for two reasons:
* It adds some computational overhead, maybe irrelevant
* It works only IF you use SASL GSSAPI mech which I don't expect most people to
use

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 65302] Add support for setting com.sun.jndi.ldap.tls.cbtype

2021-05-12 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65302

--- Comment #2 from Christopher Schultz  ---
Would it hurt anything to unconditionally add
com.sun.jndi.ldap.tls.cbtype=tls-server-end-point to the properties used to
initialize to the InitialContext? Or does this really need to be something
controlled by configuration?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 65302] Add support for setting com.sun.jndi.ldap.tls.cbtype

2021-05-12 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65302

--- Comment #1 from Michael Osipov  ---
Why? I did several reviews of the ticket when it was discussed with
security-dev@. The only SASL mech supporting this is GSSAPI and you can request
GSS-API to completely encrypt your traffic with Kerberos (auth-conf), no TLS
necessary. SSPI offers other mechs besides GSSAPI to use channel binding
(Digest MD5 which is dead).
This is a case (auth-conf) even MS considers to be secure and no need to
enforce TLS channel binding.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org