Michael,
On 10/1/24 12:13, Michael Osipov wrote:
On 2024/10/01 13:56:22 Christopher Schultz wrote:
Michael,
On 10/1/24 05:21, Michael Osipov wrote:
On 2024/09/30 17:21:30 Christopher Schultz wrote:
Michael,
On 9/30/24 11:41, Michael Osipov wrote:
Chris,
On 2024/09/30 14:33:53 Christopher Schultz wrote:
Michael,
On 9/28/24 13:34, Michael Osipov wrote:
On 2024/09/27 15:14:15 Christopher Schultz wrote:
Sebastian,
On 9/27/24 11:04, Sebastian Trost wrote:
Francesco,
On 26.09.2024 16:12, Francesco Viscomi wrote:
Hi all,
I'm not able to understand why I cannot access to
http://localhost:8080/manager/html
I've configured the user in tomcat.users.xml:
<role rolename="manager-gui"/>
<user username="admin" password="admin" roles="manager-gui"/>
I'm using tomcat 9; and jdk17;
I've also noted that in my personal pc when try to access manager/html a
pop up ask me to login (in my personal pc it works right)
While when I try to use it in the company pc it gives me 401
unauthorized;
I do not know what I have to modify on chrome to get access in manager
app,
I also use in the company pc Zscaler, but I do not know what I have to
change in it (eventually) in order to access the manager app.
Your corporate browser probably has basic authentication disabled. Check
this site: https://jigsaw.w3.org/HTTP/Basic
If there is no basic authentication popup where you can enter username/
password then this is probably the case.
See: https://answers.microsoft.com/en-us/microsoftedge/forum/all/latest-
version-of-edge-no-longer-shows-basic/3601252b-e56b-46c0-a088-0f6084eabe47
I've really had it with Microsoft deciding that HTTP Basic
authentication is just not okay. They seem to have forgotten that TLS
makes it secure.
The reasoning is never to share a long term secret: your password.
HTTP Digest also requires pre-shared passwords.
There is a subtile difference: the password is never transferred over the wire
and does not appear on the target server.
While that may be true, it is irrelevant. The
MD5(username:reaml:password) must be known to the server. That is as
good as the password in terms of security.
The realm name can never be changed without changing all passwords. The
algorithm used can never be changed without changing all passwords.
The overwhelming majority of web-based applications use pre-shared
passwords with FORM-based authentication over TLS. There is zero
reduction in security when compared to HTTP Digest. In both cases,
hashes can be stored on the server-side which is of course a best-practice.
I am aware of that, but Digest is dead, at least via SASL. Unfortunately RFC
7804 never gained traction in this regard.
HTTP Digest is a nightmare, but they are forcing users onto it.
The key is to use SPNEGO in enterprise environments.
What about non-enterprise environments?
IMHO, this is irrelevant for Microsoft. In enterprise you do have at least
SPNEGO or even PKI. For non-enterprise I see only Basic as a viable option.
Except that Microsoft is killing it.
Yes, unfortunately. They never and will never care about non-AD users.
At $work, we use WebDAV over TLS with an OpenLDAP back-end for
authentication. It works great for all employees except those who use
Windows. It seems like every installation of Windows needs a different
hack to get HTTP Basic working when connecting to WebDAV.
As said, all requires SPNEGO. WebDAV for Windows Explorer just works with
SPNEGO and nothing else. You still can use a KDC like Samba to achieve the
above without losing the LDAP bind-based authentication, but OpenLDAP will
handle over to a KDC.
I'd be interested to see some references for getting SPNEGO to work with
httpd mod_dav and OpenLDAP as a back-end. If it can expose Kerberos to
clients, I'll gladly give it a shot.
Here you go: https://lists.apache.org/thread/dnmrcgq5f1txsf7shh3dq7m044bdkv4k>
Now you need to use mod_authnz_ldap as authorization provider.
I'm already using mod_authnz_ldap. AuthType GSSAPI looks like it
requires a third-party module and, possibly, a Kerberos
"implementation". It looks like my Debian-based system has a package
"libapache2-mod-auth-gssapi" which has a dependency on
"libgssapi-krb5-2". Is that essentially all I need?
Is there an equivalent of "AuthBasicProvider ldap" that I would need
with gssapi to make it use the ldap provider?
The Kerberos principal needs to be mapped to an LDAP attribute,
dependening on the system it could be userPrincipal or
krb5Principal. Give it a shot, if you have the setup.
I'll see what I can do. Thanks for the pointer.
On Tomcat side I have replaced LDAP authz with something much better/
faster for most of the use cases.
There is no Tomcat in this particular environment. Just httpd and a disk.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
