You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
If I've understood it correctly, when redirecting to an external social/source/fed. provider, all policies along the way are run before the provider is selected, or after the user has been authenticated. There are some features in OIDC that would require those types of policies, for example customizing the the prompt parameter (#9971), modifying the redirect URL on the fly or adjusting scopes based on various parameters
Describe the solution you'd like
There are some possible solutions:
Introduce a "post-policy" (via setting)
Since the current policies are largely run as pre-policies (before the flow step), introducing the option to add policies pre (same as today)- or post (after execution, pre-redirect in the case of the identification flow with external redirect)-step. This one is a little more general, and would introduce a number of new possibilities
Introduce scope mapping for authorization requests
The ability to add expression-based scope mappings for authorization requests would also work for this
Describe alternatives you've considered
Writing a full custom policy for the entire OIDC auth processm but that would likely be a pain to maintain in the long run
Additional context
This is tangentially related to #12512 as well, and could resolve it by customizing the auth request to include details about the invitation being used, source flow, etc.
Edit: formatting
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
If I've understood it correctly, when redirecting to an external social/source/fed. provider, all policies along the way are run before the provider is selected, or after the user has been authenticated. There are some features in OIDC that would require those types of policies, for example customizing the the prompt parameter (#9971), modifying the redirect URL on the fly or adjusting scopes based on various parameters
Describe the solution you'd like
There are some possible solutions:
Introduce a "post-policy" (via setting)
Introduce scope mapping for authorization requests
Describe alternatives you've considered
Writing a full custom policy for the entire OIDC auth processm but that would likely be a pain to maintain in the long run
Additional context
This is tangentially related to #12512 as well, and could resolve it by customizing the auth request to include details about the invitation being used, source flow, etc.
Edit: formatting
The text was updated successfully, but these errors were encountered: