sticky sessions, clustering, and authentication
by Bill Burke
I was thinking a bit about performance in a cluster. Right now a client
session is created whenever login is initiated. This ends up requiring
the client session to be propagated to the cluster, either through a
database insert/update or an infinispan replication. Then, with each
authentication/required action step, another insert/update/replication.
I was thinking we should have an AuthenticationSession that was in
memory only. Then, once all authentication and required actions are
finished, then create the usersession and client session. This would
require sticky sessions though with a load balancer.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 6 months
Client Credential Grant
by Akshay Ransing
Hi,
Can anyone point me towards documentation for using Client Credential Grant
way of obtaining for access token for confidential client in Keycloak.
I have some APIs on my resource server which are not specific to resource
owner but client applications. (closer example can be "Checkout as guest"
option on any e-commerce site where user is not interested in signup but do
want to access multiple API from resource server)
https://tools.ietf.org/html/rfc6749#page-40 *point 4.4*
--
Thanks & Regards
Akshay Ransing
+918793858910
9 years, 6 months
Direct grant always on
by Stian Thorgersen
I propose we remove the option to enable/disable direct grant and always have it on. Alternatively we need an option to enable it without using the admin console.
This is for users that want to use a CLI, or needs to do some automatic configuration when provisioning a KC.
9 years, 6 months
Federation & LDAP caching
by Marek Posolda
We have still open issue https://issues.jboss.org/browse/KEYCLOAK-838 .
In shortcut, during authentication of user into LDAP there are 9 same
queries to LDAP to load this single user. Similar situation might be for
other federation providers. Few ideas to improve:
1) Simple per-request caching at UserFederationManager level - currently
each call to "session.users().getUserByXXX()" always call "isValid" on
federation provider causing that validation/loading of same user might
be done more time per request. With very simple enhancement at
UserFederationManager level, we ensure that loading of user will be done
just once per request (per KeycloakSession), which is not an issue IMO
as KeycloakSession is really short-living object. Note that this is not
specific to LDAP, but should improve performance of UserFederation in
general. I have very simple patch here
https://github.com/mposolda/keycloak/commit/f8302dac0e927756ca0d49a67500f...
. With this, number of loads to LDAP per authentication is reduced from
9 calls to 3. Any objections against merging it?
2) Global caching - this is obviously much more tricky, but I think that
earlier or later we need to address it as (1) might not be sufficient.
Few ideas:
2.a) Allow to switch the user cache on top of delegation. Currently we
have UserProvider delegation chain like:
User Federation => User Cache Provider => JPA/Mongo UserProvider
The alternative I mean is, that people will have possibility to
configure the chain like:
User Cache Provider => User Federation => JPA/Mongo UserProvider
By default, the order will be still the same like it's now, however I
can imagine that for many LDAP (and other federation) deployments, the
admins use them just as read-only store and don't do any direct changes
here. Hence there is no reason to always validate/proxy users and ask
federation storage if user still exists etc but instead suffer from our
already existing cache impl and enjoy improved performance.
I propose we will just add on/off switch to admin console, which will
allow to specify when cache should be put on top of federation or after
(like it's now). We may also need to add the button to clear the cache.
WDYT?
2.b) Another alternative is to put cache layer on top of
LDAPIdentityStore. TBH I am not the fan of it as it's specific to LDAP
and it requires another implementation of caching with all the pitfalls
(Figure which items should be invalidated during writes, abstraction to
support both "mem" and cluster/infinispan deployments etc...)
my proposal is to go with (1) for this release and then look at (2.a)
if I have time as it may be another few days of work (so maybe postpone
to next release)
WDYT, other better ideas to improve?
Marek
9 years, 7 months
Proposal of few improvements related to "Social registration" page flows
by Vlastimil Elias
Hi,
we just advanced to UAT phase of our project where we use Keycloak 1.2.0
final for user management, and we got feedback from testers.
They proposed few improvements related to "Social registration" flows
over OAuth identity providers (github, google, ...).
1. Perform "Update Profile on First Login" only if some of mandatory
user profile fields is missing
Current "Update Profile on First Login" setting in "Identity provider"
configuration is on/off switch only. But response from some identity
providers (like Github, Facebook) differs for distinct users, email is
returned sometimes and sometimes not. We would like to show "Update
Profile" page on first login only for users without email address
(generalized a bit means without some of mandatory user profile info,
which is currently email, name and surname) to simplify user flow for
other users.
Best implementation is probably to change "Update Profile on First
Login" option in "Identity provider" configuration from On/Off switch to
a select with three values:
"On", "On missing only", "Off".
2. Do not perform email verification if email is provided by trusted
Identity provider
If "Verify email" option is enabled in Settings > Login, then it is
applied to all KC users accounts, both created over registration form
and as result of social login.
We would like to simplify user flow for users who registered over social
provider where we can trust email (like google) and skip this step in
this case.
I see two ways for configuration on per "Identity provider" basis: add
new "Trust email" configuration option into "Identity provider" config
page, or add special Mapper for providers called "Trust email" which
will mark email as verified if provided by given identity provider.
3. Allow to map other informations provided by OAuth Identity providers
into Keycloak user profile attributes
Identity provider configuration contains "Mappers" configuration
already, but only "Hardcoded role" mapper is available here for OAuth
providers.
We should add something like "Attribute Importer" already available for
SAML providers.
4. allow to extend "Update Profile on First Login" page with other
fields stored into user profile attributes
My colleague created an issue for this already -
https://issues.jboss.org/browse/KEYCLOAK-1361
5. Link social account into KC user account if email conflict is
detected and user authenticated afterwards
When user clicks Social login provider on login page, and social
provider returns email which already exists for other KC user, then
login page is shown with error message like "User with email already
exists. Please login to account management to link the account.". This
is really not very user friendly, as user is returned to original
page/application after login and it may be a bit complicated for him to
go into account management page and link account there.
I believe that once user provides correct username and password on this
login page then social account should be automatically linked to KC
account user just authenticated to. Then user should be redirected to
originating application. If this "social account autolink" should be
able to survive "Forgot password" flow then even better ;-)
What do you think about proposed improvements? I believe they are
generic enough to be valuable for all KC users.
I can create JIRA issues for them if you agree, and then I should be
able to provide PR for 1, 2 ,4 first, then for 3. Feature from topic 5
is a bit complicated so I'm probably not able to help with it.
Thanks in advance
Vlastimil
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
9 years, 7 months
Minor build issue
by Marko Strukelj
Tomas has found an issue with the build when local maven repository is empty or build hasn't been run since previous version.
The issue was introduced by my changes to adapters build - I left a dependency to the artifact I removed - org.keycloak:keycloak-wildfly-adapter-subsystem, and affects distribution/modules.
There's a fix ready for merge: https://github.com/keycloak/keycloak/pull/1312
Too bad Travis CI didn't catch it - I propose we set up a local Nexus mirror and clear local repository (rm -rf ~/.m2/repository) for every build.
Artifacts would be cached by local Nexus mirror and will be refetched from localhost, rather than from remote servers.
- marko
9 years, 7 months
confused on event builder on auth
by Bill Burke
What events are we supposed to be logging with the EventBuilder when
authenticating and doing required actions?
1. All errors
2. all required action successes
3. all login success
2. Successful authentication prior to required actions?
3. Success after required actions?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 7 months
