Feature/add bearer token authentification

[Saskia32123]

Hier der Pull Request für die Bearertokenauthentifizierung + ein paar kleinere Improvements

[patrick-skowronek]

Thank you @Saskia32123 .

I have some comments and I need to apologize for the bad code 😅

1. I would introduce a enum type for the authentication. Which is either a keycloak, static or basic auth. This would make the code cleaner. With @ConfigurationProperties you can do that. This would is then needed twice for the source and target.
2. Some of the logs are quite bad, even before your PR. If you can change them, that would be nice. Otherwise I will improve them after this PR.

[Saskia32123]

Thank you @Saskia32123 .

I have some comments and I need to apologize for the bad code 😅

1. I would introduce a enum type for the authentication. Which is either a keycloak, static or basic auth. This would make the code cleaner. With @ConfigurationProperties you can do that. This would is then needed twice for the source and target.
2. Some of the logs are quite bad, even before your PR. If you can change them, that would be nice. Otherwise I will improve them after this PR.

Hi @patrick-skowronek the code gets the job done :) To your points:

1. Good idea. Even though I am not sure, why we want to go with these categories especially since Keycloak offers various authentification option. Maybe it's useful to differentiate beween the protocols and think about which one's we want to support. Afaik shortlived Bearer Token is the modern approach? Basic Auth or Apikeys is rather something for legacy clients and not very secure (just coupled with HTTPS it's encrypted by TLS) and the data itsself is rather sensitive.
2. Yes, I feel you have a clear strategy there, which I propably don't completly get? -> So I would suggest to open a seperate MR for that rework and if you like I can support you :)

[Saskia32123]

Thank you @Saskia32123 .
I have some comments and I need to apologize for the bad code 😅

1. I would introduce a enum type for the authentication. Which is either a keycloak, static or basic auth. This would make the code cleaner. With @ConfigurationProperties you can do that. This would is then needed twice for the source and target.
2. Some of the logs are quite bad, even before your PR. If you can change them, that would be nice. Otherwise I will improve them after this PR.

Hi @patrick-skowronek the code gets the job done :) To your points:

1. Good idea. Even though I am not sure, why we want to go with these categories especially since Keycloak offers various authentification option. Maybe it's useful to differentiate beween the protocols and think about which one's we want to support. Afaik shortlived Bearer Token is the modern approach? Basic Auth or Apikeys is rather something for legacy clients and not very secure (just coupled with HTTPS it's encrypted by TLS) and the data itsself is rather sensitive.
2. Yes, I feel you have a clear strategy there, which I propably don't completly get? -> So I would suggest to open a seperate MR for that rework and if you like I can support you :)

I implemented it like you suggested, but for a clear structure it maybe makes sense to differentiate between protocols and providers?

[patrick-skowronek]

Thank you @Saskia32123 .
I have some comments and I need to apologize for the bad code 😅

1. I would introduce a enum type for the authentication. Which is either a keycloak, static or basic auth. This would make the code cleaner. With @ConfigurationProperties you can do that. This would is then needed twice for the source and target.
2. Some of the logs are quite bad, even before your PR. If you can change them, that would be nice. Otherwise I will improve them after this PR.

Hi @patrick-skowronek the code gets the job done :) To your points:

1. Good idea. Even though I am not sure, why we want to go with these categories especially since Keycloak offers various authentification option. Maybe it's useful to differentiate beween the protocols and think about which one's we want to support. Afaik shortlived Bearer Token is the modern approach? Basic Auth or Apikeys is rather something for legacy clients and not very secure (just coupled with HTTPS it's encrypted by TLS) and the data itsself is rather sensitive.
2. Yes, I feel you have a clear strategy there, which I propably don't completly get? -> So I would suggest to open a seperate MR for that rework and if you like I can support you :)

I implemented it like you suggested, but for a clear structure it maybe makes sense to differentiate between protocols and providers?

Did you commit and pushed it already? From a code perspective it would be nice to have a switch case with all the options we provide. I think we don't support api keys. With you addition we would then support bearer token.