(2 votes, average: 5.00 out of 5)
To prevent unauthorized access to federated resources, federation servers will enforce the use of token-signing certificates, effectively thwarting cybercriminals from tampering with or forging security tokens. The most crucial validation technique for any federated collaboration is the private/public key pairing utilized with token-signing certificates. These encryption keys verify that a security token was generated by an authorized/legitimate partner federation server and that it was not altered in transmission.
Token signing is a procedure that requires getting a private signing key and using it to verify the identity of a single person or group of people who use tokens to access a system or service. To make sure that the digital signature on a code file is authorized and approved by a trustworthy certificate authority, this approach is frequently used in Code Signing Certificates.
Token-signing certificates are needed by federation servers in Active Directory Federation Services (AD FS) to stop attackers from modifying or forging security tokens to obtain unauthorized access to federated resources. Every token-signing certificate has public and private cryptographic keys used to digitally sign a security token (using the private key). The authenticity of the encrypted security token is later verified (using the public key) by a partner federation server after receiving these keys.
In this regard, FIPS 140-2 tokens can be used for token signing, as they contain the required cryptographic modules for handling digital signatures. Since the signed documents are handled in a licensed and secure environment, this guarantees that they are safe and tamper-proof. As they cooperate in providing a safe digital signature method for sensitive and confidential documents, FIPS 140-2 tokens and token signing are consequently connected.
Note: The stability of the Federation Service depends on the certificates used for token signing. You must back up any certificates specified for this purpose since their loss or unintended removal might cause service disruptions.
To be compatible with AD FS, a token-signing certificate must fulfill the following conditions:
Important note: The recommended practice for PKI (public key infrastructure) is not to use the same private key for multiple assignments. Because of this, avoid employing the service communication certificate you deployed on the federation server as the token-signing certificate.
Token signing certificates are standard X509 certificates utilized to protectively and securely sign all tokens issued by the federation server. Moreover, any incoming tokens are decrypted using token decryption certificates, which are standard X509 certificates. They are additionally published in federation metadata.
The certificate must be obtained and installed in the local computer personal certificate store on the first federation server that is deployed in a new AD FS installation. You can create a self-signed certificate or look for a certificate from an enterprise CA or even a public CA like Certera, Comodo, or Sectigo.
Each federation server in a farm shares a private key from a single token-signing certificate.
A YubiKey is a hardware authentication device. It can be used for two-factor authentication, digital signatures, and password management. For Code Signing, a YubiKey can store the private key of a code signing certificate, allowing it to sign code and software releases physically.
This provides a higher level of security than storing the private key on a device connected to the internet. The YubiKey never exposes the private key externally – it performs the signing process internally and returns only the digital signature. Even if the computer the YubiKey is connected to is compromised, the private key remains secure within the YubiKey.