Details
-
Enhancement
-
Status: Closed
-
Major
-
Resolution:
Out of Date
-
8.0.1, 9.0.0
-
None
-
None
-
None
-
NEW
-
NEW
Description
In Europe, data protection is standardised via the so-called DSGVO.
For example it is not allowed to store personal data or data relating to persons in plain text in log files.
My keycloak is configured to use the e-mail address as username, this is a data relating to a person.
In case of failed login attempt with an unkown userId a WARN log is written with complete username (here: user.unknown@emailprovider.com)
2020-02-28 11:40:03,508 WARN [org.keycloak.events] (default task-3) type=LOGIN_ERROR, realmId=thisIsMyRealm, clientId=api-server, userId=null, ipAddress=1.2.3.4, error=user_not_found, auth_method=openid-connect, auth_type=code, redirect_uri=https://my_domain.net/login/oauth2/code/demo, code_id=134a47cd-dc58-46ad-b9de-16234740a8ec, username=user.unknown@emailprovider.com, authSessionParentId=134a47cd-dc58-46ad-b9de-16234740a8ec, authSessionTabId=MxqpGQsKHLs
Same for the case of failed login attempt with a kown userId but wrong password a WARN log is written with complete username (here: valid.user@emailprovider.com)
2020-02-28 11:41:12,276 WARN [org.keycloak.events] (default task-4) type=LOGIN_ERROR, realmId=thisIsMyRealm, clientId=api-server, userId=45f31bdf-7afd-4d42-86ad-6b6c6e3eded3, ipAddress=1.2.3.4, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=https://my_domain.net/login/oauth2/code/demo, code_id=134a47cd-dc58-46ad-b9de-16234740a8ec, username=valid.user@emailprovider.com, authSessionParentId=134a47cd-dc58-46ad-b9de-16234740a8ec, authSessionTabId=MxqpGQsKHLs
User registration with already registered username (here e-mail address):
2020-03-02 12:54:31,881 WARN [org.keycloak.events] (default task-14) type=REGISTER_ERROR, realmId=thisIsMyRealm, clientId=api-server, userId=null, ipAddress=1.2.3.4, error=email_in_use, auth_method=openid-connect, register_method=form, redirect_uri=https://my_domain.net/login/oauth2/code/demo, code_id=1f5ea7b1-012c-43fe-b45a-9f0cbb08c805, email=valid.user@emailprovider.com, username=valid.user@emailprovider.com, authSessionParentId=1f5ea7b1-012c-43fe-b45a-9f0cbb08c805, authSessionTabId=MiIxkN81U8M
In all cases on WARN level the username sould be anonymised or left empty. Only in DEBUG Level the full content could be given out.
E.g. anonymised by taking the first 3 and last 5 characters of an e-mail, concatinated with % in the middle.
user.unknown@emailprovider.com --> use%r.com valid.user@emailprovider.com --> val%r.com
For diagnostic reasons access from known usernames have a valid userId (here userId=45f31bdf-7afd-4d42-86ad-6b6c6e3eded3) which can be used for checking.
The userId should be anonymised too! E.g:
userId=45f31bdf-7afd-4d42-86ad-6b6c6e3eded3 --> 45f%ed3
And those anonymised usernames and UserIds can be used as SQL query for diagnostic reasons without spreading the true identity in LOG files that are not under your control.
Furthermore, the system does not log any system activities. It is not visible that users log in or log out.
From a Security Information and Event Management (SIEM) point of view, at least a little data is required.
Only in DEBUG Level we see the successful login process:
2020-03-02 10:06:22,664 DEBUG [org.keycloak.events] (default task-8) type=LOGIN, realmId=thisIsMyRealm, clientId=api-server, userId=45f%ed3, ipAddress=1.2.3.4, auth_method=openid-connect, auth_type=code, redirect_uri=https://my_domain.net/login/oauth2/code/demo, consent=no_consent_required, code_id=1556a02c-06b1-470c-8230-4b40ea2d9fd8, username=valid.user@emailprovider.com, authSessionParentId=1556a02c-06b1-470c-8230-4b40ea2d9fd8, authSessionTabId=T9kmZvg_YDo 2020-03-02 10:06:22,951 DEBUG [org.keycloak.events] (default task-8) type=CODE_TO_TOKEN, realmId=thisIsMyRealm, clientId=api-server, userId=45f%ed3, ipAddress=1.2.3.4, token_id=6bfa43cd-04a1-4b2c-8e5d-392782f08630, grant_type=authorization_code, refresh_token_type=Refresh, scope='openid profile email', refresh_token_id=e67270b9-d3a1-4708-ad44-9b46312e50b9, code_id=1556a02c-06b1-470c-8230-4b40ea2d9fd8, client_auth_method=client-secret 2020-03-02 10:06:22,983 DEBUG [org.keycloak.events] (default task-8) type=USER_INFO_REQUEST, realmId=thisIsMyRealm, clientId=api-server, userId=45f%ed3, ipAddress=1.2.3.4, auth_method=validate_access_token, signature_required=false, username=valid.user@emailprovider.com
In INFO Level we nee a subset of those data and partly anonymised.
Another place is could be related to brute force protection. The WARN output could (not should?) be anonymised too.
Currently I'm getting the full userid, maybe a shorten output fits better user 5a1%6c5?
2020-03-03 08:38:00,738 WARN [org.keycloak.services] (Brute Force Protector) KC-SERVICES0053: login failure for user 5a17701c-5361-4661-aade-b5819b28c6c5 from ip 10.1.93.60 2020-03-03 08:38:42,072 WARN [org.keycloak.services] (Brute Force Protector) KC-SERVICES0053: login failure for user 5a17701c-5361-4661-aade-b5819b28c6c5 from ip 10.1.93.60 2020-03-03 08:38:43,897 WARN [org.keycloak.services] (Brute Force Protector) KC-SERVICES0053: login failure for user 5a17701c-5361-4661-aade-b5819b28c6c5 from ip 10.1.93.60
This is just one part of the whole thing, currently I have not checked other workflows.
