The Yubico java-webauthn-server library has the notion of a RelyingParty
class. This class will help support the registration and authentication ceremonies by providing configurations such as the relying party ID, allowed origins, and much more. Below we are going to provide a walkthrough of a standard configuration, and some additional options that you can include based on your applications requirements.
Let’s start with declaring a RelyingParty
object
Figure 7 demonstrates sample code to initialize a RelyingParty
object.
RelyingPartyIdentity rpID = RelyingPartyIdentity.builder()
.id("passkey.app.com")
.name("Passkey App")
.build()
Set<Strings> allowedOrigins = new HashSet<String>;
allowedOrigins.add("https://passkey.app.com");
private final RelyingParty rp = RelyingParty.builder()
.identity(rpID)
.credentialRepository(this.userStorage)
.origins(allowedOrigins)
.attestationConveyancePreference(Optional.of(AttestationConveyancePreference.DIRECT))
.allowUntrustedAttestation(true)
.validateSignatureCounter(true)
.build();
The first step is to declare an ID that will be used by the relying party. This ID is used to bind credentials to a specific domain and origin, belonging to your application. This means that the credential can only be utilized within the context of the application that it was created on.
This ID will be used in the authentication and registration requests sent by the relying party under the form of an rpID. In Figure 7, the ID is declared by providing an ID that correlates to the origin of your application, along with a descriptive name of the application.
Next we will declare the credential repository to be used by the relying party. This is going to refer to the credential repository that we declared in Figure 2.
Next we will list the origins that are allowed to register with this application. This essentially means that the credential needs to have been created on one of the origins in this list.
The next two options refer to attestation. We will cover this concept in further detail later in this guide. For now what you need to understand is that during registration, a credential can include information that can be used to identify the make and model of the authenticator that it was created on.
The settings that we provide above will allow an authenticator to send attestation data, and will still allowing registrations to be completed if attestation is not provided.
Lastly we note to the relying party that we want to check the signature counter during authentication. This will help to prevent replay attacks, or mitigate risks in the case that a private key is compromised.
Now that we have initialized our application, let’s go over how to create a method to invoke and process registration requests.