Duende Software
ServerSideSessionCleanupHost null refernce exception #331
-
|
We recently updated our BFF and Duende.IdentityServer.AspNetIdentity/EntityFramework libraries to 7.2.3. We have noticed a periodic null reference exception in our logs: Stack: Not clear as to the cause. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
The server-side session cleanup hosted service was in the middle of processing expired sessions, and attempted to trigger a back-channel logout to inform clients and/or external identity providers that the user's session should also expire there. To perform the back-channel logout, another token is created, during which the automatic key management service detected that a new signing key should be created and announced. The code responsible for this, needs to know the current issuer domain, which is derived from the current HTTP context. And this is where the NullReferenceException came from: there is no current HTTP context during the cleanup process. |
Beta Was this translation helpful? Give feedback.
-
|
Is there anything we need to do on our end or is this a safe to ignore log statement due to timing of session cleanup, backchannel logout and new key creation? |
Beta Was this translation helpful? Give feedback.
-
|
It is safe to ignore, unless you rely on the back-channel logout to be sent for every expired session. I'm going to check with the engineering team if we can catch this behaviour, but a potential fix might take a while. |
Beta Was this translation helpful? Give feedback.
-
|
@chrisrestall thanks for reporting the issue. It would be helpful for us to know a bit more about your current IdentityServer setup. Could you please provide the following info:
|
Beta Was this translation helpful? Give feedback.
-
|
Sure:
signing keys are signed as RS256
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks @chrisrestall for these details! It turns out that the process of creating a new key that Wes was describing above only actually uses the issuer if you wrap your signing keys in an x509 certificate. Since you're not doing that, we can provide a workaround. If we optimize the signing key management code to not attempt to retrieve the issuer if it isn't needed, your configuration should stop throwing this exception. We're in the process of producing a patch with that optimization/workaround, and we'll publish that soon as version 7.3.2. You mentioned that you're on 7.2.3, so there won't be any breaking changes in this upgrade. There is still the possibility of this issue coming back if you ever did start using X509 certificates for your signing keys. We're looking at a more general solution to these kinds of problems, but that will involve some larger architectural changes that would come in a future major version. For now, my recommendation is to stick to your current config and use 7.2.3. If you do need the X509 wrapper, you could work around this by adding a health check that makes requests to the JWKS endpoint in discovery (~/.well-known/openid-configuration/jwks). As Wes was describing, this error is occurring because IdentityServer generates keys on demand. The cleanup job is running when the keys need to be rotated and there hasn't been an http request that would initiate rotation. So, simply making regular requests to the jwks endpoint might prevent that situation or at least make it even rarer - especially if your health check runs more frequently than the cleanup job. |
Beta Was this translation helpful? Give feedback.
-
|
Update: 7.3.2 is now available on NuGet. Please try upgrading to it, and let us know if you have any feedback or issues. Thanks! |
Beta Was this translation helpful? Give feedback.
Thanks @chrisrestall for these details!
It turns out that the process of creating a new key that Wes was describing above only actually uses the issuer if you wrap your signing keys in an x509 certificate. Since you're not doing that, we can provide a workaround. If we optimize the signing key management code to not attempt to retrieve the issuer if it isn't needed, your configuration should stop throwing this exception.
We're in the process of producing a patch with that optimization/workaround, and we'll publish that soon as version 7.3.2. You mentioned that you're on 7.2.3, so there won't be any breaking changes in this upgrade.
There is still the possibility of this issue coming back …