OIDC dev services

[Stephane Epardaud]

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

[Sebastien Blanc]

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. 

--
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.

[Stephane Epardaud]

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.

--

Stéphane Épardaud

[Antonio Goncalves]

Hi,

I have to agree with Stephane on this. It's not just about the startup time (I'm sure it will get better) but more about the complexity to setup Keycloak. As Stephane says, my use case as a developer is to type a user/password/role and want it to "obediently say YES SIR and get me a token back to my app". More complex login (e.g. external providers, social network....) is only used once in a while. 

Then, having said that, if I can have a "Keycload Light" (with no config), then it's the best of both worlds.

My 2 cents

Antonio 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9u7itYzHT-NzNJMqfQCUh-FKs2pG3Oi_5k1Dwnqpe9TiQ%40mail.gmail.com.

--

Antonio Goncalves 
Contractor, Java Champion and Pluralsight author

Blog | Twitter | LinkedIn | Author | Pluralsight | Devoxx France | Voxxed Microservices

[Sergey Beryozkin]

Hi Steph

Thanks for starting this discussion, let me comment,

On Mon, Nov 22, 2021 at 4:17 PM Stephane Epardaud <stephane...@gmail.com> wrote:

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.

First of all, for Keycloak users, we already support a Keycloak-X image with Dev Services for Keycloak, but it is not a default yet as auto-importing the realm does not work yet with HTTP, only HTTPS - for Dev Services's Dev UI I'd like to avoid users being asked to accept self-signed certificates. Stian has blogged about Keycloak 16.0.0 on the way, with Keycloak-X being a major feature, and I'm hopeful we'll make Keycloak-X the default image then and it will start very fast.

We also do support non-Keycloak providers in the devmode - with Dev UI for OIDC one should be able to  acquire the tokens from most OIDC providers and use them to test the endpoint, using all the options available for Keycloak, i.e

All the options described at

https://quarkus.io/version/main/guides/security-openid-connect-dev-services#dev-services-for-keycloak

are available with:

https://quarkus.io/version/main/guides/security-openid-connect-dev-services#dev-ui-all-oidc-providers

If you already have a Google/etc `auth-server-url` that is it, it will work, you even will see an OIDC card with a `Provider: Google` link which will bring you to the Dev UI.

If you'd like to start with the empty properties and avoid launching Keycloak then disable it:

https://quarkus.io/version/main/guides/security-openid-connect-dev-services#disable-dev-services-for-keycloak

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.

 

See my comments above

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.

So, OIDC Dev UI supports a code flow by default - you are redirected to your provider, log in, get the tokens, view them, use them, logout and try again - here we'll have to do a bit of work to support those providers which don't support the OIDC RP-Initiated spec but I've linked you to the issue

 

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?

See my comments above; for non-Keycloak providers all we can do is to offer a Dev UI support and we do 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.

It is impossible to provide a generic account management like setting the roles, users in a provider specific way, with Keycloak we know where the admin UI is, how to create realm/users/clients, with other providers and there could be N such providers it is all opaque - but even in this case users can offer provider specific Dev UI which for ex may offer a link to login to Google Dev Console/Account, etc:

https://quarkus.io/version/main/guides/security-openid-connect-dev-services#dev-services-and-ui-support-for-other-openid-connect-providers

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.

Hope I've clarified that yes, we provide Dev UI for all OIDC providers :-) - code flow by default, use `quarkus.oidc.devui.grant.type` to switch to a password (if you prefer to enter the username and password in the Dev UI page to get a token) or client creds grant - not sure the last 2 are supported with Google but might be - the code flow always works

Cheers, Sergey

 

--

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.

[Sebastien Blanc]

Well, with Keycloak Deveservices, you already get a fully configured Keycloak with 2 users (Bob and Alice with a different set of roles) , nothing to configure, just even if it's just for just user/pass ...  

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKawoOa%2BQRLAx5ysQNAd_%2B8MQ36sBZAbwgD5WKMpCcjmHDrF8w%40mail.gmail.com.

[Antonio Goncalves]

Yes, but I need to know they are called Bob and Alice (I don't need to know the username and password to connect to PostgreSQL when using DevServices)

[Sergey Beryozkin]

It is documented. One does need to know it with OIDC in order to acquire a token, one can't have a wildcard token acquisition. A case where a user does not need to know any details and use Keycloak for Dev Services to have some meaningful Dev/test experience is not practical for the DevService for Keycloak IMHO.

By the way, I forgot to mention that Keycloak supports the federation to the social providers - so Steph, you may want to look into it later on. The user experience will be exactly the same, but your application configuration will only list the keycloak properties; the likely advantage is that the logout will work better - Keycloak supports the RP initiated logout spec and I'd expect it to translate properly to the federated provider's specific logout mechanism, though I haven't tried... Even if you will prefer to control it directly, trying a Keycloak option may make Dev Services for Keycloak actually useful even for signing in to Google - you'd just configure Dev Services to import a realm with the federation settings and it should work :-)

Sergey 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKawoObv-dbqAvKTKjC8HePvPqAYKJk5CfrJ%2B5h38i%3DV5To1yg%40mail.gmail.com.

[Max Rydahl Andersen]

+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

[Max Rydahl Andersen]

> 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 ?

>>>> Then, having said that, if I can have a "*Keycload Light*" (with no

>>>>>>> <https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9ts8FpSNNT7O%3DTig0RDo3juYd806n309MMt_r_Tq8X%2BQQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>> .

>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>> <https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9u7itYzHT-NzNJMqfQCUh-FKs2pG3Oi_5k1Dwnqpe9TiQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .

>>>>>
>>>>
>>>>
>>>> --
>>>> Antonio Goncalves
>>>> Contractor, Java Champion and Pluralsight author
>>>>

>>>> Blog <https://antoniogoncalves.org/> | Twitter
>>>> <https://twitter.com/agoncal> | LinkedIn
>>>> <https://www.linkedin.com/in/agoncal> | A
>>>> <http://amazon.com/author/agoncal> uthor
>>>> <http://amazon.com/author/agoncal> | Pluralsight
>>>> <https://app.pluralsight.com/profile/author/antonio-goncalves> | Devoxx
>>>> France <http://www.devoxx.fr/> | Voxxed Microservices
>>>> <https://voxxeddays.com/microservices>

>>>>
>>>> --
>>>> 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/CAKawoOa%2BQRLAx5ysQNAd_%2B8MQ36sBZAbwgD5WKMpCcjmHDrF8w%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/quarkus-dev/CAKawoOa%2BQRLAx5ysQNAd_%2B8MQ36sBZAbwgD5WKMpCcjmHDrF8w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .

>>>>
>>>
>>
>> --
>> Antonio Goncalves
>> Contractor, Java Champion and Pluralsight author
>>

>> Blog <https://antoniogoncalves.org/> | Twitter
>> <https://twitter.com/agoncal> | LinkedIn
>> <https://www.linkedin.com/in/agoncal> | A
>> <http://amazon.com/author/agoncal> uthor <http://amazon.com/author/agoncal>
>> | Pluralsight
>> <https://app.pluralsight.com/profile/author/antonio-goncalves> | Devoxx
>> France <http://www.devoxx.fr/> | Voxxed Microservices
>> <https://voxxeddays.com/microservices>

>>
>> --
>> 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/CAKawoObv-dbqAvKTKjC8HePvPqAYKJk5CfrJ%2B5h38i%3DV5To1yg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/quarkus-dev/CAKawoObv-dbqAvKTKjC8HePvPqAYKJk5CfrJ%2B5h38i%3DV5To1yg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>
> --
> 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/CAMsYBfUDhaNdZQqdVC%2BqQt6H2wNovc%3DE2sMdv37%3DutJGmxndag%40mail.gmail.com.

/max
https://xam.dk/about

[Sergey Beryozkin]

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 to make it as seamless as possible for Keycloak users but not only for Keycloak users - as I've already clarified in my response to Steph.

As explained in Dev Services for Keycloak docs if an OIDC endpoint URL is already configured then it does not matter if it is Keycloak or Google, OIDC Dev UI will support it in the dev mode and no Keycloak container will be started.

If you start with the empty properties then we have to decide what to do and by default it is assumed Keycloak is required - due to the fact Keycloak is our recommended provider.

In such cases, the only inconvenience for non-KC users is that they have to type `quarkus.keycloak.devservices.enabled=false`. And we'd like encourage the developers of other providers to plugin, where possible, their own Dev Services support.

Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/D535B3CD-D583-4C8B-B517-AC9C0F105587%40redhat.com.

[Sergey Beryozkin]

On Tue, Nov 23, 2021 at 8:59 AM Max Rydahl Andersen <mand...@redhat.com> wrote:

> 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.

This is not a Hello world. I know, it would be great if any user would just look at OIDC docs, and without knowing anything about OIDC or even security would just have Google and all other social providers supported in no time, but we are not there yet. But I don't agree that the OIDC docs don't provide sufficient information for users who are interested in getting it work - and we are around to help with their queries. I've created an issue though, by using Google as an example, to show how it can be integrated with. There is a security docs issue epic and the work on improving the security docs is ongoing - it just takes time.

 

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 ?

https://quarkus.io/version/main/guides/security-openid-connect-web-authentication#integration-with-github-and-other-oauth2-providers

Sergey

[Sergey Beryozkin]

On Tue, Nov 23, 2021 at 9:30 AM Sergey Beryozkin <sbia...@redhat.com> wrote:

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

I'm sorry, Phillip was very involved as well - helped a lot with getting a quality Dev UI support done around it

[Max Rydahl Andersen]

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

[Stuart Douglas]

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.

Stuart

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/D64F73C0-CE63-49E6-8C15-8C8AF5E743C2%40redhat.com.

[Sergey Beryozkin]

On Tue, Nov 23, 2021 at 10:37 AM 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.

I guess what you are saying is that users should just configure them directly - which I guess is a fair point.

If we start with the empty application.properties then, with a Keycloak specific knowledge, we know we can just create 2 default users in some roles, default client and realm.

We can only see that the user does not necessarily intend to use Keycloak if an OIDC URL is configured and then some basic URL analysis goes to figure out what kind of provider it is.

So if one goes to a DevConsole they'd see a `Provider: Auth0`, etc, I've tested all the options supported for Keycloak against Auth0.

So indeed, without the configuration it is not possible to offer any Dev UI support for the users.

It doesn't give me a "always accepting login" which could be nice to allow dev mode not reliant on accessible service.

I see. As far as the testing is concerned - we support testing the redirect flows with the OIDC wire mock for non-Keycloak services:

https://quarkus.io/version/main/guides/security-openid-connect-web-authentication#integration-testing

But for Dev UI - indeed, the service must be accessible, I'll also follow up on it in the next message

Thanks, Sergey

[Sergey Beryozkin]

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:

https://quarkus.io/version/main/guides/security-openid-connect-dev-services#dev-services-and-ui-support-for-other-openid-connect-providers

It would be good to do a POC project for some other provider but I'm not sure which one

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.

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.

Thanks, Sergey

[Sergey Beryozkin]

On Tue, Nov 23, 2021 at 12:05 PM Sergey Beryozkin <sbia...@redhat.com> wrote:

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:

https://quarkus.io/version/main/guides/security-openid-connect-dev-services#dev-services-and-ui-support-for-other-openid-connect-providers

It would be good to do a POC project for some other provider but I'm not sure which one

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.

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.

This is not quite correct, I updated it the other day to support the extra token grant request properties, so for ex, for Auth0, if you'd like to use a password grant, you do

quarkus.oidc.devui.grant.type=password

quarkus.oidc.devui.grant-options.password.audience=http://localhost:8080

so the token will get the audience set - but things like roles can't be controlled - it is scoped to the Admin Ui of a given provider. They might have their specific client API - which would require adding a new extension indeed

Sergey

[Sergey Beryozkin]

One more clarification,

On Tue, Nov 23, 2021 at 12:05 PM Sergey Beryozkin <sbia...@redhat.com> wrote:

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:

https://quarkus.io/version/main/guides/security-openid-connect-dev-services#dev-services-and-ui-support-for-other-openid-connect-providers

It would be good to do a POC project for some other provider but I'm not sure which one

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.

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 think it is not a correct message either - I believe we just should update the docs to recommend using a `prod` profile for `%prod.quarkus.oidc.application-type=web-app` - so in the dev mode it will default to `service` - as far as the Quarkus endpoint is concerned it likely `won't mind` how the token has reached it, from Dev UI or internally with the code flow completion...

Dev UI also needs to be improved to pass the custom scopes around when auth-ing into OIDC, recall now Steph had to configure it for Google...

Sergey

[Stephane Epardaud]

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. I haven't seen any justification that convinced me. I really think we're talking about two completely separate use-cases for OIDC.

--

Stéphane Épardaud

[Sergey Beryozkin]

On Tue, Nov 23, 2021 at 1:29 PM Stephane Epardaud <stephane...@gmail.com> wrote:

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.

Sounds good

 

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.

Using Keycloak does not mean everyone will want the role based access control, there are endpoints who just want to assert the token's signature is valid and allow an authenticated access, and then get something out of the token. So some Keycloak users just want to login to Keycloak :-).

And if we start with the empty properties we don't what provider uses plans to use, so as I said to Max, Keycloak is assumed to be the user choice - which can be easily `fixed` via the configuration

Sergey

[Erin Schnabel]

Keycloak can be especially handy for custom SSO/SAML systems, just as an example. Helps you separate the problem. All of your apps/infra can work with keycloak, and keycloak can deal with whatever Auth providers you have.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfXHbSMMYmabUThu%3DvaQbaOM9Tm3O2k7mEsdy6VOOvgeaQ%40mail.gmail.com.

--

Thanks,

Erin

 

------
Erin Schnabel <ebul...@redhat.com>

@ebullientworks

[William Burke]

Well, if you're going from all these sources you need a common view of the user data.  IIRC, some are a little different than others and some had different protocols.  Maybe its all solidified now around standard OIDC and you can write something generic.

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.

--

Bill Burke

Red Hat