-
Notifications
You must be signed in to change notification settings - Fork 320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds Custom property to BackchannelAuthenticationResponse #1361
Adds Custom property to BackchannelAuthenticationResponse #1361
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think maybe we need to add a new custom validator abstraction, similar to what is done on the token endpoint. Then users could provide an implementation that would build up the Custom dictionary.
/// <summary> | ||
/// The response that will be sent to the client | ||
/// </summary> | ||
public BackchannelAuthenticationResponse Response { get; set; } = default!; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gislikonrad, do you really need the full response object? Why not pass just the Custom dictionary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Passing just the Custom dictionary would be sufficient.
@@ -111,6 +111,7 @@ public virtual async Task<BackchannelAuthenticationResponse> ProcessAsync(Backch | |||
AuthenticationContextReferenceClasses = validationResult.ValidatedRequest.AuthenticationContextReferenceClasses, | |||
Tenant = validationResult.ValidatedRequest.Tenant, | |||
IdP = validationResult.ValidatedRequest.IdP, | |||
Response = response |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we sending the response to the user login service? If we want to return custom values in the response from the CIBA endpoint, that should be passed above (line 101).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the custom dictionary would just be added on line 101, then the user login service couldn't add anything to the response, i.e a code that should be shown on a page and entered in the backchannel client.
A custom validator abstraction would also work. Also, if a custom validator abstraction would be added, it might be a good place to allow validation of the raw request, if there are also custom incoming parameters. |
Closing in favor of new PR 1497 (this branch was rebased, and the custom validator was added). |
The problem
We have an authenticator app that is similar to other authenticator apps where when out-of-band authentication is invoked, a code is displayed in the invoking client that needs to be verified in the authenticator app. We need a way to send the client this verification code during CIBA authentication.
The spec
According to section 3 in the CIBA spec it allows for some extensibility - profiles can be created that define additional parameters to be sent to, and received from, the Backchannel Authentication Endpoint.
The proposed solution
What I did was to add the preliminary
BackchannelAuthenticationResponse
to theBackchannelUserLoginRequest
so that it can be mutated in theIBackchannelAuthenticationUserNotificationService
. A new dictionary property was added to theBackchannelAuthenticationResponse
which is similar to the one inTokenResponse
. This dictionary is then added to the DTO as JsonExtensionData to be serialized.More
I considered adding the raw request to the
BackchannelUserLoginRequest
aswell, to be able to respond to extra request parameters, but I might add that to a separate PR.What issue does this PR address?
There is no issue reported for this, but I felt that explaining my issue would be easier in code. We are running v6.2.3 of Duende.IdentityServer.An issue was created for this feature request.
Important: Any code or remarks in your Pull Request are under the following terms:
If You provide us with any comments, bug reports, feedback, enhancements, or modifications proposed or suggested by You for the Software, such Feedback is provided on a non-confidential basis (notwithstanding any notice to the contrary You may include in any accompanying communication), and Licensor shall have the right to use such Feedback at its discretion, including, but not limited to the incorporation of such suggested changes into the Software. You hereby grant Licensor a perpetual, irrevocable, transferable, sublicensable, nonexclusive license under all rights necessary to incorporate and use your Feedback for any purpose, including to make and sell any products and services.
(see our license, section 7)