brockallen
commented
8 years ago To improve discoverability of frequently asked and/or more general questions, we decided to move those questions to StackOverflow:
https://stackoverflow.com/questions/tagged/?tagnames=identityserver3&sort=newest
We actively monitor SO as well but hope to create a community there so questions can get answered faster when we are not available.
Question / Issue
Hi,
I have been using Identity Server since the early days of the second generation - this is an excellent project and keeps getting better. It has certainly done a great deal for pulling enterprise security out from the middle ages, I cannot thank for it enough.
I'm currently working on a product that used forms cookie authentication before. Migrating to Id Srv has been going smoothly in most regards, but there is one aspect that remains a challenge: the option to log in while in the middle of an input flow, e.g.: Step 1: input some form fields. Step 2: choose between 'new user' and the form required to register and 'existing user' and the form to type in credentials. Step 3, 4, ...: pre-fill some fields based on user information acquired in step 2 and continue taking input. Step N: Save.
These input flows are implemented as part of an SPA and the UX is polished for this. While I think that we should redesign these and use Implicit/Hybrid flows properly, this is not an option short term (time constraints and requirement battles to be had).
I prototyped two approaches to get it work short term: Approach 1: Implementation of an IViewService that supports display modes and serves a simplified login view to be used in an iframe + an Owin middleware to alter the SAMEORIGIN XFO header to allow the website using it as origin. It doesn't work consistently across all browsers (fine in FF, stops in Chrome at form post, doesn't even start in IE - I guess this could be resolved with trial and error as there are not many clues to start with).
Approach 2: Setup of second client for Resource Owner flow; this is then called form the server side to acquire the access token for the credentials posted in by the original login form. Since the frontend is an SPA, it needs to refresh the access token periodically with an Implicit flow using an iframe. To get this part to work, I had to modify the Core so that it allows CORS calls to a new action on the AuthenticationController: TokenLogin - it takes the access token form the authorization header, validates that (same as UserInfo endpoint) and clears/issues cookies if valid (same as Login action's preauthenticated branch).
One of the major issues with Approach 2 is that I had to extend the Core, diverging from the repo. It couldn't be avoided, because the CorsPolicyProvider registered by UseIdentityServer seem to make WebApi generally disallow CORS calls to any routes not listed in the CorsPaths. Additionally, extending AuthenticationController allowed access to the services that an external controller cannot otherwise have injected (e.g. TokenValidator and BearerTokenUsageValidator.
Do you see a vulnerability with any of these approaches that would make them a no-no? Any better approaches that I didn't think of? Do I miss something with CorsPolicyProvider and how I think that it actually blocks CORS access to any WebApi routes not listed in CorsPaths?
Sorry for the long summary. All opinions are welcome.
Thanks!