The Client policies feature was a preview feature since Keycloak 12 and did not have proper support. If you tried this feature and configured some client policies or client profiles
in Keycloak 12 or Keycloak 13, then you will need to configure your client policies and client profiles again in the new version. The format of the configuration changed significantly
as it was only a preview and hence we do not provide automatic migration of client policies and client profiles created in Keycloak 12 or Keycloak 13.
section to handle the migration of configuration files automatically. However, here are the most important changes, which you may need
if you made your own configuration changes:
* The link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Config_SmallRye[Eclipse MicroProfile Config], link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Health_SmallRye[Eclipse MicroProfile Health], and link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Metrics_SmallRye[Eclipse MicroProfile Metrics] subsystems are replaced with link:https://docs.wildfly.org/22/Admin_Guide.html#Health[WildFly subsystem for health] and link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Metrics_SmallRye[WildFly subsystem for base metrics].
* The default Wildfly configuration now uses the ability to make use of an automatically generated self-signed certificate with Elytron. Refer to link:https://docs.wildfly.org/22/WildFly_Elytron_Security.html#update-wildfly-to-use-the-default-elytron-components-for-application-authentication[a dedicated `applicationSSC` server SSL context section] for details.
* X.509 authenticator with custom attribute for mapping the X.509 certificate to the user identity
* Any other custom functionality, where some of the user attributes are used as the metadata for storing authentication/authorization/identity context rather
If you use the OpenID Connect parameter `request_uri`, a requirement exists that your client needs to have `Valid Request URIs` configured.
This can be configured through the admin console on the client details page or through the admin REST API or client registration API. Valid Request URIs need
to contain the list of Request URI values, which are permitted for the particular client. This is to avoid SSRF attacks. There is possibility to use wildcards
or relative paths similarly such as the `Valid Redirect URIs` option, however for security purposes, we typically recommend to use as specific value
The {project_name} server was upgraded to use Wildfly 22 as the underlying container. This does not directly involve any
specific {project_name} server functionality, but a few changes related to the migration, which are worth mentioning.
Dependency updates::
The dependencies were updated to the versions used by Wildfly 22 server. For example, Infinispan is now `11.0.8.Final`.
Configuration changes::
A few configuration changes exist in the `standalone(-ha).xml` and `domain.xml` files. You should follow the <<_install_new_version>>
section to handle the migration of configuration files automatically. If more detail is needed, because, for example, you did some
configuration changes on your own, the list of the most important changes follows:
* The link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Config_SmallRye[Eclipse MicroProfile Config], link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Health_SmallRye[Eclipse MicroProfile Health], and link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Metrics_SmallRye[Eclipse MicroProfile Metrics] subsystems were replaced by link:https://docs.wildfly.org/22/Admin_Guide.html#Health[WildFly subsystem for health] and link:https://docs.wildfly.org/22/Admin_Guide.html#MicroProfile_Metrics_SmallRye[WildFly subsystem for base metrics].
* The default Wildfly configuration now utilizes the ability to make use of an automatically generated self-signed certificate with Elytron. Refer to link:https://docs.wildfly.org/22/WildFly_Elytron_Security.html#update-wildfly-to-use-the-default-elytron-components-for-application-authentication[a dedicated `applicationSSC` server SSL context section] for details.
==== Skip creation of user session for the Docker protocol authentication
No user session is created after successful authentication with the Docker protocol. For details, please refer to the link:{adminguide_link}#_docker[{adminguide_name}].
==== Client Credentials Grant without refresh token by default
From this {project_name} version, the OAuth2 Client Credentials Grant endpoint does not issue refresh tokens by default. This behavior is aligned with the OAuth2 specification.
As a side effect of this change, no user session is created on the {project_name} server side after successful Client Credentials authentication, which results
For backwards compatibility, a possibility to stick to the behavior of old versions exists. When this is used, the refresh token will be still issued after
a successful authentication with the Client Credentials Grant and also the user session will be created. This can be enabled for the particular client in
the {project_name} admin console, in client details in the section with `OpenID Connect Compatibility Modes` with the switch `Use Refresh Tokens For Client Credentials Grant`.
In the previous {project_name} version, when the LDAP provider was configured with `Import Users` OFF, it was possible to update the
user even if some of non-LDAP mapped attributes were changed. This situation resulted in confusing behavior, when the attribute appeared to be updated,
but it was not. In the current version, the update is not allowed to be performed at all if any non-LDAP mapped attributes are changed.
This should not affect most of the deployments, but some can be affected under some rare circumstances. For example if you previously
tried to update a user with the admin REST API and the user had some incorrect attribute changes, the update was possible. With the
current version, the update is not possible and you will be immediately informed about the reason.
The fields `username`, `email`, `firstName` and `lastName` in the `UserModel` are migrated to custom attributes as a preparation for adding more sophisticated user profiles to {project_name} in an upcoming version.
If a database contains users with custom attributes of that exact name, the custom attributes will need to be migrated before upgrading. This migration does not occur automatically. Otherwise, they will not be read from the database anymore and possibly deleted.
This situation implies that the `username` can now also be accessed and set via `UserModel.getFirstAttribute(UserModel.USERNAME)`. Similar implications exist for other fields.
Implementers of SPIs subclassing the `UserModel` directly or indirectly should ensure that the behavior between `setUsername` and `setSingleAttribute(UserModel.USERNAME, ...)` (and similar for the other fields) is consistent.
Users of the policy evaluation feature have to adapt their policies if they use the number of attributes in their evaluations since every user will now have four new attributes by default.
REQUIRED and ALTERNATIVE executions not supported at same flow::
In previous version, it was possible to have REQUIRED and ALTERNATIVE executions in the same authentication flow at the same level.
There were some issues with this approach and we did the refactoring in the Authentication SPI, which means that this is not considered
valid anymore. If ALTERNATIVE and REQUIRED executions are configured at the same level, the ALTERNATIVE executions are considered disabled.
So when migrating to the newest version, your existing authentication flows will be automatically migrated preserved the same behavior as existed in the previous version.
If they contain ALTERNATIVE executions at the same level as some REQUIRED executions, then the ALTERNATIVE executions will be added to the separate REQUIRED subflow. This
should ensure same/similar behavior of the particular authentication flow as in the previous version. We always recommend
In the previous releases, developers were allowed to provide client credentials to the JavaScript adapter. For now on, this capability was *removed*, because client-side apps are not safe to keep secrets.
but you may be affected if you're developing more advanced authenticators, which introduce some new credential types (subclasses of `CredentialModel`).
There are changes on the `CredentialProvider` interface and introduction of some new interfaces like `CredentialValidator`. Also you
We have added a new `microprofile-jwt` optional client scope to handle the claims defined in the https://github.com/eclipse/microprofile/wiki/JWT_Auth[MicroProfile/JWT Auth Specification].
for the Google+ API in favor of the new Google Sign-in authentication system. The {project_name} identity provider has been updated
to use the new endpoints so if this integration is in use make sure you upgrade to {project_name} version 4.8.2 or later.
If you run into an error saying that the application identifier was not found in the directory, you will have to register the client application again in the
Accordingly with LinkedIn, all developers need to migrate to version 2.0 of their APIs and OAuth 2.0. As such, we have updated
our LinkedIn Social Broker.
Existing deployments using this broker may start experiencing errors when fetching user's profile using version 2 of
LinkedIn APIs. This error may be related with the lack of permissions granted to the client application used to configure the broker
which may not be authorized to access the Profile API or request specific OAuth2 scopes during the authentication process.
Even for newly created LinkedIn client applications, you need to make sure that the client is able to request the `r_liteprofile` and
`r_emailaddress` OAuth2 scopes, at least, as well that the client application can fetch current member's profile from the `https://api.linkedin.com/v2/me` endpoint.
Due to these privacy restrictions imposed by LinkedIn in regards to access to member's information and the limited set of claims returned by the
current member's Profile API, the LinkedIn Social Broker
is now using the member's email address as the default username. That means that the `r_emailaddress` is always set when
sending authorization requests during the authentication.
Prior to UMA 2.0 (UMA 1.0), client applications were using the Authorization API to obtain permissions from the server in the format of an RPT. The new version
of UMA specification has removed the Authorization API which was also removed from {project_name}. In UMA 2.0, RPTs can now be obtained from the token endpoint by using a specific grant type.
See link:{authorizationguide_link}#_service_obtaining_permissions[{authorizationguide_name}] for details.
Entitlement API was removed::
With the introduction of UMA 2.0, we decided to leverage the token endpoint and UMA grant type to allow obtaining RPTs from {project_name} and
avoid having different APIs. The functionality provided by the Entitlement API was kept the same and is still possible to obtain permissions for a set
of one or more resources and scopes or all permissions from the server in case no resource or scope is provided.
See link:{authorizationguide_link}#_service_obtaining_permissions[{authorizationguide_name}] for details.
Changes to UMA Discovery Endpoint::
UMA Discovery document changed, see link:{authorizationguide_link}#_service_authorization_api[{authorizationguide_name}] for details.
Changes to {project_name} Authorization JavaScript adapter::
The {project_name} Authorization JavaScript adapter (keycloak-authz.js) changed in order to comply with the changes introduced by UMA 2.0 while keeping
the same behavior as before. The main change is on how you invoke both `authorization` and `entitlement` methods which now
expect a specific object type representing an authorization request. This new object type provides more flexibility on how
permissions can be obtained from the server by supporting the different parameters supported by the UMA grant type.
One of the main changes introduced by this release is that you are no longer required to exchange access tokens with RPTs in
order to access resources protected by a resource server (when not using UMA). Depending on how the policy enforcer is configured on the resource server side, you can just send regular
access tokens as a bearer token and permissions will still be enforced.
Changes to {project_name} Authorization Client Java API::
When upgrading to the new version of {project_name} Authorization Client Java API, you'll notice that some representation classes
were moved to a different package in `org.keycloak:keycloak-core`.
==== Added session_state parameter to OpenID Connect Authentication Response
The OpenID Connect Session Management specification requires that the parameter `session_state` is present in the OpenID Connect Authentication Response.
In past releases, we did not have this parameter, but now {project_name} adds this parameter by default, as required by the specification.
However, some OpenID Connect / OAuth2 adapters, and especially older {project_name} adapters, may have issues with this new parameter.
For example, the parameter will be always present in the browser URL after successful authentication to the client application.
In these cases, it may be useful to disable adding the `session_state` parameter to the authentication response. This can be done
for the particular client in the {project_name} admin console, in client details in the section with `OpenID Connect Compatibility Modes`,
We've added two new password hashing algorithms (pbkdf2-sha256 and pbkdf2-sha512). New realms will use the pbkdf2-sha256
hashing algorithm with 27500 hashing iterations. Since pbkdf2-sha256 is slightly faster than pbkdf2 the iterations was
increased to 27500 from 20000.
Existing realms are upgraded if the password policy contains the default value for hashing algorithm (not specified) and
iteration (20000). If you have changed the hashing iterations you need to manually change to pbkdf2-sha256 if you'd like
to use the more secure hashing algorithm.
==== ID Token requires scope=openid
OpenID Connect specification requires that parameter `scope` with value `openid` is used in initial authorization request. So in {project_name}
2.1.0 we changed our adapters to use `scope=openid` in the redirect URI to {project_name}. Now we changed the server part too and ID token
will be sent to the application just if `scope=openid` is really used. If it's not used, then ID token will be skipped and just Access token and Refresh token will be sent to the application.
Direct grants (OAuth2 Resource Owner Password Credentials Grant) and Service accounts login (OAuth2 Client credentials grant) also don't use ID Token by default now.
You need to explicitly add `scope=openid` parameter to have ID Token included.
==== Authentication sessions and Action tokens
We are working on support for multiple datacenters. As the initial step, we introduced authentication session and action tokens.
Authentication session replaces Client session, which was used in previous versions. Action tokens are currently used especially for the scenarios, where
the authenticator or requiredActionProvider requires sending email to the user and requires user to click on the link in email.
Here are concrete changes related to this, which may affect you for the migration.
First change related to this is introducing new Infinispan caches `authenticationSessions` and `actionTokens` in `standalone.xml` or `standalone-ha.xml`. If you use our migration CLI, you
We also added some initial support for sticky sessions. You may want to change your load balancer/proxy server and configure it if you don't want to suffer from it and want to have better performance.
The route is added to the new `AUTH_SESSION_ID` cookie. More info in the clustering documentation.
Another change is, that `token.getClientSession()` was removed. This may affect you for example if you're using Client Initiated Identity Broker Linking feature.
The `ScriptBasedAuthenticator` changed the binding name from `clientSession` to `authenticationSession`, so you would need to update your scripts if you're using this authenticator.
Finally we added some new timeouts to the admin console. This allows you for example to specify different timeouts for the email actions triggered by admin and by user himself.
=== Migrating to 2.5.1
==== Migration of old offline tokens
If you migrate from version 2.2.0 or older and you used offline tokens, then your offline tokens didn't have KID in the token header.
We added KID to the token header in 2.3.0 together with the ability to have multiple realm keys, so {project_name} is able to find the correct key based on the token KID.
For the offline tokens without KID, {project_name} 2.5.1 will always use the active realm key to find the proper key for the token verification. In other words, migration of old
offline tokens will work. So for example, your user requested offline token in 1.9.8, then you migrate from 1.9.8 to 2.5.1 and then your user will be
still able to refresh his old offline token in 2.5.1 version.
The `realms` cache defined in the infinispan subsystem in `standalone.xml` or `standalone-ha.xml` configuration file, now has the eviction with the 10000 records by default.
what records in underlying `realms` and `users` caches should be invalidated.
=== Migrating to 2.3.0
==== Default max results on paginated endpoints
All Admin REST API endpoints that support pagination now have a default max results set to 100. If you want to return
more than 100 entries you need to explicitly specify that with `?max=<RESULTS>`.
==== `realm-public-key` adapter property not recommended
In 2.3.0 release we added support for Public Key Rotation. When admin rotates the realm keys in Keycloak admin console, the Client
Adapter will be able to recognize it and automatically download new public key from Keycloak. However this automatic download of new
keys is done just if you don't have `realm-public-key` option in your adapter with the hardcoded public key. For this reason, we don't recommend
to use `realm-public-key` option in adapter configuration anymore.
Note this option is still supported, but it may be useful just if you really want to have hardcoded public key in your adapter configuration
and never download the public key from Keycloak. In theory, one reason for this can be to avoid man-in-the-middle attack if you have untrusted network between adapter and Keycloak,
however in that case, it is much better option to use HTTPS, which will secure all the requests between adapter and Keycloak.
In this release, we added new cache `keys` to the infinispan subsystem, which is defined in `standalone.xml` or `standalone-ha.xml` configuration file.
It has also some eviction and expiration defined. This cache is internally used for caching the external public keys of the entities
trusted by the server (Identity providers or clients, which uses authentication with signed JWT).
and `migrationStrategy`. `initializeEmpty` can bet set to `true` or `false` and controls if an empty database should
be initialized. `migrationStrategy` can be set to `update`, `validate` and `manual`. `manual` is only supported for
relational databases and will write an SQL file with the required changes to the database schema. Please note that
for Oracle database, the created SQL file contains `SET DEFINE OFF` command understood by Oracle SQL clients.
Should the script be consumed by any other client, please replace the lines with equivalent command of the tool of
your choice that disables variable expansion or remove it completely if such functionality is not applicable.
==== Changes in Client's Valid Redirect URIs
The following scenarios are affected:
* When a Valid Redirect URI with query component is saved in a Client (e.g. `\http://localhost/auth?foo=bar`), `redirect_uri` in authorization request must exactly match this URI (or other registered URI in this Client).
* When a Valid Redirect URI without a query component is saved in a Client, `redirect_uri` must exactly match as well.
* Wildcards in registered Valid Redirect URIs are no longer supported when query component is present in this URI, so the `redirect_uri` needs to exactly match this saved URI as well.
* Fragments in registered Valid Redirect URIs (like `\http://localhost/auth#fragment`) are no longer allowed.
==== Authenticate by default removed from Identity Providers
Identity providers no longer has an option to set it as a default authentication provider. Instead go to Authentication, select the `Browser` flow and configure the `Identity Provider Redirector`. It has an option to set the default identity provider.
We've moved the themes and providers directories from `standalone/configuration/themes` and `standalone/configuration/providers` to `themes` and `providers` respectively.
If you have added custom themes and providers you need to move them to the new location.
You also need to update `keycloak-server.json` as it's changed due to this.
Previously, if you had installed our SAML or OIDC Keycloak subsystem adapters into WildFly or JBoss EAP, we would automatically include Keycloak client jars into EVERY application regardless if you were using Keycloak or not.
These libraries are now only added to your deployment if you have Keycloak authentication turned on for that adapter (via the subsystem, or auth-method in web.xml)
==== Session state parameter in authentication response renamed
In the OpenID Connect authentication response we used to return the session state as `session-state` this is not correct according to the specification and has been renamed to `session_state`.
==== Deprecated OpenID Connect endpoints
In 1.2 we deprecated a number of endpoints that where not consistent with the OpenID Connect specifications, these have now been removed.
To plug a security attack vector, for platforms that support it (Tomcat 8, Undertow/WildFly), the Keycloak OIDC and SAML adapters will change the session id after login.
The `/realms/{realm-name}/protocols/openid-connect/validate` endpoint is now deprecated and we strongly recommend you to move to the new introspection endpoint as soon as possible.
The new token introspection URL can now be obtained from OpenID Connect Provider's configuration at `/realms/{realm-name}/.well-known/openid-configuration`.
There you will find a claim with name `token_introspection_endpoint` within the response.
Only `confidential clients` are allowed to invoke the new endpoint, where these clients will be usually acting as a resource server and looking for token metadata in order to perform local authorization checks.
=== Migrating to 1.7.0.CR1
==== Direct access grants disabled by default for clients
In order to add more compliance with OpenID Connect specification, we added flags into admin console to Client Settings page, where you can enable/disable various kinds of OpenID Connect/OAuth2 flows (Standard flow, Implicit flow, Direct Access Grants, Service Accounts). As part of this, we have `Direct Access Grants` (corresponds to OAuth2 `Resource Owner Password Credentials Grant`) disabled by default for new clients.
Clients migrated from previous version have `Direct Access Grants` enabled just if they had flag `Direct Grants Only` on.
The `Direct Grants Only` flag was removed as if you enable Direct Access Grants and disable both Standard+Implicit flow, you will achieve same effect.
We also added built-in client `admin-cli` to each realm.
This client has `Direct Access Grants` enabled.
So if you're using Admin REST API or Keycloak admin-client, you should update your configuration to use `admin-cli` instead of `security-admin-console` as the latter one doesn't have direct access grants enabled anymore by default.
==== Option 'Update Profile On First Login' moved from Identity provider to Review Profile authenticator
In this version, we added `First Broker Login`, which allows you to specify what exactly should be done when new user is logged through Identity provider (or Social provider), but no Keycloak user linked to the social account exists yet.
As part of this work, we added option `First Login Flow` to identity providers where you can specify the flow and then you can configure this flow under `Authentication` tab in admin console.
We also removed the option `Update Profile On First Login` from the Identity provider settings and moved it to the configuration of `Review Profile` authenticator.
So once you specify which flow should be used for your Identity provider (by default it's `First Broker Login` flow), you go to `Authentication` tab, select the flow and then you configure the option under `Review Profile` authenticator.
==== Element 'form-error-page' in web.xml not supported anymore
form-error-page in web.xml will no longer work for client adapter authentication errors.
You must define an error-page for the various HTTP error codes.
See documentation for more details if you want to catch and handle adapter error conditions.
We added `First Broker Login` flow in this release and the method `IdentityProviderMapper.importNewUser` is now called after `First Broker Login` flow is finished.
So if you want to have any attribute available in `Review Profile` page, you would need to use the method `preprocessFederatedIdentity` instead of `importNewUser` . You can set any attribute by invoke `BrokeredIdentityContext.setUserAttribute` and that will be available on `Review profile` page.
=== Migrating to 1.6.0.Final
==== Option that refresh tokens are not reusable anymore
Old versions of Keycloak allowed reusing refresh tokens multiple times.
Keycloak still permits this, but also have an option `Revoke refresh token` to disallow it.
For example if you are using multitenancy and KeycloakConfigResolver, you will be affected as for example class HttpFacade was moved to different package - it is `org.keycloak.adapters.spi.HttpFacade` now.
==== Persisting user sessions
We added support for offline tokens in this release, which means that we are persisting "offline" user sessions into database now.
If you are not using offline tokens, nothing will be persisted for you, so you don't need to care about worse performance for more DB writes.
However in all cases, you will need to update `standalone/configuration/keycloak-server.json` and add `userSessionPersister` like this:
For anyone that wants to achieve increased durability of user sessions this can be achieved by configuring the user session cache with more than one owner or use a replicated cache.
It's also possible to configure Infinispan to persist caches, although that would have impacts on performance.
==== Contact details removed from registration and account management
In the default theme we have now removed the contact details from the registration page and account management.
The admin console now lists all the users attributes, not just contact specific attributes.
The admin console also has the ability to add/remove attributes to a user.
If you want to add contact details, please refer to the address theme included in the examples.
Application and OAuth clients are now merged into `Clients`.
The UI of admin console is updated and database as well.
Your data from database should be automatically updated.
The previously set Applications will be converted into Clients with `Consent required` switch off and OAuth Clients will be converted into Clients with this switch on.
=== Migrating from 1.1.0.Final to 1.2.0.Beta1
==== Database changed
This release contains a number of changes to the database.
If you're using our adapters no change is required, except if you've been using bearer-only without specifying the `auth-server-url`, you have to add it now.
If you're using another library (or RSATokenVerifier) you need to make the corresponding changes when verifying `iss`.
==== OpenID Connect endpoints
To comply with OpenID Connect specification the authentication and token endpoints have been changed to having a single authentication endpoint and a single token endpoint.
As per-spec `response_type` and `grant_type` parameters are used to select the required flow.
The old endpoints (`/realms/{realm-name}/protocols/openid-connect/login`, `/realms/{realm-name}/protocols/openid-connect/grants/access`, `/realms/{realm-name}/protocols/openid-connect/refresh`, `/realms/{realm-name}/protocols/openid-connect/access/codes`) are now deprecated and will be removed in a future version.
The directory hierarchy used to be `type/name` this is now changed to `name/type`.
For example a login theme named `sunrise` used to be deployed to `standalone/configuration/themes/login/sunrise`, which is now moved to `standalone/configuration/themes/sunrise/login`.
We did migration scripts for both RDBMS and Mongo, which should ensure that claims configured for particular application/client will be converted into corresponding protocol mappers (Still it's safer to back up DB before migrating to newer version though). Same applies for exported JSON representation from previous version.
* JavaScript adapter now has idToken and idTokenParsed properties. If you use idToken to retrieve first name, email, etc. you need to change this to idTokenParsed.
* The as7-eap-subsystem and keycloak-wildfly-subsystem have been merged into one keycloak-subsystem. If you have an existing standalone.xml
or domain.xml, you will need edit near the top of the file and change the extension module name to org.keycloak.keycloak-subsystem.
For AS7 only, the extension module name is org.keycloak.keycloak-as7-subsystem.
* Server installation is no longer supported on AS7. You can still use AS7 as an application client.
=== Migrating from 1.0.x.Final to 1.1.0.Beta1
* RealmModel JPA and Mongo storage schema has changed
* UserSessionModel JPA and Mongo storage schema has changed as these interfaces have been refactored
* Upgrade your adapters, old adapters are not compatible with Keycloak 1.1. We interpreted JSON Web Token and OIDC ID Token specification incorrectly. 'aud'
claim must be the client id, we were storing the realm name in there and validating it.
=== Migrating from 1.0 RC-1 to RC-2
* A lot of info level logging has been changed to debug. Also, a realm no longer has the jboss-logging audit listener by default.
If you want log output when users login, logout, change passwords, etc. enable the jboss-logging audit listener through the admin console.
=== Migrating from 1.0 Beta 4 to RC-1
* logout REST API has been refactored. The GET request on the logout URI does not take a session_state
parameter anymore. You must be logged in in order to log out the session.
You can also POST to the logout REST URI. This action requires a valid refresh token to perform the logout.
The signature is the same as refresh token minus the grant type form parameter. See documentation for details.
=== Migrating from 1.0 Beta 1 to Beta 4
* LDAP/AD configuration is changed. It is no longer under the "Settings" page. It is now under
Users->Federation. Add Provider will show you an "ldap" option.
* Authentication SPI has been removed and rewritten. The new SPI is UserFederationProvider and is
