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

    XMLWordPrintable

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.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: