[Freeipa-users] Cockpit integration part I - Single Sign On

[Alexander Bokovoy]

On Sun, 27 Dec 2015, Jochen Hein wrote:
>
>Hi,
>
>here is what I did on my system - may be helpful to others as well.
>
>Cockpit: enable Single-Sign-On with FreeIPA
>===========================================
>
>I wanted to use SSO to access the Cockpit already installed on my
>freeipa server.
>
>Upstream documentation is on
>http://cockpit-project.org/guide/latest/sso.html, so we only add some
>remarks here.
>
>Upstream:
>,----
>| There must be a valid Kerberos host key for the server in the
>| /etc/krb5.keytab file. It may be necessary to create a kerberos
>| service principal and update the keytab if it is not
>| present. Depending on your domain type different service names are
>| required:
>|
>| Active Directory	HOST/server.example.com at EXAMPLE.COM
>| IPA and MIT		HTTP/server.example.com at EXAMPLE.COM
>`----
>
>This has already happened - apache on my server uses the service
>HTTP/server.example.com at EXAMPLE.COM, but the service is not present in
>the server keytab. So we need to add the service principal there.
>
>If we just generate a new keytab, we invalidate the keytab used by
>apache. So we need to only retrieve the keytab, not regenerate
>it. This is only possible after we allowed the retrieval of the
>keytab for either the admin principal, the host principal or some
>users/host groups. Here we go for the host principal:
>
># kinit admin
># ipa service-allow-retrieve-keytab HTTP/freeipa.jochen.org at JOCHEN.ORG --hosts=freeipa.jochen.org
>
>Finally we retrieve the service keytab into /etc/krb5.keytab:
>
># ipa-getkeytab -r -s freeipa.jochen.org -p HTTP/freeipa.jochen.org at JOCHEN.ORG -k /etc/krb5.keytab
>
>After that Single Sign On works as expected.
Thanks. I think we actually could do better by using gss-proxy -- if
only cockpit-ws would cooperate[1]. I'll file a bug  -- when cockpit-ws
launches cockpit-session it doesn't pass anything from the environment
cockpit-ws was launched with. This prevents use of gss-proxy,
unfortunately. With gss-proxy you would not need to retrieve and
maintain separate keytabs or give cockpit any access to the keytab at
all.

When this would be fixed, a config section for /etc/gssproxy/gssproxy.conf like this
would allow the gss-proxy interposer would kick in and obtain the
ticket:

[service/cockpit-ws]
 mechs = krb5
 cred_store = keytab:/etc/httpd/conf/ipa.keytab
 cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
 cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
 # uid of cockpit-ws
 euid = 981

You also would need to add

Environment=GSS_USE_PROXY=yes

to the cockpit.service, so that GSSAPI library would start using
gss-proxy.

I've CC:ed Marius to make Cockpit guys aware of the issue.

[1] https://github.com/cockpit-project/cockpit/blob/master/src/ws/cockpitauth.c#L391
-- 
/ Alexander Bokovoy