We have a custom WebDAV solution using the IT Hit WebDAV server component. For authentication we are using an Identity Server 4 implementation. The authentication flow, from the user's perspective, is roughly as follows:
Users clicks the link to the WebDAV document in the application.
Office (in most of our test cases, Word) is opened.
If this is the first time the user has opened a document (or the cookie has expired) a login dialogue is shown.
The user enters their username and password, hits the login button and if successful the document is opened.
Behind the scenes the flow is similar to the following:
A HEAD request is made to the parent folder of the document e.g. https://webdav.example.com/documents/
The response to this request contains the headers necessary for Office to show the login dialogue. X-FORMS_BASED_AUTH_REQUIRED etc.
Office follows the URL from the value of the X-FORMS_BASED_AUTH_REQUIRED header. e.g. https://identityserver.example.com/connect/authorize?client_id=WebDAV&response_type=code+id_token+token...
This returns a 302 response with a location similar to: https://identityserver.example.com/account/login?returnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3DWebDAV%26response_type%3Dcode%2520id_token%2520token...
Office opens this URL in the dialogue. Once the user enters their credentials and hits login a POST request is made to the login form, this returns a 302 with the location of the Identity Server callback URL e.g. https://identityserver.example.com/connect/authorize/callback?client_id=WebDAV&response_type=code%20id_token%20token...
A GET request is made to this URL which then POSTs the Identity Server info (tokens) to the configured client callback URL e.g. https://webdav.example.com/account/callback.
This is a custom endpoint that stores the Identity Server access token in a cookie (so that Office can use the cookie) and then responds with a 302 with the location of https://webdav.example.com/account/success. This URL is the same one configured in X-FORMS_BASED_AUTH_RETURN_URL header.
Ona Windows client this all works fine. However on a Mac (Mac OS Sierra 10.12.6) and using Office 2016 (16.11.1 (180319)) we see that the 302 response is returned from the https://webdav.example.com/account/callback URL but it's never followed, there's no GET request made to https://webdav.example.com/account/success.
In addition, there are further WebDAV requests made and stepping through the code we can see that the cookie never seems to be set on the Mac despite the code to do that being executed without error.
So, what's going on?
Thanks,
Stuart.
Related
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
It's so strange that this simple solution is not yet implemented or is it that I can't Google it ;p) (I'm trying from last 5 days).
My requirements:
Call from Angular App (withCredentials = true) on a URL to see if it is windows user (challenge NTLM). (I may configure this based on what URL user accessing it). If it's a valid Windows user and I find them in DB, I return the Bearer Token.
If Above call returns Unauthorised (401), I show login form to user in my AngularJS (1.6) client. User provides non-windows username and password and when user click Login, from angular service go to another URL (for getting Bearer Token - standard OWIN stuff).
** In any case above, I store Bearer Token in my client for any further API interaction.
I'm not using ASP.NET identity but I have my own DAL to verify user from DB.
I'm going to have my own custom Authorise (inherited) attribute (which will check for Bearer Token only).
I don't want users to enter Windows login on my form and to authenticate them from Active Directory.
I Don't want windows users to click on any separate button to login. (They should just login seamless - with prompt from browser asking them windows login)
I've seen hundreds of posts but nowhere I could see exactly what need. Either the mixed authentication needs to be Cookie based or separate MVC implementation. (Lot's of confusion)
Already referred:
https://techblog.dorogin.com/mixed-windows-forms-authentication-for-ajax-single-page-application-e4aaaac0424a
https://techblog.dorogin.com/mixed-windows-forms-authentication-for-ajax-single-page-application-e4aaaac0424a
https://github.com/MohammadYounes/OWIN-MixedAuth
Don't know if this may help: (but again with cookie) https://github.com/pysco68/Pysco68.Owin.Authentication.Ntlm
Can someone please help?
I may have to give up on this by tomorrow evening :-(
I've a group of employees whom use Outlook Web Access exclusively, and they are complaining that mailto: links on our intranet don't work for them because they don't open OWA (I can't change the settings on the individual machines, fyi).
I'm looking for some kind of way to have an intermediary page that I'll redirect them too when they click a mailto: link, which checks for an OWA login, and if it's found, will redirect the user to OWA. If no login is found, it will open a standard mailto: command.
MY PROBLEM: I can't seem to find a way to detect if they are logged into OWA. I can't use normal AJAX or Iframes because those elements are not allowed to inspect the contents of a page loaded from a different domain (our intranet is NOT on the same domain as OWA).
I even tried hitting the OWA url in code (C#) using the WebRequest class of System.Net, but I get a 400 error there for some reason.
I tried AJAX, IFrames and WebRequest against both the base URL of the OWA system, as well as the URL that you are redirected to for a login. All fail as described above.
Does anyone have a way of detecting an OWA login? I don't need to 'scrape' anything from a page in OWA, I just need a yes/no answer for if they are logged in or not.
Can you make a jsonp ajax request and just look at the 302 redirect url?
If you get redirected to owa/auth/logon.aspx, you are not logged in.
Using jsonp will let you work around cross domain security limitations.
We have a SharePoint 2007 site which has FBA configured (extended the webapp to different zone). The problem is that a user has to authenticate twice when the URL changes from http://site to http://www.site i.e if the user enters http://site it asks for username and after authenticating if the user clicks on a url containg http://www.site it authenticates again.
Our host header has both enteries for http and http://www.
Can anyone help me fix this issue (why is SharePoint treating http:// and http://www differently).
I don't think this is a SharePoint problem. The reason this is occuring is the FBA auth cookie is being set for http://site as the domain, so when the user navigates to http://www.site, the cookie isn't getting passed back to the server, and the user is being seen as unauthenticated.
I don't think there is a way to set the cookie for both sites without writing some code (if its even possible).
I have a website that I would like to allow both Forms and Windows Auth for. My problem is that it seems that when you setup IIS to allow both anonymous (Required for forms auth) and Windows auth that the browser won't send the user's network credentials.
It just uses the anonymous login. Is there any way either in IE8 or IIS to have it try Windows Auth 1st and then fall back to Anonymous?
Thanks for any help.
You can't ask for HTTP authentication (whether that's Basic Authentication or Integrated Windows Authentication) without causing the authentication dialogue box to pop in the case where there are no credentials yet.
So in general for hybrid HTTP-auth+cookie-auth approaches you enable both anonymous and authenticated access for the bulk of the site, but allow only authenticated access to one particular script.
When the user accesses a page without either kind of auth, you spit out a page with a login form for the cookie-based auth, and also a link to the one URL that allows only authenticated access. The user can fill out the form for cookies&forms auth, or hit the link to log in with HTTP auth instead.
If the user follows that link, they will be given a 401 response and must provide HTTP authentication, either through the auth dialog, or potentially automatically using integrated Windows authentication. Once this has happened once, the browser will start submitting the same credentials to every future page, so IIS will decode the credentials to give you the expected REMOTE_USER when your main site scripts are run.
Browsers will only submit the credentials to pages in the same directory as the 401 script, or subdirectories of this. For this reason it is best to put the HTTP-auth-required script in the root, for example as /login.aspx.
However, there are a few browsers that won't automatically submit credentials for further pages, and require every HTTP request to respond 401 first, before sending the request again with credentials. This makes optional-auth and hybrid-auth schemes impossible (as well as making browsing of protected sites much slower!). The only modern browser that does this is Safari. You may not care, as Safari's support for Integrated Windows Authentication has traditionally been shaky anyway, and it can still use the forms+cookies auth type.