--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9ts8FpSNNT7O%3DTig0RDo3juYd806n309MMt_r_Tq8X%2BQQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9u7itYzHT-NzNJMqfQCUh-FKs2pG3Oi_5k1Dwnqpe9TiQ%40mail.gmail.com.
Well, it's not just the startup time: it's whether starting Keycloak is even useful for devs that want to use OIDC sign-ins such as Google/Github etc. 2-4s is still way too much (not counting the CPU/mem usage) if all I need is a YES login form.
On Mon, 22 Nov 2021 at 17:11, Sebastien Blanc <scm....@gmail.com> wrote:If the main blocking point is the startup time (and I have to confess , the current one is too long) I would suggest waiting until devservices uses keycloak.x (Quarkus based) instead of the "old-school" Keycloak distrib (Wildfly based) to have this conversation. We should have a startup time between 2-4seconds which seems acceptable to me.On Mon, Nov 22, 2021 at 4:52 PM Stephane Epardaud <stephane...@gmail.com> wrote:Hi,I've had the discussion with Sébi at Devoxx about the OIDC dev services, which currently starts Keycloak and takes quite a while to start. Sébi thought it was really great for demos, and I thought anything that takes more than 1-2s to start for dev services is actually harmful.
I told him that me, as a user, wanted a dev service for OIDC that had a single HTML page where I'd type in my email/pass and possibly another field for a list of roles, and it would obediently say YES SIR and get me a token back to my app.
I can't even imagine a use-case where a dev would want anything else for dev service unless they already have a configured keycloak, but then it's not even a dev service, is it?
At least this would start in 0s: actually it could even be an in-app page.At the time I thought I didn't have enough justification for that, but now that I've been using OIDC for sign-in using the Google Sign-in, I realise that in this use-case, the OIDC provider is ony there for user/pass: it doesn't even give you user management or roles or anything: so the value in having keycloak for dev services is unknown to me.
I realise there's surely a huge value in having keycloak in dev services for people who will want keycloak as their OIDC provider in prod, but now I'm fairly sure that for the people using OIDC for sign-in and not user/role management, a YES SIR endpoint is all they'll ever need.Am I missing something? If not, is there any chance we could get that sort of dev service endpoint if the OIDC provider is not keycloak? I know we already query them to get info about what they provide, so we could use that as a selector.
----Stéphane Épardaud
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9ts8FpSNNT7O%3DTig0RDo3juYd806n309MMt_r_Tq8X%2BQQ%40mail.gmail.com.
--Stéphane Épardaud--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9u7itYzHT-NzNJMqfQCUh-FKs2pG3Oi_5k1Dwnqpe9TiQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKawoOa%2BQRLAx5ysQNAd_%2B8MQ36sBZAbwgD5WKMpCcjmHDrF8w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKawoObv-dbqAvKTKjC8HePvPqAYKJk5CfrJ%2B5h38i%3DV5To1yg%40mail.gmail.com.
+100 on having dead-dumb OIDC devservices but can we properly detect when OIDC is NOT going through keycloak ?
/max
--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9ts8FpSNNT7O%3DTig0RDo3juYd806n309MMt_r_Tq8X%2BQQ%40mail.gmail.com.
/max
https://xam.dk/about
+100 on having dead-dumb OIDC devservices but can we properly detect when OIDC is NOT going through keycloak ?
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/D535B3CD-D583-4C8B-B517-AC9C0F105587%40redhat.com.
> By the way, I forgot to mention that Keycloak supports the federation to
> the social providers
We definitely should highlight and make this as easy to setup as possible.
Like Steph I struggle hard grokking what I need to actually do to just get
basic auth against github/google etc. working.
That said - I think there are a lot of usecases where you just are making an
app and want to use a specific social provider; i.e. github.
Do we support GitHub login + exchange of scope/auth without having to expose a
separate service ?
On Tue, Nov 23, 2021 at 8:55 AM Max Rydahl Andersen <mand...@redhat.com> wrote:+100 on having dead-dumb OIDC devservices but can we properly detect when OIDC is NOT going through keycloak ?
Keycloak is our recommended provider so we do our best effort to optimize it for Keycloak users. We spent abou 2 months and 100+ PR comments with Stuart discussing and trying different variations
Don't get me wrong - I think having keycloack support in devservice fashion is critical and I really like where it is at.
Its just I wonder if we can do something simpler when you are trying to use google or GitHub directly.
I guess what you are saying is that users should just configure them directly - which I guess is a fair point.
It doesn't give me a "always accepting login" which could be nice to allow dev mode not reliant on accessible service.
/max
/max
https://xam.dk/about
Don't get me wrong - I think having keycloack support in devservice fashion is critical and I really like where it is at.
Its just I wonder if we can do something simpler when you are trying to use google or GitHub directly.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/D64F73C0-CE63-49E6-8C15-8C8AF5E743C2%40redhat.com.
Don't get me wrong - I think having keycloack support in devservice fashion is critical and I really like where it is at.
Its just I wonder if we can do something simpler when you are trying to use google or GitHub directly.
I guess what you are saying is that users should just configure them directly - which I guess is a fair point.
It doesn't give me a "always accepting login" which could be nice to allow dev mode not reliant on accessible service.
On Tue, 23 Nov 2021 at 21:38, Max Rydahl Andersen <mand...@redhat.com> wrote:Don't get me wrong - I think having keycloack support in devservice fashion is critical and I really like where it is at.
Its just I wonder if we can do something simpler when you are trying to use google or GitHub directly.
Can we add extensions (that depend on the OIDC extension), that just expose the bits of config that would be provided by these providers and transform it into our config?Basically just extensions that expose config using the exact same terminology as the relevant providers, defaulting all the settings that we can, and just use that to make configuration easier to understand for users?
The 'just log me in a X' thing is a separate topic, we can already do that for tests, we could also do it for dev mode, but what the actual user experience looks like might be a bit tricky to sort out. You would not want to have to manually re-enter roles every time you restart Quarkus, and the tokens can contain more info than just roles.
Hi Stuart,On Tue, Nov 23, 2021 at 11:23 AM Stuart Douglas <sdou...@redhat.com> wrote:On Tue, 23 Nov 2021 at 21:38, Max Rydahl Andersen <mand...@redhat.com> wrote:Don't get me wrong - I think having keycloack support in devservice fashion is critical and I really like where it is at.
Its just I wonder if we can do something simpler when you are trying to use google or GitHub directly.
Can we add extensions (that depend on the OIDC extension), that just expose the bits of config that would be provided by these providers and transform it into our config?Basically just extensions that expose config using the exact same terminology as the relevant providers, defaulting all the settings that we can, and just use that to make configuration easier to understand for users?If it is a SAAS provider like Okta or Google or Auth0 - then all we can do is to support it at the Dev UI level only - the users just type `auth-server-url`, client/account id, secret and it is done, Dev UI will discover the data if it can and will offer the same UI offered for Dev Services for Keycloak.It is not guaranteed to be a 1 to 1 match, ex, Auth0/Goolge logout is non-standard so I'm looking at making it work. GitHub will not return the id token so we need to tune UI not to always expect the id token, etc.If it is a provider which, similar to Keycloak, can be launched with a docker image, then yes, sure, I'd like to see the new extensions extending OIDC dev services only appearing in Quarkiverse :-), recall we discussed it, this is what this section recommends:It would be good to do a POC project for some other provider but I'm not sure which oneThe 'just log me in a X' thing is a separate topic, we can already do that for tests, we could also do it for dev mode, but what the actual user experience looks like might be a bit tricky to sort out. You would not want to have to manually re-enter roles every time you restart Quarkus, and the tokens can contain more info than just roles.If it is not Keycloak then the only way to control the token content is to set the properties in a given provider's console, ex, in Auth0 Admin console etc.
Hi Stuart,On Tue, Nov 23, 2021 at 11:23 AM Stuart Douglas <sdou...@redhat.com> wrote:On Tue, 23 Nov 2021 at 21:38, Max Rydahl Andersen <mand...@redhat.com> wrote:Don't get me wrong - I think having keycloack support in devservice fashion is critical and I really like where it is at.
Its just I wonder if we can do something simpler when you are trying to use google or GitHub directly.
Can we add extensions (that depend on the OIDC extension), that just expose the bits of config that would be provided by these providers and transform it into our config?Basically just extensions that expose config using the exact same terminology as the relevant providers, defaulting all the settings that we can, and just use that to make configuration easier to understand for users?If it is a SAAS provider like Okta or Google or Auth0 - then all we can do is to support it at the Dev UI level only - the users just type `auth-server-url`, client/account id, secret and it is done, Dev UI will discover the data if it can and will offer the same UI offered for Dev Services for Keycloak.It is not guaranteed to be a 1 to 1 match, ex, Auth0/Goolge logout is non-standard so I'm looking at making it work. GitHub will not return the id token so we need to tune UI not to always expect the id token, etc.If it is a provider which, similar to Keycloak, can be launched with a docker image, then yes, sure, I'd like to see the new extensions extending OIDC dev services only appearing in Quarkiverse :-), recall we discussed it, this is what this section recommends:It would be good to do a POC project for some other provider but I'm not sure which oneThe 'just log me in a X' thing is a separate topic, we can already do that for tests, we could also do it for dev mode, but what the actual user experience looks like might be a bit tricky to sort out. You would not want to have to manually re-enter roles every time you restart Quarkus, and the tokens can contain more info than just roles.If it is not Keycloak then the only way to control the token content is to set the properties in a given provider's console, ex, in Auth0 Admin console etc.The other somewhat orthogonal but important point is that if Quarkus OIDC is configured as a `web-app` application - i.e it itself drives the authentication (with redirects, code flow) then Dev UI does not help much - since Quarkus itself controls the process - hence it would be good to at least do a better Swagger UI integration in this case.Dev UI is ideal for Quarkus OIDC `service` applications which expect a Bearer token acquired elsewhere - in this case Dev UI emulates a Single Page Application acquiring the tokens and then sends the token to Quarkus.
I'm in the process of making an app working with Google Sign-in, Github, and I'll probably try Facebook and whatever other? Once that is done I intend to document this all, at least for Vixen, and produce issues for/if whatever is missing from our OIDC extension/docs.
As for dev services, I still don't understand why I'd even want keycloak if all I want was login and not preconfigured users/roles.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfXHbSMMYmabUThu%3DvaQbaOM9Tm3O2k7mEsdy6VOOvgeaQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9uFPbtAsdtnNvD%3DuvYiw_RrdR%2Bb_9rp3DR%3D3Jt1SNgvOg%40mail.gmail.com.