4:52 a.m.
On ma, 03 helmi 2020, TC Johnson via FreeIPA-users wrote:
Hi,
I'm looking to understand a little better how the framework is using
GSS Proxy to authenticate the user who is accessing the tools. The
information here
(https://www.freeipa.org/page/Troubleshooting/PrivilegeSeparation) is
nice and I've been reading through the numerous libraries, python
files, and configs... but I can't find how they are telling the WSGI
app to use GSS to impersonate.
Any guidance is appreciated, reading suggestions, examples, what have you :)
They aren't telling anyone, they don't need to. It is configured in
gssproxy:
[service/ipa-api]
mechs = krb5
cred_store = keytab:/var/lib/ipa/gssproxy/http.keytab
cred_store = client_keytab:/var/lib/ipa/gssproxy/http.keytab
allow_constrained_delegation = true
allow_client_ccache_sync = true
cred_usage = initiate
euid = ipaapi
Since IPA framework doesn't have access to the actual keys and uses
GSSAPI code, GSS-Proxy's GSSAPI interposer proxies the calls to
GSS-Proxy from any GSSAPI application. GSS-Proxy configuration describes
what to allow here. And in case of IPA API, since the process runs under
effective UID of 'ipaapi', it matches the definition above.
So the flow goes like this:
- mod_auth_gssapi does initial authentication and stores GSSAPI
credentials (service ticket provided by the client) in a cred store,
then returns a cookie that contains encrypted creds
- for non-Kerberos case, IPA framework does run own kinit as a user and
then does internal redirect to mod_auth_gssapi-protected end point
that will generate a cookie as part of a subrequest.
- when cookie is provided by the client, mod_auth_gssapi automatically
handles its transformation into a proper GSSAPI cred store that is
handled transparently by GSS-Proxy thanks to the interposer proxy.
- so when IPA framework does the check that there is a known Kerberos
principal in the context, we already deal with the credentials
managed for us by mod_auth_gssapi + GSS-Proxy. At this point, we
simply load 'default' creds and use them. From 'use' point of view,
IPA framework just tries to connect to LDAP with SASL GSS-SPNEGO and
that causes MIT Kerberos library to request a service ticket to LDAP.
We don't have original user's TGT here, only a service ticket to
ourselves (HTTP/...) and this means GSS-Proxy would have failed to
unless constrained delegation is allowed. And it is allowed in
GSS-Proxy configuration. Also, on KDC side it is allowed for HTTP/...
principal on IPA masters to use constraint delegation on behalf of a
user to obtain a service ticket to ldap/... and cifs/... principals.
- once IPA framework gets a service ticket to ldap/... (or cifs/...,
for trust-specific operations), it simply uses it. The target side
(LDAP or SMB server) recognize that the ticket was obtained via
constraint delegation and see the impersonated identity instead of
HTTP/... principal.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland