orchestrator
2020.10
false
- Getting Started
- Requirements
- Best Practices
- Installation
- Updating
- Identity Server
- High Availability Add-on
Prerequisites for Installation
OUT OF SUPPORT
Orchestrator Installation Guide
Last updated Dec 12, 2023
Prerequisites for Installation
Apart from the prerequisites listed here for Orchestrator installation, Identity Server needs the following:
Identity Server requires 2 valid certificates:
- A certificate for the HTTPS protocol.
-
A certificate used to sign the tokens generated by the Identity Server.
Important:For security reasons, the certificate used by the Identity Server needs to:
- have a public key on 2048 bits
- have a private key accessible by the AppPool user,
- be in its validity period (not expired).
The certificate's location is set in Identity Server's configuration fileappsettings.Production.json
, in the Signing Credential section.Note: The certificate is used for signing OpenID access tokens that are used for user identification via browser and for service-to-service communication between Orchestrator and Identity Server. Click here for more details about OpenID Connect.
You can employ certificate rotation to avoid the risk of certificate expiration and, implicitly, an Identity Server outage. This method entails maintaining two certificates and rotating them periodically. Note, however, that you can only use one signing key at a time.
To initiate the certificate rotation process, take the following steps:
- Specify the initial certificate's
Name
,Location
, andNameType
using theSigningCredential
parameter inappsettings.Production.json
’s SigningCredential section. Note that the first signing key you register is the default. - Specify the second certificate's
Name
,Location
, andNameType
using theValidationKeys
parameter in the same section of theappsettings.Production.json
file. Make sure you complete this step before the rotation date. - At this stage, the second certificate is published using the
identity/.well-known/openid-configuration/jwks
endpoint. This ensures everyone has enough time to update their cached discovery document. - At rotation time, switch the certificates and restart Identity Server. The new certificate can now be used for signing whereas the previous one continues to be available for validation purposes for as long as you need.
- The previous certificate can be safely removed from the configuration after 48 hours.
In the following example,
SigningCredential
references the currently used certificate whereas ValidationKeys
references the newly published validation key.
"SigningCredentialSettings": {
"StoreLocation": {
"SigningCredential": {
"Name": "2816a67bc34496ca0acabbe04eb149b88ade0684",
"Location": "LocalMachine",
"NameType" : "Thumbprint"
},
"ValidationKeys": [
{
"Name": "2cde6c443f0147c6258a6fe2203e71a997bfcd44",
"Location": "LocalMachine",
"NameType" : "Thumbprint"
}
]
}
}
"SigningCredentialSettings": {
"StoreLocation": {
"SigningCredential": {
"Name": "2816a67bc34496ca0acabbe04eb149b88ade0684",
"Location": "LocalMachine",
"NameType" : "Thumbprint"
},
"ValidationKeys": [
{
"Name": "2cde6c443f0147c6258a6fe2203e71a997bfcd44",
"Location": "LocalMachine",
"NameType" : "Thumbprint"
}
]
}
}
Important: If you are using AI Center, make sure to redeploy it whenever updating the Identity Server certificate.