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).
Related
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.
I have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.
I've got an internal web app for my company that uses a login with google authentication system. It's working well for the most part, they can authenticate with google, give consent for my app to access basic user details, and then when they are returned to my app, I can indeed get their user details.
The issue is that I thought once they give consent they wouldn't have to do it each time. Is this an incorrect assumption? As it is now, each time they click the "login with google" they must give consent rather than being redirected back to my app.
I'm using PHP (codeigniter) and a pretty good Oauth lib found on github (fork of phil sturgeon's library). Is there some param I should be passing so the user doesn't have to give consent every time, after the first time?
Google login does not require user consent every time. If you're using OAuth2 Login procedure, you should be able to login a second time w/o re-approvals: https://developers.google.com/accounts/docs/OAuth2Login
In some contexts, however, it is possible for auto-approval to become disabled, with the subsequent requirement of user consent on every login.
The first and most common case is if your application explicitly requests Google to prompt for consent everytime. Check if your authorization request (which you may have copied from an example or sample code) includes 'prompt=consent' or the older, non-standard form 'approval_prompt=force'. Removing these parameters (if present), will likely cause auto-approval to start working.
Another situation is if your redirect URL is based on 'localhost' or some other URL that does not belong to the global DNS namespace. In this case, for security reasons, Google sets a cookie on the user's computer, in the accounts.google.com domain, to signal that the user authorized _this_device_ to login to 'foo' on localhost (or local domain); Google will only auto-approve w/o consent a 2nd request if it finds the cookie. The reason is that the meaning of 'localhost' (or local domain, or other URL not built on global DNS namespace) is device-dependent, and allowing the authorization to apply across devices could introduce security risks. So if your company has configured browsers to clear all cookies on exit, and you use a non-absolute URL, you could see your users having to consent everytime. The solution is either to host your endpoint on an Internet-valid hostname (the host doesn't need to be accessible from outside the Intranet, just the hostname needs to be globally valid), or you need to exempt accounts.google.com from the cookie clearing policy.
Updated with clarifications
Hello,
When our users go to http://mysubdomain.server.com/login they get redirected to https://secure.server.com/login?subdomain=mysubdomain. So the actual login page is located on the secure.server.com subdomain.
The problem is that if the user logs in with the credentials meant for subdomainA and tells Firefox to remember the password, the browser will autocomplete the login form even if the user visits the login page meaning to log into subdomainB.
Firefox assumes that the login form on secure.server.com/login?subdomain=subdomainA is the same with the one on secure.server.com/login?subdomain=subdomainB.
At first, I thought Firefox remembers passwords based on a combination of the URL and the name attribute of the form, but I've tried changing the name based on the subdomain (name="login-<subdomain_name>"), and it still doesn't work.
How can I make Firefox remember passwords for subdomainA and for subdomainB separately, and not together?
I couldn't quite decipher what your setup is, but you can enable login manager debugging and check what Firefox does. You can also inspect signons.sqlite in your profile to see what pieces of data are stored with the login.
I thought that for web forms it keyed off the form's submit URL, but my memory is shady on this.
[edit]
source (nsLoginManager.js) says it only uses the form's action and the page's URL, and it uses not the action/page URL itself, but (see _getPasswordOrigin) the scheme+host+port combination.
If they're actually entering data into http just to be redirected to https after login, isn't that a bad scenario? You're already sending the most sensitive piece of data unencrypted across the wire.
I believe a better solution would be to redirect them to the https site and do login there...is there something I'm missing with your setup? Do they login again on the secure site?
AFAIK domain name (complete) is the current basis for remembering login. It wasn't always so, though. I'm not sure about protocol or port number, but a.domain.com is different from b.domain.com and domain.com, but same as a.domain.com/somewhere.
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.