Red Hat Summit이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Basic authentication
Abstract
Providing feedback on Red Hat build of Quarkus documentation
To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account.
Procedure
- Click the following link to create a ticket.
- Enter a brief description of the issue in the Summary.
- Provide a detailed description of the issue or enhancement in the Description. Include a URL to where the issue occurs in the documentation.
- Clicking Submit creates and routes the issue to the appropriate documentation team.
Chapter 1. Basic authentication
HTTP Basic authentication is one of the least resource-demanding techniques that enforce access controls to web resources. You can secure your Quarkus application endpoints by using HTTP Basic authentication. Quarkus includes a built-in authentication mechanism for Basic authentication.
Basic authentication uses fields in the HTTP header and does not rely on HTTP cookies, session identifiers, or login pages.
1.1. Authorization header
An HTTP user agent, like a web browser, uses an Authorization header to provide a username and password in each HTTP request. The header is specified as Authorization: Basic <credentials>, where credentials are the Base64 encoding of the user ID and password, joined by a colon.
Example:
If the user name is Alice and the password is secret, the HTTP authorization header would be Authorization: Basic QWxjZTpzZWNyZXQ=, where QWxjZTpzZWNyZXQ= is a Base64 encoded representation of the Alice:secret string.
The Basic authentication mechanism does not provide confidentiality protection for the transmitted credentials. The credentials are merely encoded with Base64 when in transit, and not encrypted or hashed in any way. Therefore, to provide confidentiality, use Basic authentication with HTTPS.
Basic authentication is a well-specified, simple challenge and response scheme that all web browsers and most web servers understand.
1.2. Limitations with using Basic authentication
The following table outlines some limitations of using HTTP Basic authentication to secure your Quarkus applications:
| Limitation | Description |
|---|---|
| Credentials are sent as plain text | Use HTTPS with Basic authentication to avoid exposing the credentials. The risk of exposing credentials as plain text increases if a load balancer terminates HTTPS because the request is forwarded to Quarkus over HTTP. Furthermore, in multi-hop deployments, the credentials can be exposed if HTTPS is used between the client and the first Quarkus endpoint only, and the credentials are propagated to the next Quarkus endpoint over HTTP. |
| Credentials are sent with each request | In Basic authentication, a username and password must be sent with each request, increasing the risk of exposing credentials. |
| 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. |
1.3. Implementing Basic authentication in Quarkus
For more information about how you can secure your Quarkus applications by using Basic authentication, see the following resources:
1.4. Role-based access control
Red Hat build of Quarkus also includes built-in security to allow for role-based access control (RBAC) based on the common security annotations @RolesAllowed, @DenyAll, @PermitAll on REST endpoints and CDI beans. For more information, see the Quarkus Authorization of web endpoints guide.
1.5. References
Chapter 2. Enable Basic authentication
Enable Basic authentication for your Quarkus project and allow users to authenticate with a username and password.
2.1. Prerequisites
You have installed at least one extension that provides an
IdentityProviderbased on username and password. For example:
The following procedure outlines how you can enable Basic authentication for your application by using the elytron-security-properties-file extension.
2.2. Procedure
In the
application.propertiesfile, set thequarkus.http.auth.basicproperty totrue.quarkus.http.auth.basic=true
Optional: In a non-production environment only and purely for testing Quarkus Security in your applications:
To enable authentication for the embedded realm, set the
quarkus.security.users.embedded.enabledproperty totrue.quarkus.security.users.embedded.enabled=true
You can also configure the required user credentials, user name, secret, and roles. For example:
quarkus.http.auth.basic=true quarkus.security.users.embedded.enabled=true quarkus.security.users.embedded.plain-text=true quarkus.security.users.embedded.users.alice=alice 1 quarkus.security.users.embedded.users.bob=bob 2 quarkus.security.users.embedded.roles.alice=admin 3 quarkus.security.users.embedded.roles.bob=user 4
For information about other methods that you can use to configure the required user credentials, see the Configuring User Information section of the Quarkus "Security Testing" guide.
ImportantConfiguring user names, secrets, and roles in the
application.propertiesfile is appropriate only for testing scenarios. For securing a production application, it is crucial to use a database to store this information.
2.3. Next steps
For a more detailed walk-through that shows you how to configure Basic authentication together with Jakarta Persistence for storing user credentials in a database, see the Getting started with Security by using Basic authentication and Jakarta Persistence guide.
