Re: [keycloak-dev] username guessing
by Michael Gerber
@Bill
What do you think about this? Do you prefere the "new way" or the old one?
Am 29. Oktober 2015 um 07:15 schrieb Michael Gerber <gerbermichi(a)me.com>:
You showed in the passt the correct error message only if the user has entered the correct password.
In other words, you can split the userValidation into a pre and post validation, so you have the possibility to show sensitive messages only to authenticated users.
Am 29.10.2015 um 00:42 schrieb Bill Burke <bburke(a)redhat.com>:
Hmmm...IIRC I kept that there because, if the account is disabled how would the user ever know? This is even more important with a temporarily disabled account.
On 10/28/2015 5:48 PM, Michael Gerber wrote:
Just create a new user, disable it and try to log in with the username and a wrong password.
And you will get the following error message:
Account is disabled, contact admin.
On 28.10.2015, at 20:50, Bill Burke <bburke(a)redhat.com> wrote:
How is this possible?
On 10/28/2015 10:53 AM, Michael Gerber wrote:
Hi all,
it is possible to guess the username of disabled users.
This was not possible in earlier versions of keycloak. Is this on purpose?
Best
Michael
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10 years
Plan for "First login with identity brokers"
by Marek Posolda
I went again through all the previous discussions, related JIRAs and
requirements. As of now, my plan is to:
- Use authentication SPI to handle the flow and related actions for
first social login. (Update user profile, Detect duplicated account,
Verify email or reauthenticate user if duplication is detected, Create
social link to existing account). This allows most flexibility for
admins to specify how exactly the linking should work
- Detecting duplication will be based on email only by default - (For
example duplication is detected if Facebook user with email
bob(a)gmail.com authenticates, but there is already Keycloak user with
email bob(a)gmail.com ). The people can provide their own execution if
they want different way for detect duplications
- It seems it's more proper to postpone creating user account later,
once we know that there is no duplication. In other words, if "Update
profile on first login" is enabled, the user account is not yet created
when the update profile page is shown. All the info related to
BrokeredIdentityContext stuff will be available on ClientSession. This
seems to me easier and more proper solution then creating temporary
account with email in some "temporary" attribute. Temporary accounts
have other challenges (Cleaner thread for delete outdated unmerged
accounts etc).
- If "trustEmail" flag is on for IdentityProvider, the provider link
will be created automatically. (For example if Facebook user
bob(a)gmail.com authenticates for the first time and there is already
Keycloak user with email bob(a)gmail.com and trustEmail is on, the
Facebook link is automatically created for Keycloak account
bob(a)gmail.com without any additional verification)
- If "trustEmail" flag is off, there would need to be other way to
verify user before creating social link. The user will first confirm if
he wants to merge the accounts. Then there will be either:
-- Email verification: The mail will be sent to bob(a)gmail.com like
"Someone authenticates to Keycloak server http://www.keycloak.org:8080
through Facebook account bob(a)gmail.com and wants to link Facebook
account with existing Keycloak account bob(a)gmail.com . If it is you,
click here" . After user clicks, the social link is created
-- Further authentication: User will need to authenticate to existing
bob(a)gmail.com keycloak account through password (or OTP or both or
something else)
All of this is configurable through flows, so admin can disable the "Do
you want to create social link?" screen, or enforce email verification
instead of authentication, configure required authenticators etc.
- I am not sure if we want to handle just merge with existing account
during first broker login, or if we also want to handle merging of
accounts in account management? For now, I am planning to handle just
the login flow and possibly address Account management later if there is
need for it. The merging accounts in account management might be quite a
challenge as there is merge of 2 already existing user accounts with
various issues related to it (Which roles/permissions should merged
account have? Which attributes it should have? Which federation link?
etc.). But at least, I am planning to address the issue with redirect to
login forms error screen instead of stay in account management -
https://issues.jboss.org/browse/KEYCLOAK-1822
Marek
10 years
redesign of federation
by Bill Burke
In doing group model, I was thinking more about federation. Our SPI
kinda sucks. I was thinking that local storage (Model API) and
UserFederation should be the same exact SPI. Instead of just
RealmProvider and UserProvider, we might break it up into:
* RealmProvider - holds realms and clients
* UserProvider - holds username and attributes about the user
* UserRelationshipProvider - holds user role mappings, user group membership
* UserCredentialProvider - stores and authenticates credentials
* GroupProvider - holds group definitions
* RoleProvider - holds role definitions
One of the big problems we have is that roles and groups have to be
defined within Keycloak DB even though they might live in one or more
external stores.
Admin console would have to change too. You'd have to pick which
database you wanted to manage. i.e. if you wanted to add a role you
might want to add it to an LDAP store and not local storage.
This is something we'd really have to map out and design. I would love
to be able to do it before product, but I don't think we'll have enough
time to bake it in community. Maybe something we'll have to wait for
Keycloak 2.0.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years