My app is on Azure AD and I'm using the following code to request authentication on the Auth Service:
HttpContext.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/Home/Index" }, WsFederationAuthenticationDefaults.AuthenticationType);
What happens is that this works in some browsers (there is no pattern) and sometimes it doesn't work in others.
When the application redirects to /home/index, sometimes the object User.Identity has the user's email but sometimes it has no information.
Why is this happening?
Seamless SSO doesn't work in private browsing mode on Firefox and Microsoft Edge browsers. It also doesn't work on Internet Explorer if the browser is running in Enhanced Protected mode.
For SSO implementation , please consider browser consideration doc published here
As per last update , here is supporting browser list
Mozilla Firefox (all platforms)
Mozilla Firefox doesn't automatically use Kerberos authentication. Each user must manually add the Azure AD URL to their Firefox settings by using the following steps:
Run Firefox and enter about:config in the address bar. Dismiss any notifications that you see.
Search for the network.negotiate-auth.trusted-uris preference. This preference lists - - Firefox's trusted sites for Kerberos authentication.
Right-click and select Modify.
Enter https://autologon.microsoftazuread-sso.com in the field.
Select OK and then reopen the browser.
Safari (macOS)
Ensure that the machine running the macOS is joined to AD. Instructions for AD-joining your macOS device is outside the scope of this article.
Google Chrome (all platforms)
If you have overridden the AuthNegotiateDelegateWhitelist or the AuthServerWhitelist policy settings in your environment, ensure that you add Azure AD's URL (https://autologon.microsoftazuread-sso.com) to them as well.
Google Chrome (macOS and other non-Windows platforms)
For Google Chrome on Mac OS and other non-Windows platforms, refer to The Chromium Project Policy List for information on how to whitelist the Azure AD URL for integrated authentication.
The use of third-party Active Directory Group Policy extensions to roll out the Azure AD URL to Firefox and Google Chrome on Mac users is outside the scope of this article.
Hope it helps.
Related
When I use a service used for online authentication, I get an url to navigate to that will automatically open an app that is used for the passcode input.
The url is in this format:
bankid:///?autostarttoken=2a1b5e2c-c9fb-4402-1239-2a1619d655e9&redirect=null
The navigation to this kind of urls do only make sense on a mobile unit where a certain app is installed.
Nevertheless, desktop browsers (not everyone) also try to navigate to such an url, like it would ever be possible. That of course results in an error page.
Why do they do that?
Do I need to use a hidden form?
Will every mobile unit honor that?
The custom URL scheme is used to be able to start an application locally, in this case the BankID client which handles the 2FA.
This works nicely on both mobile and desktop, as long as the custom url scheme is registered. AFAIK for mobile, if the URL scheme is not registered locally, it will query the appstore and let the user install from there. The BankID is available for both iPhone and Android in the appstore. On Windows it also query the appstore, but the BankID client is not available as Windows App, so it has to be installed manually from https://install.bankid.com. On Mac I have no idea if it queries the app store, but I know it has to be installed manually from https://install.bankid.com
Android, iPhone, Windows Phone, Windows mobile, Windows XP and later, MacOSX all honors the custom URL scheme but it also need to be honored by the browser, which all the major browsers do.
Historically, before mobile, we used to start programs using the NSS plugin support in the browsers. NSS plugin support was removed by the browsers since it was easy to mis-use from a security point of view.
That's why the custom URL schemes are used.
As you can read about in the BankID relying party guidelines, there is a transition to use https://app.bankid.com links to start the client instead. Basically, that's just a custom url scheme similar to bankid:// but registers both protocol (https://) and host (app.bankid.com), which then starts the app. This has the added benefit that if a user who hasn't got the client installed and is not able to find the client via a appstore or similar, will get the web site available, which then can help the user to install the client.
As the idea of an applink is to let the user navigate to the website if the URL is not registered locally, don't hide the navigation.
I have a web app running .Net 4.5.1 and Identity 2.
In my WebApi I have an iOSLoginController.cs using code grafted from the main .NET Identity's AccountController.cs. It's being fed from my iOS app using AFNetworking 2.0.
It works fine locally in my local iis. Logs in fine. But when published to Azure, it isn't actually logging in but it still says 'success' at:
var result = await SignInManager.PasswordSignInAsync(usernameToCheck, model.Password, false, shouldLockout: false);
// switch on result
switch (result)
{
case SignInStatus.Success: <-- it says it's successful ?!?
But then if i check right away with AFNetworking in a WebView, it's not logged in and redirects to Login?ReturnURL=..c (My app is hybrid and uses Webviews for info/stats and native for login/signup and worked fine in Identity 1, this is an upgrade site)
It's not the iOS app, it is working fine against my local IIS and another regular physical server. But when I change where the base url for the API to point to the Azure machine, it's just not logging the person in... but saying success... I verified by attaching to the process in VS2015
I have set a machine key manually as well in the web.config so it won't rotate and log users out when IIS starts recycling processes.
Any ideas?
Modern browsers reference the Public Suffix List for cookie domains, which are regarded as public.
The idea of the list originally came from the need to protected top level domains, like .com, as it would have been possible for anyone to set a cookie for all domains ending .com, which would affect all sites with of the top level .com domain.
The list also contains other domains considered to be public. This list is maintained by the community and the azurewebsites.net domain, amoung others, is part of this list.
Thanks to this, it isn't possible for a person to setup an azure app and hijack cookies in other peoples apps on the shared domain.
We need to access the intranet site called as "http://mysite/myapp".
And with using IE, every domain users can access the site without any prompt.
But, if the user try it with Chrome, the logon prompt shows at first. After entering credential just once, the prompt doesn't appear anymore for the access.
I'm just wondering any way to avoid the first-time logon prompt on Chrome.
And we don't want any chrome browser setting or shortcut for white listing per user. Because we can't handle many users Chrome one by one.
Any help will be appreciated.
Thanks.
Check the details of the Integration Authentication in this Chromium documentation:
http://www.chromium.org/developers/design-documents/http-authentication
With Integrated Authentication, Chrome can authenticate the user to an
Intranet server or proxy without prompting the user for a username or
password. It does this by using cached credentials which are
established when the user initially logs in to the machine that the
Chrome browser is running on. Integrated Authentication is supported
for Negotiate and NTLM challenges only.
Basically, execute Chrome with these switches to specify the auth schemes:
Chrome.exe --auth-server-whitelist="MYIISSERVER.DOMAIN.COM" --auth-negotiate-delegatewhitelist="MYIISSERVER.DOMAIN.COM" --auth-schemes="digest,ntlm,negotiate"
I tried running the command line but it wasn't working. I had to configure the same settings via the Windows Registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthSchemes"="basic,digest,ntlm,negotiate"
"AuthServerWhitelist"="*domain"
"AuthNegotiateDelegateWhitelist"="domain,server.domain.com"
Then I Killed Chrome (cmd line: TaskKill /im chrome.exe) and restarted chrome and tried again and voila. Everything worked as expected.
NOT the (fka Metro) style IE10, but the desktop version.
I have an app that accesses Dropbox. OAuth works fine with IE9 and other browsers.
However, on Win8RTM, IE10 doesn't accept the URI redirect after I login to Dropbox and approve my app's access.
Once I approve access, Dropbox returns a URI to open my app and pass it the new token. In IE10, it fails: error Cannot handle https....
I changed the default browser to the latest Chrome, and it worked fine.
I even added Dropbox to my Trusted Sites list.
Works fine in IE9 on my Win7 test box.
Here's a link to my beta. Just need to fix this setup issue and do the graphics for the buttons and its finished.
https://dl.dropbox.com/u/17111851/SMARTLIST.ZIP
I've created a basic MVC 3 website that's using Windows Azure's Access Control Service (ACS) to perform user authentication against an Active Directory Federated Service (ADFS) endpoint. I followed the "Add STS Reference" wizard and the site runs fine and authenticates users just perfectly in IE. However, when I use Chrome or Firefox it continually prompts for my credentials over and over again.
I found this post on technet that mentions the issue as it pertains to Firefox but there's no fix for Chrome mentioned, nor do I feel like the steps required to fix Firefox are practical in the real world (i.e. I can't expect end users to do this)
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-when-using-firefox-3-6-3.aspx
Has anybody else hit this snag? What am I doing wrong?
With some help from a Microsoft Rep (Adam Conkle) over on TechNet (scroll down to the comments), I finally have an answer to this problem.
Turns out, the ADFS website that performs authentication of users (this website gets setup in IIS during the installation of ADFS v2.0) is by default configured for Integrated Windows Authentication (IWA). IWA is configured in IIS to use Extended Protection for Authentication (EPA) and therein lies the problem. Apparently, most other browsers don't support EPA yet which is why Firefox & Chrome continually prompt for credentials in a loop.
Two options...
Keep using IWA but turn off EPA in IIS for the website (described here)
Turn off IWA in favor of Forms-based Authentication (described here)
I had the same issue, sort of. I had 1 person who was being prompted in Chrome and another that was not. On a hunch, I looked at the trusted sites. The person who was being challenged had the intranet site in their list of trusted sites. I removed it and tried again. This time they were not challenged.
Thought I would put that out there in case anyone else has this issue.