Firefox and Brave SPNEGO Setup for Authentication with Kerberos
Updates
- 2023-05-22
-
Add Firejail config for sssd-krb5;
- 2022-11-24
-
Add Firejail configuration and k5tls requirement;
- 2022-12-07
-
Update Firejail information slightly.
- 2022-12-20
-
Use
/run
, not/var/run
for Firejail.
Kerberos single sign-on authentication is a Good Thing,A cheer for
each head!
including for use with web sites. The mechanism for that is
SPNEGO,A Microsoft
invention, which IANA
quoth,
“violates both HTTP semantics (being connection-oriented) and syntax (use
of syntax incompatible with the WWW-Authenticate and Authorization header
field syntax).”
a.k.a. ‘negotiate-auth’ — specifically the
GSSAPI method to do Kerberos.
The other one, NTLM, is insecure
and should just be avoided even if the client supports it.
SPNEGO is supported by Firefox and Chromium derivatives like Brave (the only
non-Firefox graphical browser I use). However, configuration for it is rather
poorly-documented, with somewhat misleading instructions in various
laces.I was recently looking at this for use with Fedora services
after years of not having SPNEGO available locally, and getting confused.
Here’s (all) you need to do, at least assuming you’re using versions for Unixy
systems, tested on GNU/Linux.
Kerberos configuration
Obviously you need a krb5.conf
appropriate for the site(s) you want
to access, specifically any foreign realm setup.
Less obviously, you may need to ensure dns_canonicalize_hostname
is
true
.Debian’s default is false, unlike Red Hat’s.
That
allows, for instance, the redirection done by the Fedora copr site
(copr.fedoraproject.org
) to work; it’s not clear whether it should be
necessary or whether the site may be mis-configured as of now.
You need the MIT Kerberos TLS plugin from the krb5-k5tls
package on
Debian and Fedora-ish systems.
Browser configuration
Generally browsers need to be configured to use SPNEGO.
Firefox
Visit the pseudo-URL about:config
and proceed despite the warning if
you haven’t done that before. Type, say, negotiate
into the search
box. That should show, amongst others,
network.negotiate-auth.trusted-uris
. Select its ‘pen’ edit button and
set its value to https://
to make SPNEGO generally available. If
you’re using the packaged version of Firefox from a Fedora or RHEL-based
system,But not Debian. I haven’t checked OpenSUSE.
that’s already
set as the default.Nevertheless there are Red Hat/Fedora
instructions to configure for specific domains.
If you really want to
restrict it to specific sites, it seems you can specify either actual URLs or
domain names, in which ‘.
’ acts as a wildcard,
e.g. .example.com
for sub-domains. For a list of domains, the
separator is a comma. You do want only to use https
, so it’s
presumably dangerous just to specify domains if you can’t be sure they
redirect http
to https
.
If you want to delegate credentials — only to trusted sites! —
set network.negotiate-auth.delegation-uris
similarly.
Brave (and other Chromium derivatives?)
Start the browser on the command line like
brave-browser --auth-server-whitelist=https://*
to do SPNEGO generally. You can use a comma-separated list of specific URLs
if you do want to restrict them for some reason. ‘*
’ acts as a
possible wildcard in them. Use --auth-negotiate-delegate-whitelist=...
if you want to allow delegation to selected sites.
The same works with Chromium, and you can put the option in the
CHROMIUM_FLAGS
environment variable. There seems to be no such
possibility for Brave. I had no luck setting that in the policies
directory, as
described in
Fedora instructions, for either Brave or Chromium.
Non-browser
SPNEGO may be used other than in browsers. On the command line,
appropriately-built curl
supports it with the --negotiate
option, but wget
appears not to have support.
Python has a requests_negotiate
module and Perl, if you must, has
LWP::Authen::Negotiate
. Doubtless similar things are
available elsewhere.
Otherwise there’s curl
to call either via a sub-process or a binding for your
chosen language.
Sandboxes (like Firejail)
Running the browser in some form of sandbox may stop GSSAPI working. That’s
specifically the case with the current (version 0.9.70) browser profiles for
Firejail. The Firejail
configuration you need depends on your Kerberos credential
cache;Potentially controllable per-application with the
KRB5CCNAME
environment variable.
I’ve tested with the default
FILE:
ccache location, for which adding the following to
/.config/firejail/firefox-common.local
works on Debian (similarly
for profiles for other browsers) and, presumably,
non-browsers:As reported.
whitelist /etc/krb5.conf
whitelist /tmp/krb5cc_*
whitelist /etc/ssl
A Fedora-ish system needs /etc/pki
instead of
/etc/ssl
. /etc/gss
might be needed generally for
GSSAPI using other mechanisms SPNEGO doesn’t support.
A KCM:
ccache with the default socket used by
sssd-kcm
and the original Heimdal KCM also needs
whitelist /run/.heim_org.h5l.kcm-socket
It was reported that
whitelist /var/lib/sss/pubconf/krb5.include.d/
needs to be added, presumably for use with sssd-krb5
which provides
it.
The above are collected into
whitelist-gssapi-common.inc
for inclusion in profiles of applications supporting GSSAPI.
I don’t know about the KEYRING:
ccache,Which anyway has
disadvantages — see sssd-kcm(8)
.
but it seems at least to be
blocked by seccomp. Running the program with KRB5_TRACE=/dev/stdout
(say) in the environment may provide enlightening messages about GSSAPI
failures and indicate what to whitelist if the above doesn’t work in another
situation.
Security
The Firefox default to allow SPNEGO generally over HTTPS in Fedora et al was
on the advice of experts (FreeIPA maintainers, I think) that it is
safe.I don’t know whether it was unsafe in the past, but there is
apparently-current advice around that it isn’t.
I guess that assumes that
insecure NTLM can’t be chosen. I don’t know what would be required for NTLM to
work with a non-MS Windows client, but the Firefox ...ntlm...
configuration items indicate that it at least would need to be configured in
the browser.
The implications of setting dns_canonicalize_hostname
are unclear.
Presumably it’s been OK’d by Red Hat experts, but I’ve seen suggestions that
it can potentially allow impersonation to enable servers to obtain credentials
for a service they don’t host.