i have some doubts on the SSO functionalities in different browsers,
-> if i enter my SSO application URL in IE browser it is automatically taking my windows credentials and it is allowing me to access the applications without re-authenticating.
-> same URL i have tried in Mozilla and Google Chrome browsers but it is asking for credentials. its weird for me by not taking the windows credentials.
could you please help me with this, do i have to change any settings in mozilla and chrome browsers to access the SSO application without asking credentials.
Note: It is from both the internal network and outside network.
Thanks,
Gowthaman. p
Ping Identity has two URLs that explain the settings required...
IE/Firefox:
https://documentation.pingidentity.com/display/PFIWA31/Step+Five+--+Configure+User+Browsers
Chrome:
https://ping.force.com/Support/PingIdentityArticle?id=kA3400000008RWWCA2
Though, generally, if IE is working, then so will Chrome (on Windows), since it uses the same configuration. If you have the PingFed Server in your "Trusted" sites, remove it.
Related
I've developed an website in Asp.net using VB. One of the requirements was for a qlikview to be displayed.
It's under a type of report hub, where I've got a list on the side of the page where the user can select a report and the rest of the page is an iframe. When the user selects a report, a javascript function is fired which sets the address of one of the reports into the iframe. The reports are all on their own page so I'm basically calling the page from the same domain and showing it in the iframe, no issue here. The problem comes when I've got to display the Qlikview which is hosted on another server.
This throws an error in the inspector but it still displays fine, it works like this on Chrome, Edge, Explorer and Firefox.
The issue comes with Safari, it blocks the authentication request because it is a cross-origin request.
I've tried the answer from this question. I've tried changing the domain name as listed here.
I've tried allowing cross origin access as listed here, but it didn't help.
I'm still very new to this, so i apologize if this is a simple solution.
Take a look here - Maybe this can help you
Using cors with all modern browsers
If it is working ok on Chrome and Firefox it is set ok on server. Qlikview officially support IE and Chrome. Safari have some issue with headers.
If you host your add-on (what is in iframe for Qlikview) on S3 for example for Safari you need to allow origin header, probably on different hostings something similar:
<AllowedHeader>origin</AllowedHeader>
Workaround is also that on Qlikview server it can use IIS for displaying Qlikview access point. If you want you can just go to IIS settings on Qlikview server and just set folder where you deploy your add-on pages so this way it can be configured that both will be served from the same domain (your add-on and qlikview access point). There is also Qlikview server configuration without IIS with Qlikview Web Server which will not allow to deploy another site.
This one's driving me nuts. I have a .Net Web Form app, not MVC. Works fine on localhost, also on a development server running server 2012, as an IP address it works fine on a UAT Server running 2012; but with a URL that is assigned to the same IP address for UAT it redirects to the default.aspx with each postback. Looking in IE, it shows same security level - Intranet, which forces Compatibility using F12 that compatibility shows as ie7 (I'm on IE11), plus everything else looks right in the IE settings. Trying from another PC with a different user, same results IP works, URL doesn't, and all IE settings appear to be the same. Fun thing, Chrome works fine with both URL and IP; but IETab in Chrome has the same issue (running as ie7 or ie11). Anything similar to this out on the Forums just say check Compatibility; which I've done. I can only assume something is weird with the URL or IIS not recognizing the URL for postback; but I don't understand what or why.
In the IE Tools menu select Compatibility View Settings. Then uncheck Display Intranet Sites in Compatibility View. For the life of me I don't know why that is the default setting.
Thanks for the reply. However, it turned out to be an Under Score in the URL. For some reason the Under Score caused the Session Cookie in the Post Back to be dropped. This was only true of Internet Explorer; all other browsers still included the Session Cookie. i.e. Dummy_URL would cause the issue but DummyURL would fix it.
A tester of my new app reported problems with authorization support in ASP.NET MVC app: Whenever he switches to a new tab (different controller), he's prompted for his login again.
After investigation, I found that the server forcibly wants to use cookieless forms authentication using URLs such as in this question.
The problem appears in his Firefox 3.6.15. Not on other browsers on his computer, not on Firefox on other computers. I checked his Firefox options: Cookies are enabled. HTTPfox even says there is an ASPNetSessionId exchanged!
How come? Can anyone shed some light? FWIW, my web.config doesn't say anyhting about cookies or sessions. I didn't even know of these cookieless URLs before seeing them on this computer and doing some research.
Uninstall and reinstall Firefox from his machine. backup his bookmarks first so he doesnt lose anything. It sounds like its an installation issue rather than a coding problem.
I just deployed some changes to my web app, restarted IIS, and suddenly I'm getting 401 errors all over the place. EXCEPT if I enable NTLM authentication in Firefox:
browse to about:config, and agree not to mess anything up
filter by "trusted", then modify "network.automatic-ntlm-auth.trusted-uris" to include my app url, e.g. foo.mycompany.com
restart Firefox, and it gets into the app just fine
IE and Chrome will not let me in, even when I enter the DOMAIN\USERNAME and password.
Any ideas what would cause this behavior?
Turns out a server reboot was needed. Sheesh. It appears that a patch/update was applied to the server that either required a reboot or should have, and in any case wasn't performed. My code rests vindicated, but the cries of my users still ring in my ears.
If my ASP.NET app is set up for ADFS using Windows Integrated Authentication, I know this will work in IE, but will it work in Firefox?
I've seen some things on the web that indicate that there are problems, and you need to put a workaround in each client browser - http://codebetter.com/blogs/eric.wise/archive/2006/11/16/Note-to-self_3A00_-Firefox-Windows-Authentication.aspx
It's not a workaround. Firefox will not send your Windows Integrated Credentials to a website by default. You have to tell it to "trust" the website.
You could display those instructions on a page you direct unauthenticated users to.