I'm trying to include keycloak in my application based on Spring 4 MVC but I see that all the examples are on Spring Boot. No way to include keycloak in Sping MVC?
I hope you can help me !!!
>From already thank you very much
I've just been playing with the client registration cli and it's just plain
# kcreg.sh create myclient.json
Is so much better than:
# Open admin console
# Click clients
# Click create
# Click import file
# Click save
Nice work :)
for KEYCLOAK-3410 "Ease creating user with initial roles via REST I" filed
PR https://github.com/keycloak/keycloak/pull/3120 in which the need arose
to selectively include details within a Representation returned by a REST
In this concrete case I made it easier to create users with an initial set
via the Keycloak admin client which I learned in some projects is a common
Previously roles passed to the UserRepresentation were ignored when
creating a user via the Keycloak admin client and a user had to create the
roles in a second step after the creation of the user which required
multiple HTTP requests.
With the changes within the mentioned PR clients can create a user with a
set of predefined roles
with a single HTTP request like the following:
UserRepresentation user = new UserRepresentation();
Response response = keycloak.realm(realmName).users().create(user);
For symmetry reasons I also changed the
method to return the configured Realm/ClientRoles with just one HTTP
One downside of this is that this could potentially lead to unexpected
performance problems since a user could have many roles assigned, also
currently the admin console issues some UsersResource#getUser(String)
requests which would (currently) ignore the returned rows.
Stian and I had some discussions on how this could be solved - among the
discussed options were:
1) just return the Realm/ClientRoles and document the potential performance
2) introduce some sort of ?include=[String ... categories] parameter in the
Keycloak client API
which would allow a client to control what would be returned in the
3) Introduce a new dedicated endpoint UsersResource#getUserDetails(String
userId) to return the full UserRepresentation with the roles.
4) Use Media-Types like application/vnd.keycloak-user+json and
application/vnd.keycloak-user-details+json to control the data of the
Since all of those mentioned options come with some pros and cons we'd like
to reach out to you folks to help us to find the best solution possible.
Since this problem also arises for other representations like clients /
groups, realms etc.
it would be beneficial for the sake of a consistent API to find a general
solution how to proceed here.
Looking forward to your feedback.
I've removed the themes jar from the server distribution and at the same
time made all built-in theme resources read-only so users don't edit them
I've also removed from unused files from the common resources for themes
(files for third party libraries).
There is one strange thing for ProviderConfigProperties, which uses type
LIST. For those, the "defaultValue" field doesn't really use
defaultValue of particular field, but instead it contains list of
available values to be selected in combobox for particular config property.
IMO this is not good because of:
* Field "defaultValue" is used for something, which is not really
defaultValue. It's a bit confusing IMO. Note once we're adding supported
UserStorage SPIs, then customers may need to add their own properties of
type "List" . So this is not just Keycloak implementation detail, but
it's exposed externally.
* It's not easily possible to set the actual defaultValue for list
because field "defaultValue" is occupied by the list of available values.
How about adding new field like "availableValues" to
ProviderConfigProperty and refactor existing impls to use this one instead?
I've added support for Dynamic client registration policies to the master.
Summary of changes:
* Admin console tab "Initial Access Tokens" was renamed to "Client
Registrations" . It has 2 subtabs now "Initial Access Tokens" and
"Client Registration Policies" .
* Previous "Trusted hosts" stuff was renamed from UI (still need to do
some model cleanup...)
* Client Registration Policies tab exposes the configured client
registration policies for the realm. I've added new
ClientRegistrationPolicy SPI based on generic component model.
* There are 2 kinds of client registration policies.
** Authenticated - Those are used when clientRegistration request with
initial-access-token or with bearer-token comes.
** Anonymous - Those are used when clientRegistration request without
initial-access-token or without bearer-token comes. Also it's used for
update requests with registrationToken for clients, which were
registered through anonymous registration.
* Implementations of clientRegistrationPolicies:
** TrustedHostClientRegistrationPolicy - Allows to configure trusted
hosts (by IP Address or by hostname) and domains. ClientRegistration
request needs to come from some trusted host or domain, otherwise it's
rejected. Also all the client uris (redirect_uris etc) needs to match
some trusted host or domain. By default there is not any trusted host
configured. Hence anonymous clientRegistrations, which uses this policy
by default, are always rejected by default unless you specify some
** ConsentRequiredClientRegistrationPolicy - newly registered clients
will automatically have consentRequired enabled. Also it's not possible
to update them to switch consentRequired to off.
** ScopeClientRegistrationPolicy - newly registered clients will
automatically have fullScopeAllowed disabled. Also it's not possible to
update them to switch fullScopeAllowed to on.
** ProtocolMapperClientRegistrationPolicy - newly registered clients
can't use any protocolMapper implementations besides those, which are
whitelisted. By default, the whitelisted includes few types, mostly
those which we already as builtin mappers (User Property Mapper, USer
Attribute Mapper, Full name mapper etc)
** ClientTemplateClientRegistrationPolicy - newly registered or updated
clients can't have any clientTemplate, which is not whitelisted. By
default, there is not any whitelisted clientTemplate
* Authenticated policies - There are 2 policies by default. One for
protocol mappers and one for clientTemplate.
* Anonymous policies - Contains all 5 policies configured. In other
words, newly registered clients need to come from trusted hosts, have
fullScopeAllowed disabled and consentRequired enabled and can't have
non-whitelisted protocolMappers and clientTemplates.
* Some generic changes:
** Added 2 types of ProviderConfigProperty
*** MultivaluedString - allows to specify more string values of some
attribute. Something like redirectUris or webOrigins for client.
*** MultivaluedList - allows to specify more string values, which needs
to be selected from the list of pre-defined allowed values. Something
like "requiredActions" for user.
** Added field "subType" to ComponentModel. This is because for
clientRegistrationPolicies, I have 2 kinds of policies with same type
and same parentId (same realm), but I still need to differentiate
Remaining TODOs (maybe some more based on feedback) :
* It seems I broke Wildfly distribution. I will fix ASAP today.
* I've just created KEYCLOAK-3712 Client Registration limitations - In
shortcut, our default implementations of ClientRegistrationProvider
doesn't allow to CRUD client roles, scope mappings, service account
roles or authorization settings of client. It also doesn't allow to
update of protocolMappers. Not sure if we need to address this for this
release? If yes, then Scope policy should be enhanced to also support
whitelisting of scoped roles.
* Some cleanup (logging messages, cleanup of infinispan model for
previous "trusted hosts" thing)
I started to look at https://issues.jboss.org/browse/KEYCLOAK-3625 . The
fix is to send back a String containing just "changed" or "unchanged" from
the iframe to the main window, instead of a whole JSON like we do now.
Most of the refactoring is doable but there is one point on which I'm
really stuck :
The JS library maintain a callBack map that contains promises, the key is a
ID that we generate and that we pass to the iframe. When the iframe sends
back a message to the main Window it passes also the ID, so that we can
retrieve the correct promise to resolve it (or not).
But now since we return just a String, I don't know how we can retrieve the
correct promise from the callBack map.
Does anyone have an idea ?