A bit more details about Kerberos and LDAP mappers in docs

This commit is contained in:
mposolda 2016-03-14 11:50:54 +01:00
parent 975dcb68a9
commit 804fb2dc96
2 changed files with 32 additions and 2 deletions

View file

@ -154,7 +154,7 @@ ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG
</listitem>
<listitem>
<para>
Finally run Keycloak server and configure SPNEGO/Kerberos authentication in Keycloak admin console. Keycloak supports Kerberos authentication
Run Keycloak server and configure SPNEGO/Kerberos authentication in Keycloak admin console. Keycloak supports Kerberos authentication
through <link linkend='user_federation'>Federation provider SPI</link> . We have 2 federation providers with Kerberos authentication support:
<variablelist>
<varlistentry>
@ -185,6 +185,20 @@ ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG
</variablelist>
</para>
</listitem>
<listitem>
<para>
Finally you may need to check the Kerberos authenticator correctly configured. You can go to <literal>Authentication</literal> tab in
admin console and select <literal>Browser</literal> flow. Here you will see <literal>Kerberos</literal> authenticator, which is used by Keycloak for SPNEGO
handshake with client (exchange <literal>Negotiate</literal> header etc.). By default it's disabled, so Keycloak doesn't ask for Negotiate header, however once you
configured federation provider in previous step, it's automatically switched to <literal>ALTERNATIVE</literal>. So defacto you don't need to do anything, just
check that it's really switched to Alternative.
</para>
<para>
Alternative means that Keycloak tries to ask browser for Negotiate header, but if it's not available, it will continue on next authenticator (which usually means
displaying username/password form to user). You can switch to <literal>REQUIRED</literal> if you want to enforce login with
kerberos ticket and not allow fallback to username/password form.
</para>
</listitem>
</itemizedlist>
</section>
<section>

View file

@ -294,8 +294,24 @@
We have an example, which is showing LDAP integration and set of base mappers and sample mappers (mappers for street and postalCode) . It's in <literal>examples/ldap</literal>
in the Keycloak example distribution or demo distribution download. You can also check the example sources directly <ulink url="https://github.com/keycloak/keycloak/blob/master/examples/ldap">here</ulink> .
</para>
<section>
<title>Writing your own LDAP Mapper</title>
<para>
For the more advanced usecases, you have the possibility to create your own implementation of LDAP mapper or just subclass from
some already existing mapper implementation. You will need to implement <literal>UserFederationMapperFactory</literal> interface. In most cases, instead of
creating <literal>UserFederationMapperFactory</literal> from scratch, you can create subclasses of <literal>AbstractLDAPFederationMapperFactory</literal>, which itself
implements <literal>UserFederationMapperFactory</literal>. Then you need to create mapper implementation, which will be subclass of
<literal>AbstractLDAPFederationMapper</literal> (this mapper implementation will be returned by <literal>YourAbstractLDAPFederationMapperFactorySubclass.createMapper</literal> method).
</para>
<para>
After your code is written you must package up all your classes within a JAR file. This jar file must contain a file called
<literal>org.keycloak.mappers.UserFederationMapperFactory</literal> within the <literal>META-INF/services directory</literal> of the JAR. This file is a list of fully
qualified classnames of all implementations of <literal>UserFederationMapperFactory</literal>. For more details, look at section for
<link linkend="write_federation_provider">Write your own federation provider</link> and at <link linkend="providers">Providers and SPI</link> section.
</para>
</section>
</section>
<section>
<section id="write_federation_provider">
<title>Writing your own User Federation Provider</title>
<para>
The keycloak examples directory contains an example of a simple User Federation Provider backed by