Menu
Due to the nature of our application we can have users coming in via a wide number of auth providers, several of them using OAuth 1.0 (specifically, LTI). Rather than always creating a new user account whenever we don't recognize a login and then having to deal with complex identity merges later, we want to invite apparently new users to identify themselves via OpenID (Google and Microsoft primarily since that covers most of our users.) We could ask them for their U/P, except we don't do U/P - we have always preferred to only support login via 3rd party identity providers and don't really want to change that.
So the scenario would be that our custom authentication scheme (LTI/OAuth1.0) receives the 3rd party claims, determines that these claims are new to our system, and then forwards a challenge to our default auth scheme. Upon completion of that scheme (either successful auth or the user declining (i.e. NoResult)) we would ideally return to the original scheme to complete either creating a new user using the provided claims or adding an additional login to the existing user. Once all of that was complete, the final AuthenticationTicket would be returned and the request would proceed normally as authenticated.
I may be thinking about this all wrong, and if so I would be glad to be guided in a better direction. But the basic business requirement is that I don't want to create a new user prior to giving incoming individuals the opportunity to identify themselves as existing users via another login method.
Target environment is ASP.NET Core 2.0 or 2.1.
248
Authentication is the process of determining a user's identity. Authorization is the process of determining whether a user has access to a resource. In ASP.NET Core, authentication is handled by the authentication service, IAuthenticationService, which is used by authentication middleware.
ASP.NET allows four types of authentications: Windows Authentication. Forms Authentication. Passport Authentication.
Authorization in ASP.NET Core is controlled with AuthorizeAttribute and its various parameters. In its most basic form, applying the [Authorize] attribute to a controller, action, or Razor Page, limits access to that component to authenticated users. Now only authenticated users can access the Logout function.
The Default Policy is the policy that gets evaluated when authorization is required, but no explicit policy is specified. In other words, it's the policy that evaluates when you add an [Authorize] attribute without any PolicyName. Out of the box, the Default Policy is set to requiring Authenticated Users.
The ASP.NET Core file -> new project template (when you pick 3rd party auth) does something similar when you choose to login from a 3rd party provider. It stores the 3rd party claims in a cookie (signed) and hands you to the registration page. Once you submit the form, it grabs the claims from this cookie together with the registration details, creates the user in the database, nukes this temporary cookie, and issues the real auth cookie that everything else looks to. To mitigate replay attacks, this intermediate cookie is only a session cookie and expires after a short time -- 5 minutes, I think. You're definitely on the right track.
51
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
