security-openid-connect-web-authentication.adoc is out of sync with current code base and related quickstart

[rsvoboda]

security-openid-connect-web-authentication.adoc is out of sync with current code base and related quickstart

There were several adjustments to the codebase and security-openid-connect-web-authentication-quickstart was updated too
https://github.com/quarkusio/quarkus-quickstarts/commits/development/security-openid-connect-web-authentication-quickstart

security-openid-connect-web-authentication.adoc needs to catch up with those changes

[sberyozkin]

@rsvoboda Not sure it should be marked as a bug, since there was no code presented there. My understanding the code was not added there because the demo is not really about the code but the login, though may be that code can be copied.... But I'd consider it be an enhancement request :-) CC @pedroigor

[pedroigor]

@sberyozkin I think I agree. The guide is only about protecting a web app serving pages that can only be accessed after the user is authenticated.

@rsvoboda Do you mean we should update guide to describe in more detail the TokenResource ?

[rsvoboda]

I meant differences like

https://github.com/quarkusio/quarkus/blob/master/docs/src/main/asciidoc/security-openid-connect-web-authentication.adoc#configuring-using-the-applicationproperties-file

quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.client-type=web-app

https://github.com/quarkusio/quarkus-quickstarts/blob/adb7a530264249d02ede94474a6822bf605e1afd/security-openid-connect-web-authentication-quickstart/src/main/resources/application.properties#L1-L6

quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.application-type=web-app
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated
quarkus.log.category."com.gargoylesoftware.htmlunit.DefaultCssErrorHandler".level=ERROR

[sberyozkin]

Thanks @rsvoboda for pointing to it. We can probably avoid adding the htmlunit log category to the docs, it is really related to minimizing the noise during the test.

[rsvoboda]

a bit confused about quarkus.oidc.client-type=web-app vs quarkus.oidc.application-type=web-app difference

Seems quarkus.http.auth.permission.authenticated.paths=/* and quarkus.http.auth.permission.authenticated.policy=authenticated were necessary to pass tests. See quarkusio/quarkus-quickstarts#366

[sberyozkin]

@rsvoboda a user has just reported this issue on Zulip :-), I mean, the client-type is an old name and is not supported

[sberyozkin]

@rsvoboda Hmm, not sure now why those permission properties had to be added, @stuartwdouglas, can you please clarify ? I'm not seeing which changes at #5315 might've caused it. If all the users need to do is to login with OIDC code flow, should they be required to configure the permissions ?

[sberyozkin]

Started with #5414. I'd still like to discuss with Stuart if we need to ask the users to configure the permissions in the application.properties in addition to enabling the OIDC adapter.

[stuartwdouglas]

You need to say which parts of the app need permissions. If you are only going to public pages it will not ask you to log in, only if you attempt to access a protected resource.

If you are using REST endpoints this can just be via annotations, or you can use the application.properties approach.

[sberyozkin]

@stuartwdouglas right, but can we get it by default: one should be authenticated to access anything in the URI space of the application if we have an non-anonymous SecurityIdentity available ?
IMHO we will not be too strict here, if some users need a semi-secured endpoint then let them do this extra configuration in application.properties or add @Authenticated. In this case it feels like a user has to express the intent twice, prepare OIDC (to get the user authenticated) and then do some more non-OIDC configuration to make this authentication effective.
What do you think ?

[pedroigor]

Considered that security is now layered so that the security extension provides the base for any other security extension, I think the way it works is correct.

It is easy to explain and tell our security story. In a regular application, you need to provide the rules that should initiate authentication. For OIDC the behavior should be the same, the fact that you are enabling the extension does not necessarily mean it is automatically protected so that the user should tell what parts (if not everything) he wants to enforce authentication.

[sberyozkin]

@pedroigor sure; you are probably referring to a regular Java EE application :-) ? The reason we enable OIDC is because we want to authenticate the users. If, as a user, I don't want a semi-secured application, then having to tell Quarkus with more configuration (as in the quickstart example where a wildcard authentication policy is applied) is like having to repeat my intent twice. IMHO it does not help with the ease of the security experience. May be it is only me.

@pedroigor, @stuartwdouglas If we enable a wildcard authenticated policy mode by default, where can we go wrong ? The only issue I can see is that the users who are OK with some of their application resources being possibly unprotected will have to do the extra configuration to permit an access to some resources, but this was my point earlier, let those users do this extra configuration, as opposed to the users who just would like to secure their applications

[pedroigor]

@sberyozkin I understand your point and it makes sense. But if you take the behavior we have today when using a web.xml you also need to set security-constraint to explicitly define the resources that should be protected.

I think this approach is good also because the user is telling us the intent instead of figuring out automatically and protecting everything. It also makes more clear what are the resources being protected and those made public.