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.