search

robsontenorio / laravel-keycloak-guard

🔑 Simple Keycloak Guard for Laravel
MIT License
434 stars 141 forks source link

Feature/autoreg multirealm #30

Closed iruizr7 closed 2 years ago

iruizr7 commented 4 years ago

FEAT: Implemented multi-realm support and automatic user registration

This is done through a two new configuration parameters that control this behaviour. Setting this two to null will proved the same behaviour as before.

The multi-realm support is done through a cookie that should hold the realm name to use in every request. The realm public keys are downloaded on demand from the IDMS if not cached.

The automatic user registration is made in order to ease the functionality of the plugin in environments that have the IDMS as the only source of truth. Thus an unknown user can be logged into the app and still be a valid behaviour. This parameter allows a closure with the Access Token of this requests as the only parameter. The developer is responsible of wiring this call to a code which properly registers the user to be usable according to the plugin original behaviour.

robsontenorio commented 4 years ago

Hi thanks for PR!

I really like the "auto register user" and plan to support it on up coming releases.

About multi-realm feature, i am not sure about implementation. If you depend on third party online connections we can issue future problem.

As you can notice laravel-keycloak-guard package is "stateless" and validate tokens in "offline way", because we set up everything is necessary. So it is not reponsible for "authenticate" or similar tasks. It is a simple middleware.

iruizr7 commented 4 years ago

Hi, thanks for the rapid response!

Yeah, I completely agree that depending on third-parties always add some risks along the way. But I am thinking about the following:

This is to be configured for the IDMS you trust, the IDMS that provides the authorization mechanism for your app, and probably the IDMS from which your user just came from (Thinking of the login step). So, if that IDMS cames down, you have a more severe problem, as your user cannot login back to the application neither. It's a true problem for IDMS's that are behind VPN's and so, but this is a rare case. By no means we are doing authorization here, only avoiding harcoding public keys and retrieving them on demand.

Another solution would be to hardcode each realm public keys on an array with the realm code as the key of this array. But this would not fit my business case, where new realms are created only at the IDMS and then the users login into the app out of the sudden, without any other intervention.

I truly don't know what you prioritise in this project, if "stateless" operation or any sort of flexible interoperation. So it's on your hands. If you think about any other mechanism allowing this sort of functionality without compromising reliability, I am all ears.

Have a nice day!