- Use IdSrv3 as an OAuth 2.0 Authorization Server only.
- Use legacy authentication pages and session management mechanism.
- No Federation Gateway functionality is required.
- The IdSrv3 built in page should never be rendered to the user.
- Create a
IUserService
implementation with the following behavior on thePreAuthenticateAsync
method.- If the user is already authenticated using the legacy mechanism, assign the
PreAuthenticationContext
with anAuthenticationResult
containing aClaimsPrincipal
built from that legacy authentication (non partial sign-in). As a consequence, IdSrv3 will establish its own session and redirect back to the Authorization Endpoint to complete the authorization request. - If there isn't any authenticated user, assign the
PreAuthenticationContext
with a partial login pointing to a new page that will act as a bridge between IdSrv3 and the system's legacy login page. As a consequence, IdSrv3 will redirect to this bridge page.- The bridge page should redirect to the legacy login page (the return URL will be the bridge page).
- On return (after the user is authenticated on the existent page), the bridge page should use IdSrv3 extensions methods to resume the authorization request flow.
- If the user is already authenticated using the legacy mechanism, assign the
- Make sure that any changes to the legacy session (e.g. legacy logout) invalidate the IdSrv3 session. This may require changes to the legacy logout page.
- Is any better way to do this, perhaps with some PostXxxx hook?
The legacy page lives in the same web app as the IdSrv (is that what you mean by "same pipeline"?) I just want to minimize changes to the login page. The interface between this page and IdSrv is done by the "bridge" page. The login page is not aware of IdSrv3, the bridge page is.