We have a program that runs in IIS with Windows authentication, and which is available to the outside world.
Right now, we provide to every interested party a link to the program, along with guest credentials they then have to type.
Is there a possibility to do away with the credentials? Our internal people should be able to login as usual, but we want to provide a link to get into the guest account without typing any login credentials.
I have tried to add the credentials into the clickable url, but Internet Explorer and Edge browser do not support this, and Mobile Safari throws phishing warnings.
Can this be done universally, that the authentication is done invisibly in the background in all browsers, using some kind of redirect or XHR call with arguments or something like that?
Related
I'm working on an Electron app connected to a backend on AWS that handles the verification and creation of the user. If it matters I'm building the app with React.
Basically the backend flow is:
Navigates to backend.com/oauth/login
Backend prepares OAuth config, redirects to the Discord.com authentication url
User authenticates, redirects to backend.com/oauth/callback with the neccessary information to validate the authentication and create a user
I've got this part working. But if I would open backend.com/oauth/login in a separate browser window, how would I know the authentication was successful?
Are there some events I could listen to in the authentication window I've opened? Maybe let the callback redirect to backend.com/login/successful if the authentication was completed or otherwise backend.com/login/failed. This feels like such a hack but I'm way out of my expertise here.
Three ways to do it:
Once the authentication is successful, you redirect the user's browser to your backend where you load the authentication data in the user state. Your React/Electron app is also connected to this backend. You must be able to match those two connections
Once the authentication is successful, you redirect the user's browser to a custom URL protocol which is registered in the OS to open your Electron app
Once the authentication is successful, you redirect the user's browser to a port on your running Electron app
Most good Electron applications use number 2 - but it requires that your application knows how to register an URL handler on every OS it can potentially run. Number 1 is good if you can safely match the two connections. It requires passing some form of identification. Number 3 is a hack.
I am working on some browser tests in selenium on Chrome. I have a script which ran on my personal machine can connect to a site and has no issues. However when the script is ran on a machine inside our network, it pops an authentication pop up. When I click cancel on the authentication box, it continues to a user login page which allows regular authentication. I have disabled IWA for the browser but it is still popping up.
I tried passing username#password:url but that did not work. Our test account is not connected to the domain and this website will try to use your Windows account but outside the network it defaults to the login page where we do have regular userid/pw for certain people (like our test account they created for us). We do not control the server so I cannot change that behavior.
I would normally close the alert in this case however selenium is not recognizing the authentication popup as an alert so the script just hangs. So step 2 would be the userid/password sent in the URL but that doesn't work either. I would prefer not to go the route of installing any other tools (like AutoIt) and try to solve this with settings.
Is there a way to skip the authentication popup in chrome? In the header the response is its using "Negotiate" for auth. I do not get that when testing on my local machine outside the network.
I'm trying to develop a rally app using the app builder. When I load App-debug.html in my browser, I am prompted to enter my user credentials in the form provided. I enter them, but the form re-appears over and over again.
I did notice that the login attempts to authenticate via https://rally1.rallydev.com:443. If I go to this in another window and enter my account details I am able to get in. However, when I do log in, there is a corporate redirect that takes place (for SSO) and I ultimately end up on us1.rallydev.com.
How would I get my app to authenticate through us1.rallydev.com. Changing urls in App.js and config.json only causes errors when trying to load javascript for APIs.
The app should always just piggyback on your existing session. Changing the serverin config.json and re-running rab build should cause all traffic to go to that server- if that's not happening then that's a bug.
You won't be able to authenticate from scratch using SSO from an app, but it should have no problem re-using an existing session.
Another option is to use an API Key to develop: https://help.rallydev.com/apps/2.0/doc/#!/guide/embedding_apps
I've implemented a simple OAuth2 for Authentication login system that is working reliably on my dev server using a localhost redirect uri.
When testing from a production server, with updated redirect uri, the Google account permission interface opens up for the user logging in. After authorizing account access, the browser just hangs on "Waiting for accounts.google.com..." and doesn't go anywhere. At this point, I can see that the application has been granted access to my profile by viewing account permissions on my Google account dashboard.
If I change the redirect uri to an invalid one, I do get the invalid redirect uri Google error message back, so it looks like the redirection cannot reach my redirect uri. I can reach the reditect uri directly through a browser though. Any pointers?
Had a similar problem trying to create a "Login with Google" App. Since this was my first Google App, and I was also just first using the social networking setups in the software package which I bought BEFORE the Google API had changed, I was at a complete loss as where to start.
It finally dawned on me to redirect Google (via the App settings in the developer console) to a test web page on my site (instead of the page defined by the software package,) and all worked as expected, meaning Google redirected properly to the test page (which was actually just my root index.php). This told me that because the Google API had changed, my software package functionality was obsolete, and I needed to explore the code there.
I have a mvc4 web app that sits behind ADFS 2.0 authentication, it's configured using the web.config file. The application can be visited by going directly to a URL or as an iframe inside of CRM 2013.
The application works in all (tested) browsers when visiting the URL directly, both redirection to login form and handing the user back to the web app with the proper information in the ClaimsIdentity.
However, when visiting the app as an iframe inside CRM2013, internet explorer goes into a continous login loop. You are asked to provide the credentials (which are the same as for logging in to CRM) and when you click ok you get redirected back to the same login page again, to my knowledge the app never receives the hand off.
In Safari, Chrome, Firefox, and Opera the users are able to log into the application inside of CRM as well as outside without any problems (I'd even go as far as saying that it works better than expected for these browsers).
Does anyone have any idea of what I can try or what the problem could be for IE?
EDIT 1
I'm thinking it has to do with some security setting and am playing around with the settings in IE. Unchecking this box stops the login form from showing in IE at all and I get an empty page instead.
Is the iFrame on the same (sub)domain as the site inside? You can use Fiddler to view your redirect flow, are the cookies added as expected?
I've seen cookies that are overridden by the iFrame host, in that case you lose the auth cookie. Browsers react differently on same domain cookies.
Another problem might be X-Frame-Options, do you see any warning in the F12 console of IE?