*web-eid-authtoken-validation-java* is a Java library for issuing challenge nonces and validating Web eID authentication tokens during secure authentication with electronic ID (eID) smart cards in web applications.
@@ -48,7 +48,7 @@ Implement the session-backed challenge nonce store as follows:
import org.springframework.beans.factory.ObjectFactory;
import eu.webeid.security.challenge.ChallengeNonce;
import eu.webeid.security.challenge.ChallengeNonceStore;
-import javax.servlet.http.HttpSession;
+import jakarta.servlet.http.HttpSession;
public class SessionBackedChallengeNonceStore implements ChallengeNonceStore {
@@ -79,7 +79,7 @@ public class SessionBackedChallengeNonceStore implements ChallengeNonceStore {
## 3. Configure the challenge nonce generator
-The validation library needs to generate authentication challenge nonces and store them for later validation in the challenge nonce store. Overview of challenge nonce usage is provided in the [Web eID system architecture document](https://github.com/web-eid/web-eid-system-architecture-doc#authentication-1). The challenge nonce generator will be used in the REST endpoint that issues challenges; it is thread-safe and should be scoped as a singleton.
+The validation library needs to generate authentication challenge nonces and store them for later validation in the challenge nonce store. Overview of challenge nonce usage is provided in the [Web eID system architecture document](https://github.com/web-eid/web-eid-system-architecture-doc#authentication-1). The challenge nonce generator will be used in the filter that issues challenges; it is thread-safe and should be scoped as a singleton.
Configure the challenge nonce generator as follows:
@@ -99,7 +99,7 @@ import eu.webeid.security.challenge.ChallengeNonceStore;
## 4. Add trusted certificate authority certificates
-You must explicitly specify which **intermediate** certificate authorities (CAs) are trusted to issue the eID authentication and OCSP responder certificates. CA certificates can be loaded from either the truststore file, resources or any stream source. We use the [`CertificateLoader`](https://github.com/web-eid/web-eid-authtoken-validation-java/blob/main/src/main/java/eu/webeid/security/certificate/CertificateLoader.java) helper class to load CA certificates from resources here, but consider using [the truststore file](./blob/example/main/src/main/java/eu/webeid/example/config/ValidationConfiguration.java#L104-L123) instead.
+You must explicitly specify which **intermediate** certificate authorities (CAs) are trusted to issue the eID authentication and OCSP responder certificates. CA certificates can be loaded from either the truststore file, resources or any stream source. We use the [`CertificateLoader`](src/main/java/eu/webeid/security/certificate/CertificateLoader.java) helper class to load CA certificates from resources here, but consider loading the truststore file (see [loadTrustedCACertificatesFromTrustStore](example/src/main/java/eu/webeid/example/config/ValidationConfiguration.java#L104-L123)) instead.
First, copy the trusted certificates, for example `ESTEID2018.cer`, to `resources/cacerts/`, then load the certificates as follows:
@@ -134,36 +134,86 @@ import eu.webeid.security.validator.AuthTokenValidatorBuilder;
...
```
-## 6. Add a REST endpoint for issuing challenge nonces
+## 6. Add a filter for issuing challenge nonces
-A REST endpoint that issues challenge nonces is required for authentication. The endpoint must support `GET` requests.
+Request Filters that issue challenge nonces for regular Web eID and Web eID for Mobile authentication flows are required for authentication.
+The filters must support POST requests.
-In the following example, we are using the [Spring RESTful Web Services framework](https://spring.io/guides/gs/rest-service/) to implement the endpoint, see also the full implementation [here](example/blob/main/src/main/java/eu/webeid/example/web/rest/ChallengeController.java).
+The `WebEidChallengeNonceFilter` handles `/auth/challenge` requests and issues a new nonce for regular Web eID authentication flow.
+See the full implementation [here](example/src/main/java/eu/webeid/example/security/WebEidChallengeNonceFilter.java).
```java
-import org.springframework.web.bind.annotation.GetMapping;
-import org.springframework.web.bind.annotation.RequestMapping;
-import org.springframework.web.bind.annotation.RestController;
-import eu.webeid.security.challenge.ChallengeNonceGenerator;
-...
+public final class WebEidChallengeNonceFilter extends OncePerRequestFilter {
+ private static final ObjectWriter OBJECT_WRITER = new ObjectMapper().writer();
+ private final RequestMatcher requestMatcher;
+ private final ChallengeNonceGenerator nonceGenerator;
+
+ public WebEidChallengeNonceFilter(String path, ChallengeNonceGenerator nonceGenerator) {
+ this.requestMatcher = PathPatternRequestMatcher.withDefaults().matcher(HttpMethod.POST, path);
+ this.nonceGenerator = nonceGenerator;
+ }
+
+ @Override
+ protected void doFilterInternal(
+ @NonNull HttpServletRequest request,
+ @NonNull HttpServletResponse response,
+ @NonNull FilterChain chain
+ ) throws ServletException, IOException {
+ if (!requestMatcher.matches(request)) {
+ chain.doFilter(request, response);
+ return;
+ }
+
+ var dto = new ChallengeDTO(nonceGenerator.generateAndStoreNonce().getBase64EncodedNonce());
+
+ response.setContentType(MediaType.APPLICATION_JSON_VALUE);
+ OBJECT_WRITER.writeValue(response.getWriter(), dto);
+ }
-@RestController
-@RequestMapping("auth")
-public class ChallengeController {
+ public record ChallengeDTO(String nonce) {}
+}
+```
- @Autowired // for brevity, prefer constructor dependency injection
- private ChallengeNonceGenerator nonceGenerator;
+The `WebEidMobileAuthInitFilter` handles `/auth/mobile/init` requests for authentication flows using **Web eID token format v1.1**. It generates a challenge nonce and returns a deep link URI that embeds both the challenge nonce and the authentication endpoint required for initiating the v1.1 flow.
+See the full implementation [here](example/src/main/java/eu/webeid/example/security/WebEidMobileAuthInitFilter.java).
- @GetMapping("challenge")
- public ChallengeDTO challenge() {
- // a simple DTO with a single 'nonce' field
- final ChallengeDTO challenge = new ChallengeDTO();
- challenge.setNonce(nonceGenerator.generateAndStoreNonce().getBase64EncodedNonce());
- return challenge;
+```java
+@Override
+protected void doFilterInternal(@NonNull HttpServletRequest request,
+ @NonNull HttpServletResponse response,
+ @NonNull FilterChain chain) throws IOException, ServletException {
+ if (!requestMatcher.matches(request)) {
+ chain.doFilter(request, response);
+ return;
}
+
+ var challenge = nonceGenerator.generateAndStoreNonce();
+
+ String loginUri = ServletUriComponentsBuilder.fromCurrentContextPath()
+ .path(mobileLoginPath).build().toUriString();
+
+ String payloadJson = OBJECT_WRITER.writeValueAsString(
+ new AuthPayload(challenge.getBase64EncodedNonce(), loginUri,
+ webEidMobileProperties.requestSigningCert() ? Boolean.TRUE : null)
+ );
+ String encoded = Base64.getEncoder().encodeToString(payloadJson.getBytes(StandardCharsets.UTF_8));
+ String authUri = getAuthUri(encoded);
+
+ response.setContentType(MediaType.APPLICATION_JSON_VALUE);
+ OBJECT_WRITER.writeValue(response.getWriter(), new AuthUri(authUri));
}
```
+Both filters are registered in the Spring Security filter chain in ApplicationConfiguration.
+See the full implementation [here](example/src/main/java/eu/webeid/example/config/ApplicationConfiguration.java):
+```java
+http
+ .addFilterBefore(new WebEidMobileAuthInitFilter("/auth/mobile/init", "/auth/mobile/login", challengeNonceGenerator, webEidMobileProperties),
+ UsernamePasswordAuthenticationFilter.class)
+ .addFilterBefore(new WebEidChallengeNonceFilter("/auth/challenge", challengeNonceGenerator),
+ UsernamePasswordAuthenticationFilter.class)
+```
+
Also, see general guidelines for implementing secure authentication services [here](https://github.com/SK-EID/smart-id-documentation/wiki/Secure-Implementation-Guide).
## 7. Implement authentication
@@ -172,17 +222,20 @@ Authentication consists of calling the `validate()` method of the authentication
When using [Spring Security](https://spring.io/guides/topicals/spring-security-architecture) with standard cookie-based authentication,
-- implement a custom authentication provider that uses the authentication token validator for authentication as shown [here](example/blob/main/src/main/java/eu/webeid/example/security/AuthTokenDTOAuthenticationProvider.java),
-- implement an AJAX authentication processing filter that extracts the authentication token and passes it to the authentication manager as shown [here](example/blob/main/src/main/java/eu/webeid/example/security/WebEidAjaxLoginProcessingFilter.java),
-- configure the authentication provider and authentication processing filter in the application configuration as shown [here](example/blob/main/src/main/java/eu/webeid/example/config/ApplicationConfiguration.java).
+- implement a custom authentication provider that uses the authentication token validator for authentication as shown [here](example/src/main/java/eu/webeid/example/security/WebEidAuthenticationProvider.java),
+- implement an AJAX authentication processing filter that extracts the authentication token and passes it to the authentication manager as shown [here](example/src/main/java/eu/webeid/example/security/WebEidAjaxLoginProcessingFilter.java),
+- configure the authentication provider and authentication processing filter in the application configuration as shown [here](example/src/main/java/eu/webeid/example/config/ApplicationConfiguration.java).
-The gist of the validation is [in the `authenticate()` method](example/blob/main/src/main/java/eu/webeid/example/security/AuthTokenDTOAuthenticationProvider.java#L74-L76) of the authentication provider:
+The gist of the validation is [in the `authenticate()` method](example/src/main/java/eu/webeid/example/security/WebEidAuthenticationProvider.java#L74-L76) of the authentication provider:
```java
try {
- String nonce = challengeNonceStore.getAndRemove().getBase64EncodedNonce();
- X509Certificate userCertificate = tokenValidator.validate(authToken, nonce);
- return WebEidAuthentication.fromCertificate(userCertificate, authorities);
+ final String nonce = challengeNonceStore.getAndRemove().getBase64EncodedNonce();
+ final X509Certificate userCertificate = tokenValidator.validate(authToken, nonce);
+ final var signingCertificate = requireSigningCert && !CollectionUtils.isEmpty(authToken.getUnverifiedSigningCertificates())
+ ? authToken.getUnverifiedSigningCertificates().getFirst() // NOTE: Handling multiple signing certificates is out of scope of this example.
+ : null;
+ return WebEidAuthentication.fromCertificate(userCertificate, signingCertificate, authorities);
} catch (AuthTokenException e) {
...
```
@@ -202,10 +255,11 @@ try {
- [Basic usage](#basic-usage-1)
- [Extended configuration](#extended-configuration-1)
- [Differences between version 1 and version 2](#differences-between-version-1-and-version-2)
+- [Authentication token format versions](#authentication-token-format-versions)
# Introduction
-The Web eID authentication token validation library for Java contains the implementation of the Web eID authentication token validation process in its entirety to ensure that the authentication token sent by the Web eID browser extension contains valid, consistent data that has not been modified by a third party. It also implements secure challenge nonce generation as required by the Web eID authentication protocol. It is easy to configure and integrate into your authentication service.
+The Web eID authentication token validation library for Java contains the implementation of the Web eID authentication token validation process in its entirety to ensure that the authentication token sent by the Web eID browser extension or mobile application contains valid, consistent data that has not been modified by a third party. It also implements secure challenge nonce generation as required by the Web eID authentication protocol. It is easy to configure and integrate into your authentication service.
The authentication protocol, authentication token format, validation requirements and challenge nonce usage is described in more detail in the [Web eID system architecture document](https://github.com/web-eid/web-eid-system-architecture-doc#authentication-1).
@@ -216,7 +270,7 @@ In the following,
- **origin** is defined as the website origin, the URL serving the web application,
- **challenge nonce** (or challenge) is defined as a cryptographic nonce, a large random number that can be used only once, with at least 256 bits of entropy.
-The Web eID authentication token is a JSON data structure that looks like the following example:
+The Web eID authentication token (format **`web-eid:1.0`**) is a JSON data structure that looks like the following example:
```json
{
@@ -248,6 +302,55 @@ It contains the following fields:
The value that is signed by the user’s authentication private key and included in the `signature` field is `hash(origin)+hash(challenge)`. The hash function is used before concatenation to ensure field separation as the hash of a value is guaranteed to have a fixed length. Otherwise the origin `example.com` with challenge nonce `.eu1234` and another origin `example.com.eu` with challenge nonce `1234` would result in the same value after concatenation. The hash function `hash` is the same hash function that is used in the signature algorithm, for example SHA256 in case of RS256.
+The Web eID authentication token (format **`web-eid:1.1`**) is a JSON data structure that looks like the following example:
+
+```json
+{
+ "unverifiedCertificate": "MIIFozCCA4ugAwIBAgIQHFpdK-zCQsFW4...",
+ "algorithm": "RS256",
+ "signature": "HBjNXIaUskXbfhzYQHvwjKDUWfNu4yxXZha...",
+ "unverifiedSigningCertificates": [
+ {
+ "certificate": "MIIFikACB3ugAwASAgIHHFrtdZ-zeQsas1...",
+ "supportedSignatureAlgorithms": [
+ {
+ "cryptoAlgorithm": "ECC",
+ "hashFunction": "SHA-384",
+ "paddingScheme": "NONE"
+ }
+ ]
+ }
+ ],
+ "format": "web-eid:1.1",
+ "appVersion": "https://web-eid.eu/web-eid-app/releases/v2.0.0"
+}
+```
+It contains the following fields:
+
+- `unverifiedSigningCertificates`: an array of objects containing signing certificate information.
+
+Each object inside `unverifiedSigningCertificates` contains:
+
+- `certificate`: base64-encoded DER-encoded signing certificate,
+
+- `supportedSignatureAlgorithms`: list of supported algorithms in the following format:
+
+ - `cryptoAlgorithm`: the cryptographic algorithm used for the key,
+
+ - `hashFunction`: the hashing algorithm used,
+
+ - `paddingScheme`: the padding scheme used (if applicable).
+
+
+Allowed values are:
+
+ cryptoAlgorithm: "ECC", "RSA"
+
+ hashFunction:
+ "SHA-224", "SHA-256", "SHA-384", "SHA-512",
+ "SHA3-224", "SHA3-256", "SHA3-384", "SHA3-512"
+
+ paddingScheme: "NONE", "PKCS1.5", "PSS"
# Authentication token validation
@@ -255,8 +358,13 @@ The authentication token validation process consists of two stages:
- First, **user certificate validation**: the validator parses the token and extracts the user certificate from the *unverifiedCertificate* field. Then it checks the certificate expiration, purpose and policies. Next it checks that the certificate is signed by a trusted CA and checks the certificate status with OCSP.
- Second, **token signature validation**: the validator validates that the token signature was created using the provided user certificate by reconstructing the signed data `hash(origin)+hash(challenge)` and using the public key from the certificate to verify the signature in the `signature` field. If the signature verification succeeds, then the origin and challenge nonce have been implicitly and correctly verified without the need to implement any additional security checks.
+- Additional validation for **Web eID authentication tokens (format v1.1)**: the token must contain the `unverifiedSigningCertificates` field with at least one signing certificate entry. Each entry's `supportedSignatureAlgorithms` are validated against the set of allowed cryptographic algorithms, hash functions, and padding schemes. For each signing certificate, the following checks are performed:
+ - The subject must match the subject of the authentication certificate, ensuring both certificates belong to the same user.
+ - The issuing authority must match that of the authentication certificate, verified via the Authority Key Identifier (AKI) extension.
+ - The certificate must not be expired.
+ - The certificate must contain the non-repudiation key usage bit required for digital signatures.
-The website back end must lookup the challenge nonce from its local store using an identifier specific to the browser session, to guarantee that the authentication token was received from the same browser to which the corresponding challenge nonce was issued. The website back end must guarantee that the challenge nonce lifetime is limited and that its expiration is checked, and that it can be used only once by removing it from the store during validation.
+The website back end must look up the challenge nonce from its local store using an identifier specific to the browser session, to guarantee that the authentication token was received from the same browser to which the corresponding challenge nonce was issued. The website back end must guarantee that the challenge nonce lifetime is limited and that its expiration is checked, and that it can be used only once by removing it from the store during validation.
## Basic usage
@@ -342,7 +450,7 @@ The authentication protocol requires support for generating challenge nonces, la
The `-Djava.security.egd=file:/dev/./urandom` command line argument is added to `pom.xml` to avoid the risk of having the code execution blocked unexpectedly during random generation. Without this, the JVM uses `/dev/random`, which can block, to seed the `SecureRandom` class.
-The authentication protocol requires a REST endpoint that issues challenge nonces as described in section *[6. Add a REST endpoint for issuing challenge nonces](#6-add-a-rest-endpoint-for-issuing-challenge-nonces)*.
+The authentication protocol requires a filter that issues challenge nonces as described in section *[6. Add a filter for issuing challenge nonces](#6-add-a-filter-for-issuing-challenge-nonces)*.
Nonce usage is described in more detail in the [Web eID system architecture document](https://github.com/web-eid/web-eid-system-architecture-doc#authentication-1).
@@ -362,18 +470,18 @@ The `generateAndStoreNonce()` method both generates the nonce and saves it in th
## Extended configuration
-The following additional configuration options are available in `NonceGeneratorBuilder`:
+The following additional configuration options are available in `ChallengeNonceGeneratorBuilder`:
- `withNonceTtl(Duration duration)` – overrides the default challenge nonce time-to-live duration. When the time-to-live passes, the nonce is considered to be expired. Default challenge nonce time-to-live is 5 minutes.
- `withSecureRandom(SecureRandom)` - allows to specify a custom `SecureRandom` instance.
Extended configuration example:
```java
-NonceGenerator generator = new NonceGeneratorBuilder()
- .withChallengeNonceStore(store)
- .withNonceTtl(Duration.ofMinutes(5))
- .withSecureRandom(customSecureRandom)
- .build();
+ChallengeNonceGenerator generator = new ChallengeNonceGeneratorBuilder()
+ .withChallengeNonceStore(store)
+ .withNonceTtl(Duration.ofMinutes(5))
+ .withSecureRandom(customSecureRandom)
+ .build();
```
# Differences between version 1 and version 2
@@ -381,3 +489,16 @@ NonceGenerator generator = new NonceGeneratorBuilder()
In version 1, the generated challenge nonces were stored in a JSR107 compatible cache. The goal of using a cache was to support stateful and stateless authentication with a universal API that uses the same underlying mechanism. However, in case the website had a CSRF vulnerability, this made the solution vulnerable to [forged login attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests) (the attacker could trick the victim to submit the authentication token with the attacker's challenge nonce to the website using a CSRF attack, so that the victim was authenticated to the website as the attacker). To mitigate this attack, in version 2 the requirement is that the library adopter must guarantee that the authentication token is received from the same browser to which the corresponding challenge nonce was issued. The recommended solution is to use a session-backed challenge nonce store, as in the code examples above. The library no longer uses the JSR107 cache API and provides a `ChallengeNonceStore` interface instead.
In the internal implementation, the Web eID authentication token format changed in version 2. In version 1, the authentication token was in the OpenID X509 ID Token (JWT) format in order to be compatible with the standard OpenID Connect ID Token specification. During independent security review it was pointed out that any similarities of the Web eID authentication token to the JWT format are actually undesirable, as they would imply that the claims presented in the Web eID authentication token can be trusted and processed, while in fact they must be ignored, as they can be manipulated at the client side. The presence of the claims in the authentication token introduces a risk of vulnerabilities in case the authentication implementer decides to rely on any of them for making security critical decisions or decides to apply the same standard validation workflow that is applied to standard JWTs. Since there does not exist a standardized format for an authentication proof that corresponds to the requirements of the Web eID authentication protocol, a special purpose JSON-based format for the Web eID authentication token was adopted in version 2. The format is described in detail in the section *[Authentication token format](#authentication-token-format)*, and the full analysis of the format change is available in [this article](https://web-eid.github.io/web-eid-system-architecture-doc/web-eid-auth-token-v2-format-spec.pdf).
+
+# Authentication Token Format Versions
+
+The Web eID authentication protocol defines two token formats currently supported by this library:
+
+- **Format v1.0** – Used in desktop Web eID authentication flows with traditional smart card readers.
+
+- **Format v1.1** – An extended authentication token format that allows signing certificate information to be included in the authentication response.
+ - `unverifiedSigningCertificates` – an array of signing certificate entries. Each entry contains:
+ - `certificate` – a base64-encoded DER-encoded signing certificate;
+ - `supportedSignatureAlgorithms` – a list of supported signature algorithms associated with that certificate;
+
+Both token formats follow the same validation principles, differing only in the structure of embedded certificates and the additional verification steps required for v1.1.
diff --git a/example/README.md b/example/README.md
index f0e66519..ebf58d68 100644
--- a/example/README.md
+++ b/example/README.md
@@ -1,6 +1,6 @@
# Web eID Spring Boot example
-
+
This project is an example Spring Boot web application that shows how to implement strong authentication
and digital signing with electronic ID smart cards using Web eID.
@@ -51,7 +51,7 @@ You can specify the profile as a command-line argument to the Maven wrapper comm
### 5. Run the application
-Spring Boot web applications can be run from the command-line. You need to have the Java Development Kit 17 installed for building the application package and running the application.
+Spring Boot web applications can be run from the command-line. You need to have the Java Development Kit 21 installed for building the application package and running the application.
Build and run the application with the following command in a terminal window:
@@ -82,6 +82,7 @@ When the application has started, open the _ngrok_ HTTPS URL in your preferred w
- [Using DigiDoc4j in production mode with the `prod` profile](#using-digidoc4j-in-production-mode-with-the-prod-profile)
+ [Stateful and stateless authentication](#stateful-and-stateless-authentication)
+ [Assuring that the signing and authentication certificate subjects match](#assuring-that-the-signing-and-authentication-certificate-subjects-match)
+ + [Requesting the signing certificate in a separate step](#requesting-the-signing-certificate-in-a-separate-step)
* [HTTPS support](#https-support)
+ [How to verify that HTTPS is configured properly](#how-to-verify-that-https-is-configured-properly)
* [Deployment](#deployment)
@@ -100,7 +101,8 @@ This repository contains the code of a minimal Spring Boot web application that
- Spring Security,
- the Web eID authentication token validation library [_web-eid-authtoken-validation-java_](https://github.com/web-eid/web-eid-authtoken-validation-java),
- the Web eID JavaScript library [_web-eid.js_](https://github.com/web-eid/web-eid.js),
-- the digital signing library [_DigiDoc4j_](https://github.com/open-eid/digidoc4j).
+- the digital signing library [_DigiDoc4j_](https://github.com/open-eid/digidoc4j),
+- the Android application [_MOPP-Android_](https://github.com/open-eid/MOPP-Android/).
The project uses Maven for managing the dependencies and building the application. Maven project configuration file `pom.xml` is in the root of the project.
@@ -113,11 +115,15 @@ The source code folder `src` contains the application source code and resources
The `src/main/java/eu/webeid/example` directory contains the Spring Boot application Java class and the following subdirectories:
- `config`: Spring and HTTP security configuration, Web eID authentication token validation library configuration, trusted CA certificates loading etc,
-- `security`: Web eID authentication token validation library integration with Spring Security via an `AuthenticationProvider` and `AuthenticationProcessingFilter`,
-- `service`: Web eID signing service implementation that uses DigiDoc4j, and DigiDoc4j runtime configuration,
-- `web`: Spring Web MVC controller for the welcome page and Spring Web REST controllers that provide endpoints
- - for getting the challenge nonce used by the authentication token validation library,
- - for digital signing.
+- `security`: Web eID authentication token validation library integration with Spring Security
+ - `AuthenticationProvider` and `AuthenticationProcessingFilter` for handling Web eID authentication tokens,
+ - `WebEidChallengeNonceFilter` for issuing the challenge nonce required by the authentication flow,
+ - `WebEidMobileAuthInitFilter` for issuing the challenge nonce and generating the deep link with the authentication request, used to initiate the mobile authentication flow,
+ - `WebEidAjaxLoginProcessingFilter` and `WebEidLoginPageGeneratingFilter` for handling login requests.
+- `service`: Web eID signing service implementation that uses DigiDoc4j, and DigiDoc4j runtime configuration.
+ - `SigningService`: prepares ASiC-E containers and finalizes signatures.
+ - `MobileSigningService`: orchestrates the mobile signing flow (builds mobile signing requests/responses) and supports requesting the signing certificate in a separate step when enabled by configuration.
+- `web`: Spring Web MVC controller for the welcome page and Spring Web REST controller that provides a digital signing endpoint.
The `src/resources` directory contains the resources used by the application:
@@ -134,7 +140,7 @@ The `src/tests` directory contains the application test suite. The most importan
As described in section [_4. Choose either the `dev` or `prod` profile_](#4-choose-either-the-dev-or-prod-profile) above, the application has two different configuration profiles: `dev` profile for running the application in development mode and `prod` profile for production mode. The `dev` profile is activated by default.
-The profile-specific configuration files `src/main/resources/application-{dev,prod}.yaml` contain the `web-eid-auth-token.validation.use-digidoc4j-prod-configuration` setting that configures DigiDoc4j either in test or production mode, and a setting for configuring the origin URL as described in section [_2. Configure the origin URL_](#2-configure-the-origin-url) above. Additionally, the `web-eid-auth-token.validation.truststore-password` setting specifies the truststore password used in the `prod` profile.
+The profile-specific configuration files `src/main/resources/application-{dev,prod}.yaml` contain the `web-eid-auth-token.validation.use-digidoc4j-prod-configuration` setting that configures DigiDoc4j either in test or production mode, and a setting for configuring the origin URL as described in section [_2. Configure the origin URL_](#2-configure-the-origin-url) above. Additionally, the `web-eid-auth-token.validation.truststore-password` setting specifies the truststore password used in the `prod` profile. The `web-eid-mobile` section configures the mobile authentication flow, including the `base-request-uri` for deep link generation and the `request-signing-cert` flag that controls whether the signing certificate is requested during authentication.
The main configuration file `src/main/resources/application.yaml` is shared by all profiles and contains logging configuration and settings that make the session cookie secure behind a reverse proxy as described in section [_HTTPS support_](#https-support) below.
@@ -144,7 +150,7 @@ Spring Security has CSRF protection enabled by default. Web eID requires CSRF pr
### Integration with Web eID components
-Detailed overview of Java code changes required for integrating Web eID authentication token validation is available in the [_web-eid-authtoken-validation-java_ library README](https://github.com/web-eid/web-eid-authtoken-validation-java/blob/main/README.md). There are instructions for configuring the nonce generator, trusted certificate authority certificates, authentication token validator, Spring Security authentication integration and REST endpoints. The corresponding Java code is in the `src/main/java/eu/webeid/example/{config,security,web/rest}` directories.
+Detailed overview of Java code changes required for integrating Web eID authentication token validation is available in the [_web-eid-authtoken-validation-java_ library README](https://github.com/web-eid/web-eid-authtoken-validation-java/blob/main/README.md). There are instructions for configuring the nonce generator, trusted certificate authority certificates, authentication token validator, Spring Security authentication integration and security filters. The corresponding Java code is in the `src/main/java/eu/webeid/example/{config,security,web/rest}` directories.
A similar overview of JavaScript and HTML code changes required for authentication and digital signing with Web eID is available in the [web-eid.js library README](https://github.com/web-eid/web-eid.js/blob/main/README.md). The corresponding JavaScript and HTML code is in the `src/resources/{static,templates}` directories.
@@ -174,6 +180,16 @@ A common alternative to stateful authentication is stateless authentication with
It is usually required to verify that the signing certificate subject matches the authentication certificate subject by assuring that both ID codes match. This check is implemented at the beginning of the `SigningService.prepareContainer()` method.
+### Requesting the signing certificate in a separate step
+
+In some deployments, the signing certificate is not reused from the authentication flow. Instead, it is retrieved directly from the user’s ID-card during the signing process itself.
+
+This approach is useful when the signing process is performed without a prior authentication step. For example, in a mobile flow, the user may start signing directly without authenticating beforehand. In such cases, the signing certificate must be requested separately from the user’s ID-card before the signature can be created.
+
+When this mode is enabled in the configuration, the backend issues a separate request for the signing certificate using the `MobileSigningService`. The service communicates with the client to obtain the certificate before the signing container is prepared, ensuring that the correct certificate chain is available for the signature.
+
+This behavior is controlled by the `request-signing-cert` flag in the `application.yaml` configuration files (`application-dev.yaml`, `application-prod.yaml`). When the flag is set to **false**, the application explicitly requests the signing certificate during the signing process, demonstrating the separate signing certificate retrieval flow. When set to **true**, the signing uses the signing certificate that was already obtained during authentication, and no additional request is made.
+
## HTTPS support
There are two ways of adding HTTPS support to a Spring Boot application:
@@ -216,9 +232,9 @@ Tomcat web server automatically if it detects the presence of the
server.tomcat.protocol-header=x-forwarded-proto
These settings are already enabled in the main configuration file `application.yaml`. See chapter
-[9.3.12](https://docs.spring.io/spring-boot/docs/2.2.5.RELEASE/reference/htmlsingle/#howto-use-behind-a-proxy-server)
+[Running Behind a Front-end Proxy Server](https://docs.spring.io/spring-boot/3.5/how-to/webserver.html#howto.webserver.use-behind-a-proxy-server)
and
-[9.14.3](https://docs.spring.io/spring-boot/docs/2.2.5.RELEASE/reference/htmlsingle/#howto-enable-https)
+[Enable HTTPS When Running Behind a Proxy Server](https://docs.spring.io/spring-boot/3.5/how-to/security.html#howto.security.enable-https)
in the official documentation for further details.
### How to verify that HTTPS is configured properly
@@ -229,7 +245,7 @@ Strict Transport Security (HSTS) header and the `JSESSIONID` session cookie has
## Deployment
-A Docker Compose configuration file `docker-compose.yml` is available in the root of the project for packaging the application in a Docker image so that it can be deployed with a container enginge.
+A Docker Compose configuration file `docker-compose.yml` is available in the root of the project for packaging the application in a Docker image so that it can be deployed with a container engine.
Build the Docker image with [Jib](https://github.com/GoogleContainerTools/jib) as follows:
diff --git a/example/pom.xml b/example/pom.xml
index a6bbebb6..831e8c3f 100644
--- a/example/pom.xml
+++ b/example/pom.xml
@@ -10,17 +10,17 @@
- The Web eID project enables usage of European Union electronic identity (eID) smart cards for - secure authentication and digital signing of documents on the web using public-key cryptography. -
-- Estonian, Finnish, Latvian, Lithuanian, Belgian and Croatian eID cards are supported in the first phase, - but only Estonian eID card support is currently enabled in the test application below. -
-- Please get in touch by email at help@ria.ee in case you need support with adding Web eID to your project - or want to add support for a new eID card to Web eID. -
- -The recommended way of installing Web eID is by installing - the latest Open-EID ID-software package. - In case you do not need or want to install the Open-EID package, install the latest Web eID packages in - Firefox, Chrome, Edge or Safari according to the following instructions: -
-install-web-eid.sh
- script from the console withwget -O - https:///scripts/install-web-eid.sh
- | bashTesting:
-- -
- -The privacy policy of the test service is available here. -
- -The uninstaller will remove the browser extension from all supported browsers automatically.
- -Uninstall the Web eID software either using the Ubuntu Software Center or from the console with
- sudo apt purge web-eid
To uninstall the Web eID software, do the following:
-uninstall.sh from the downloaded file to the Terminal window,Uninstall the Web eID software using Add or remove programs.
- -echo 'logging=true' > ~/.config/RIA/web-eid.conf
- defaults write \ "$HOME/Library/Containers/eu.web-eid.web-eid/Data/Library/Preferences/eu.web-eid.web-eid.plist"
- \ logging truedefaults write
- "$HOME/Library/Containers/eu.web-eid.web-eid-safari/Data/Library/Preferences/eu.web-eid.web-eid-safari.plist"
- \ logging true[HKEY_CURRENT_USER\SOFTWARE\RIA\web-eid]"logging"="true"
- + The Web eID project enables usage of European Union electronic identity (eID) smart cards for + secure authentication and digital signing of documents on the web using public-key cryptography. +
++ Estonian, Finnish, Latvian, Lithuanian, Belgian and Croatian eID cards are supported in the + first phase, but only Estonian eID card support is currently enabled in the test application + below. +
++ Please get in touch by email at help@ria.ee in case you need support with adding Web eID to your + project or want to add support for a new eID card to Web eID. +
++ The privacy policy of the test service is available + here. +
+ +~/.local/share/RIA/web-eid/web-eid.log in Linux~/Library/Containers/eu.web-eid.web-eid/Data/Library/Application\
- Support/RIA/web-eid/web-eid.log in macOS
- ~/Library/Containers/eu.web-eid.web-eid-safari/Data/Library/Application\
- Support/RIA/web-eid-safari/web-eid-safari.log of Safari in macOS
- C:/Users/<USER>/AppData/Local/RIA/web-eid/web-eid.log in Windows.
+ Usage with Web eID plugin
+
web-eid manually,
- there will be an informative message in the logs.
- - Technical overview of the solution is available in the project - system architecture document. - Overview of authentication token validation implementation in the back end is available in the - web-eid-authtoken-validation-java Java library - README. -
-- Security analysis of the solution is available - in this - document. -
-- Currently the Web eID back-end libraries are available for Java, .NET and PHP web applications. -
-- To implement authentication and digital signing with Web eID in a Java, .NET or PHP web application, - you need to -
+ The recommended way of installing Web eID is by installing + the latest Open-EID ID-software package. In case you do not need or want to install the Open-EID package, install the latest Web eID + packages in Firefox, Chrome, Edge or Safari according to the following instructions: +
+install-web-eid.sh
+ script from the console withwget -O - https:///scripts/install-web-eid.sh |
+ bash- The full source code of an example Spring Boot web application that uses Web eID for authentication - and digital signing is available - here. - The .NET/C# version of the example is available - here. - The PHP version of the example is available - here. -
+ +Testing:
++ +
+ ++ The uninstaller will remove the browser extension from all supported browsers + automatically. +
+ +
+ Uninstall the Web eID software either using the Ubuntu Software Center or from
+ the console with
+ sudo apt purge web-eid
+
To uninstall the Web eID software, do the following:
+uninstall.sh from the downloaded file to the
+ Terminal window,
+ Uninstall the Web eID software using Add or remove programs.
+echo 'logging=true' > ~/.config/RIA/web-eid.conf
+ defaults write \ "$HOME/Library/Containers/eu.web-eid.web-eid/Data/Library/Preferences/eu.web-eid.web-eid.plist"
+ \ logging truedefaults write
+ "$HOME/Library/Containers/eu.web-eid.web-eid-safari/Data/Library/Preferences/eu.web-eid.web-eid-safari.plist"
+ \ logging true[HKEY_CURRENT_USER\SOFTWARE\RIA\web-eid]"logging"="true"
+ ~/.local/share/RIA/web-eid/web-eid.log in Linux~/Library/Containers/eu.web-eid.web-eid/Data/Library/Application\
+ Support/RIA/web-eid/web-eid.log
+ in macOS
+ ~/Library/Containers/eu.web-eid.web-eid-safari/Data/Library/Application\
+ Support/RIA/web-eid-safari/web-eid-safari.log
+ of Safari in macOS
+ C:/Users/<USER>/AppData/Local/RIA/web-eid/web-eid.log
+ in Windows.
+ web-eid
+ manually, there will be an informative message in the logs.
+ + Technical overview of the solution is available in the project + system architecture document. Overview of authentication token validation implementation in the back end is + available in the web-eid-authtoken-validation-java Java library + README. +
++ Security analysis of the solution is available + in this document. +
++ Currently the Web eID back-end libraries are available for Java, .NET and PHP + web applications. +
++ To implement authentication and digital signing with Web eID in a Java, .NET or + PHP web application, you need to +
++ The full source code of an example Spring Boot web application that uses Web eID + for authentication and digital signing is available + here. The .NET/C# version of the example is available + here. The + PHP version of the example is available + here. +
++ The Web eID solution can also be used without installing the Web eID native app and browser + extension. This includes devices like mobile phones, tablets, and some Chromebooks, where the + Web eID plugin cannot currently be installed. +
++ +
+ ++ Technical overview of the solution is available in the project + system architecture document. Overview of authentication token validation implementation in the back end is + available in the web-eid-authtoken-validation-java Java library + README. +
+
+ +
+- - + +