Add custom properties to CIBA response
gislikonrad opened this issue · comments
Which version of Duende IdentityServer are you using?
6.2.3
Which version of .NET are you using?
.net6.0
Describe the bug feature request
We need a way to add custom properties to the /connect/ciba response.
Additional context
We are using CIBA and have multiple acr values that are supported. One of the acr values describes a 3rd party authenticator app where you have to first verify a number on the authenticator device that is shown to you in the requesting client.
According to the CIBA spec, there is room for extensibility in the request and response properties. We would want a way to add custom properties to the /connect/ciba response.
We have a pending PR that implements this in a way that is similar to the custom response properties on the /connect/token response.
Thanks for the PR @gislikonrad. We'll give this some consideration and follow up here soon.
Any news on this?
@josephdecock ping -- we did this in 7.0, right?
Yes, I've linked the associated PR and updated the milestone.
@gislikonrad, please check out our release candidate for v7 that we just published yesterday. In addition to this ciba extensibility point, it includes support for .NET 8, better observability with OpenTelemetry metrics, support for the Pushed Authorization Requests specification which offers enhanced security, and lots of other bug fixes and enhancements.
We'd really appreciate any feedback, especially in the next couple of weeks before we make the GA release!
So I looked over it and, for the most part, it looks good and usable. However, there is one thing that I didn't notice in the pull request that I find a bit odd.
The Properties dictionary was added to the ValidatedBackchannelAuthenticationRequest, which is all well and good. This Properties dictionary can be accessed in the ICustomBackchannelAuthenticationRequestValidator where you can add properties for use in subsequent parts of the request. The thing I find odd is that this Properties dictionary that is being used in the request is added directly to the BackchannelAuthenticationResponse and BackchannelAythenticationResult and uses it as extension data. Does that mean that the implementation of IBackchannelAuthenticationUserNotificationService should sanitize the dictionary so that it's safe for the response?
In my opinion, there should be a separate Custom dictionary, like in the TokenResponse that is used to extend the response.
Here's a few relative links
I'll reopen this until we have a resolution to the feedback.
My intent is that the custom validator should look for extension parameters that you want to add support for, validate and sanitize that input, and add good values to the Properties dictionary of validated request.
The way I've been thinking about it is that the validator adds valid custom values to the properties and then those valid properties propagate to the rest of the pipeline. In particular, there would be no need to do validation in the notification service, because the properties that are sent to the notification service were validated in the custom validator.
I think it is reasonable to pass the validated custom properties along to the notification service because ultimately it gets to decide what to do with that data, and I also think it makes sense to persist those properties when we create the record in the store because they might be needed later.
However, in the response generator, we are echoing back the valid extension parameters, and that probably isn't useful. If you need custom response parameters, the way to do it is to extend the BackchannelAuthenticationResponseGenerator, override the ProcessAsync method, call the base, and then manipulate the custom properties of the result before returning. As things exist now, after you call the base method you will have the echoed input parameters in the output parameters by default, and you'd have to clear them out if you didn't want them. You'd also be sort of forced to implement that generator if you have custom request parameters that you didn't want in the response, even if you didn't need any custom response parameters. So I think the thing to do is to change the default response generator so that it doesn't copy custom request properties into response properties.
So I think the thing to do is to change the default response generator so that it doesn't copy custom request properties into response properties.
Would this behavior make more sense to you @gislikonrad?
That behavior would make a lot more sense. I'm wondering if the name on the response should then be changed to Custom from Properties so that it follows the same pattern as the TokenResponse object.
That behavior would make a lot more sense. I'm wondering if the name on the response should then be changed to Custom from Properties so that it follows the same pattern as the TokenResponse object.
We were just discussing this exact idea earlier this morning :)
@gislikonrad we just merged these updates and a second release candidate is in the pipeline. Please give it a look and let us know what you think.
Also, we released a 7.0.0-rc.2 that includes these changes.
I just tried out 7.0.0-rc.2. Works as expected. Very nice, thanks.
Thanks for the feedback!