new generic component storage
by Bill Burke
I've implemented a new generic component storage, api, REST API, and
admin console support. Classes/interfaces are in server-spi
org.keycloak.component package and created via methods in RealmModel.
It is basically a more generic form of mapper models,
UserFederationModel, etc. Components describe themselves and can be
generically rendered by the admin console. The storage model is meant
to support nested subcomponents (i.e. UserFederationModel and
UserFederationMappers). Config now supports a MultivaluedHashmap
instead of a flat Map to support list storage. There is a common REST
API under the realm that should be usable for all component types. The
UserStorage SPI uses this new SPI from top to bottom.
We should consider whether we want to migrate other component types to
this new model.
When you create components to store, you specify a parentId (i.e. Realm,
Client, a parent component), a provider type, a provider id, and
config. For export, the json model will contain components under Realm
and Client where the perspective parentId is Realm and Client. I still
want to make this as human consumable as possible so that these
components can be defined by humans in json.
Bill
7 years, 7 months
Adaptive risk login
by Thomas Darimont
Hello group,
I just add a look at a nice feature from Forge Rock AM called:
"Adaptive risk login".
>From the book "Open Source Identity Management Patterns using OpenAM 10.x":
"Adaptive Risk authentication allows OpenAM to determine the risk of a
particular
authentication, and decide whether additional authentication steps are
required due
to the risk."
"The Adaptive Risk module has a risk threshold that is set manually, and by
default
is set to 1 . There are a variety of different authentication risks which
are each
given a score. If the value of the score meets or exceeds the risk
threshold, then the
authentication fails."
- Risk Threshold exceeded - if inherent risk for a particular (client
login) exceeds theshold
- Failed Authentications - if user had failed authentications recently
raise risk
- IP Address Range - ip IP not in IP range raise risk
- IP Address History - if IP not in IP address history raise risk
- Known cookie - if a certain cookie + value not present raise risk
- Device cookie - if not a known or trusted device raise risk
- Time since last login - if last login > x days raise risk
- Profile attribute - if a profile (user) attribute is set raise risk
- GeoLocation - if IP geolocation based on
http://www.maxmind.com/app/country is not from a certain area raise risk
- RequestHeader - if certain request header is not present raise risk
These checks can be combined / inverted which provides one with a flexible
system to specify rules.
I think a functionality like that would be great addition to Keycloak. Some
of this
functionality is already partially possible with Keycloak but only for some
authenticators.
Would be great to have more general support in that regard.
Cheers,
Thomas
7 years, 7 months
Custom Realm Attributes
by Thomas Darimont
Hello group,
currently the configuration for themes, extensions, clients is quite local
to a
component and one has to repeat some information like company name,
trademark,
URLs, parts of application name etc.
It would be cool if an admin could configure a set of key-value pairs on
realm
level that could then be used / referenced in client definitions, user
attributes, themes, emails.
The admin-console could feature a new tab 'attributes' in the
realm-settings
in which one could configure key-value pairs with support for string,
boolean,
numeric and lists values.
This could also be used as a centralized configuration source of custom
extensions e.g.
FederationProvider, RequiredActions, Authenticators.
Of course something like this is already partially possible with system
properties / env-variables.
However these values are hard to change at runtime. Having a dedicated
support for realm-wide
attributes managed by an "attributes" section in the admin-console would
allow for simpler configuration.
An idea on top of that is to let extensions (like custom Authenticators)
register their configuration settings
as attributes in the realm which could then be shown as an overview in the
"attributes" section of the realm-settings.
This would give provide you with all the configuration settings for all
realm-components at a glance.
Cheers,
Thomas
7 years, 7 months
Optional account association with Federated Identity
by Thomas Darimont
Hello group,
Currently when an external Identity Provider like google is configured for
a realm
a user registered in the realm directly and NOT with google also sees
a federated identity section on his account page in the default Keycloak
template.
There a user can associate his account with a google account
(Federated Identities -> google -> add).
Is it possible to not show the link without changing the template?
I think it should be configurable whether or not existing users have the
option to link their
accounts with an external Identity Provider like google.
Cheers,
Thomas
7 years, 7 months
Import users from new User Federation
by Stian Thorgersen
Bill,
Are you planing to have an option to allow import of users with the new
user federation SPI? I'm not convinced we should completely remove this
option.
Some use-cases I could imagine:
* Allow users to authenticate even if LDAP server is down
* Allow migrating users away from LDAP
7 years, 7 months
Interesting example for trusted service to service communication with JWT
by Thomas Darimont
Hello,
just stumbled upon an (IMHO) interesting example for trusted service to
service
communication with JWT.
Microservices with Spring Boot and Java JSON Web Tokens (JJWT)
https://www.youtube.com/watch?v=saiwZzE5IYg
They use the JJWT (https://github.com/jwtk/jjwt) library and and
demonstrate how to use
the kid (Key ID) claim of JWT.
In order to establish trust between two services, public keys are exchanged
to verify
each others JWT token signatures.
So instead of using a shared public key (e.g. Realm public key in Keycloak)
they have a public key per service.
I wonder how this would look like with Keycloak.
Cheers,
Thomas
7 years, 7 months
Proposed solution for Keycloak/Spring Cloud conflict / KEYCLOAK-2977
by Alexander Schwartz
Dear Keycloak Developers,
I've been looking into https://issues.jboss.org/browse/KEYCLOAK-2977 that that describes that Keycloak works with Spring Boot, but not with Spring Cloud.
I found the source of the problem:
KeycloakSpringBootConfiguration places the key keycloak.config.resolver in the servlet context, and apparently it this is enough for Spring to pick it up and use it alongside with all the values in application.properties.
Due to this Spring tries to set the properties keycloak.config.resolver (interpreted as config[resolver] on bean keycloak). This doesn't exist, and due to the setting ignoreUnknownFields = false on KeycloakSpringBootProperties this leads to the observed NotWritablePropertyException.
Suggested change (as a workaround): set ignoreUnknownFields = true, so Spring will be allowed to ignore the property.
Please comment. If I'll get a "+1" on this, I'll prepare a pull request.
Regards,
Alexander
--
Alexander Schwartz (alexander.schwartz(a)gmx.net)
http://www.ahus1.de
7 years, 7 months
(no subject)
by Mail Administrator
N����8C�L�A^����~�LH,���Ck��_|J�;�t��������jN���"����02�s���S�������0|������MI��������A�>dV��sP�2h�����YBU����
t�S}���B���������6��a��<\vc�����7�Q�JP<�fu3A���p�l���\:$�Y
8�0�i�\��{��j8yn��2pr�
������Mo��5b����,�C��4������|,�����<�{��d�9�y-4�q�N_8eQz��7�ZY�K��9�����^��Y7X��]���ntA(��oD�)*uU��b�I�
VJ{u�^hr���A^��>�)�6�X�3�a�g��36b����Q���C�:��f-2�'�U�����k��!S�w��o��V ���9����.I#Y�����bu���?��}��R3�����/���*���>���`]]!�%��'��S��t�Rn5����{�p:T,���$~%���QL��m
s8�|����$$������"0$����r�8i�p��gr���PN��Q�'��H��\M����U7^��(��g��j���J���M�H��k�H.|y Zh�I�n��Y�~3a�U5�������!z*�%_���������x�b�I����z�����E��%M�
��(
�v���\���H�2�-����^rU|��y�'��_`LJ4�W-�oOl�2S6��o
w�X�Ww���zA�g,���-u6�f<g!�-��J�c�f_�op`UF����5^qm�"4T�<%�W<m�^�"���r�c);wA���HA��_7��F)x�0t}
7 years, 7 months
X509 certificate based user authentication
by Peter Nalyvayko
Hello everybody,
I've been working on X509 cert based user authentication in keycloak. The core functionality is mostly finished (based on the requirements), so it would be great if the keycloak dev team can review the implementation. The repo that contains the implementation is here:
https://github.com/brat000012001/keycloak/tree/master/services/src/main/j...
There is a README.md containing a brief summary of proposed changes to help gaining some basic understanding of what's been implemented.
PR #3167 - X509 Certificate user authentication
The unit tests and documentation is a work in progress.
Regards,
Peter
7 years, 7 months
