This reminds me of a feature that was recently added to keycloak - "Provide
an endpoint that redirect to the actual client referred to by clientId."
Perhaps this could be used to define multi-stage redirect redirect URI -
the generic redirect endpoint mentioned in the issue could be populated
from the "state" parameter
which would then redirect to the approproate realm / broker client.
... just thinking out loud...
Cheers,
Thomas
2016-04-20 10:52 GMT+02:00 Thomas Raehalme <thomas.raehalme(a)aitiofinland.com
Hi!
Some time ago I had a similar enquiry but the response was that every
realm should have its own configuration in Google. This does add quite a
lot of configuration overhead regarding SaaS applications and I would also
like to see the state parameter being used to transfer the realm.
You can find the discussion here:
http://lists.jboss.org/pipermail/keycloak-dev/2016-January/006301.html
Best regards,
Thomas
On Wed, Apr 20, 2016 at 11:37 AM, Martijn Claus <m.claus(a)smile.nl> wrote:
> Hello,
>
>
>
> I’ve got a question regarding the identity provider google (and maybe
> others). We are building a multi-tenant saas environment where the tenants
> are dynamically added (which I think is a valid usecase). We use the
> keycloak admin api to create a realm per tenant. We want to use (amongst
> others) the google identity provider. For this you need to set up the
> callback url in the google api client. The problem is that the callback url
> is different for each realm and *Google does not allow wildcards in
> redirect urls.*
>
>
>
> The redirect url format now:
>
>
http://ourserver:8080/auth/realms/{realm}/broker/google/endpoint
>
>
>
> I don’t want to dynamically add redirect urls to the google api account.
> Google has a solution for this, the client (ie KeyCloak) should use the
> “state” queryparameter to add the realm. But this is a change Keycloak
> needs to make imo.
>
>
>
> Someone with a related problem (not with keycloak)
>
>
>
http://stackoverflow.com/questions/13652062/subdomain-in-google-console-r...
>
>
>
> Any thoughts on this problem?
>
>
>
> PS: I can imagine this holds also true for other identity providers, but
> Google was the first I tried.
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user