Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-13160

To be European DSGVO compliant Keycloak running in Loglevel INFO -- missing audit trail for successful logins && failed logins: do not output personal data or data relating to persons



    • Enhancement
    • Status: Closed
    • Major
    • Resolution: Out of Date
    • 8.0.1, 9.0.0
    • None
    • None
    • None
    • NEW
    • NEW


      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=, 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=, 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=, 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=, 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=, 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=, 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
      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
      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

      This is just one part of the whole thing, currently I have not checked other workflows.




            Unassigned Unassigned
            patrikschwieger Patrik Schwieger (Inactive)
            0 Vote for this issue
            4 Start watching this issue