Documentation describing Basic authentication stress additional complexity while this complexity is handled by extensions providing IdentityProvider

[michalvavrik]

Description

Here https://quarkus.io/guides/security-basic-authentication-howto I can see following text saying that Basic authentication adds extra complexity.

Application complexity increases:

The Quarkus application must validate that usernames, passwords, and roles are managed securely. This process, however, can introduce significant complexity to the application. Depending on the use case, other authentication mechanisms that delegate username, password, and role management to specialized services might be more secure.

I think that what the paragraph tries to say is that if you implement the identity provider, you have to write a lot of code. There is no other additional complexity increased. I suggested that instead, we just say: it could be complex if you don't use one of:

• Quarkus Security Jakarta Persistence extensions (security-jpa or security-jpa-reactive)
• Elytron security properties file extension (quarkus-elytron-security-properties-file)
• Elytron security JDBC extension (quarkus-elytron-security-jdbc)

Implementation ideas

No response

[sberyozkin]

@michalvavrik

I'm assuming you are referring to https://quarkus.io/guides/security-basic-authentication#limitations-with-using-basic-authentication

think that what the paragraph tries to say is that if you implement the identity provider, you have to write a lot of code

Not really, what that paragraph implies that it is now a responsibility of Quarkus application to manage users/secrets (indirectly, but the application has to deal with adding and configuring extensions like the ones you listed). validate can be a bit misleading there, but ensure would be fine IMHO. These specific identity provider extensions are discussed separately, at this level it is a very high level intro into pros and cons of using Basic authentication

[michalvavrik]

Not really, what that paragraph implies that it is now a responsibility of Quarkus application to manage users/secrets (indirectly, but the application has to deal with adding and configuring extensions like the ones you listed).

But you know how this is implemented. How exactly is Quarkus managing users and secrets in relation to Basic authentication? It extract credentials and passes them to identity providers. That logic is probably much simpler than any other mechanism. Extensions providing identity are storing it and retrieving it, which if you look how Keycloak is written, it's stored in database which can be much more complex, let alone caching which is one of the hardest things. Additionally, if you compare OIDC authentication mechanism with basic authentication mechanism, the basic one is simpler, it does less things, doesn't it? It is called "Application complexity increases" so I don't agree with conclusion that specialized services might be more secure. If you disagree, please provide concrete example why is it not secure.

I'd like to point out that main disadvantages why not to use basic are already explained in Credentials are sent with each request and Credentials are sent as plain text.

[sberyozkin]

May be something like this can be clearer...

The Quarkus application must ensure  that usernames, passwords, and roles are managed securely, by choosing one of the following identity providers: (the ones you listed). This process, however, can introduce an additional complexity to the application. Depending on the use case, using other authentication mechanisms that delegate username, password, and role management to specialized services, such as OpenId Connect providers,  might be more appropriate.

[michalvavrik]

btw I realized this is very small thing, I just mentioned it when doing docs review, it's no biggie.

[michalvavrik]

May be something like this can be clearer...

The Quarkus application must ensure  that usernames, passwords, and roles are managed securely, by choosing one of the following identity providers: (the ones you listed). This process, however, can introduce an additional complexity to the application. Depending on the use case, using other authentication mechanisms that delegate username, password, and role management to specialized services, such as OpenId Connect providers,  might be more appropriate.

looks better, thanks

[sberyozkin]

Np, thanks for that, the docs have to be constantly reviewed :-)