We are running an online learning platform on WordPress. We are using MiniOrange to allow SSO to our site for Google (which has worked great). It means our students can sign on using their school email address. However, Azure is proving a bit of a headache.
We have set up app using the instructions that MiniOrange provide and this has allowed personal accounts to sign in without issue.
However, for accounts belonging to a school/other organisation throws an exception asking for admin consent (which we can't logistically get from every organisation we work with).
The app asks for API access to 'email,openid,profile,User.Read' - none of which require admin consent.
We have turned off 'Assignment required?' in our Enterprise settings based on the second option in this post
We have allowed users to consent to any app based on this thread
We are also a verified MPN and have added an MPN ID which is a warning when creating non verified apps
So from our perspective - we have a set of API terms that don't need admin consent and yet users are hitting a wall with it?
Does anyone have any ideas on why this workflow wouldn't be possible? Anything we have skipped over?
There are a lot of tickets with similar issues but none seem to point to anything obvious we have missed?
This could also happen if the Azure AD administrators have turned on "Do not allow user consent" setting in their tenant. This would prevent non-admin users to grant access to 3rd party applications (like yours).
You can learn more about this here: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent?tabs=azure-portal.
I want to use Google Pay in a Firebase web app. The user signs in to a Google account in the app. I have tested the example code from Google Developers for this. It seems to work fine.
Except when I sign out from the Firebase app. Then the Google Pay code still seems to work. Obviously now using the account I have signed in to Google Chrome with.
So I do not know for sure which user Google Pay sees. I can test a bit, but I need to be sure. How is this supposed to work? Where is it documented?
It doesn't matter how the web application is hosted (Firebase or otherwise), Google Pay will launch in the context of the currently logged in Google user.
One way to verify is to visit https://pay.google.com/. It will show you payment details of the currently logged in user.
EDIT: Responding with clarifications (apologies for the length)
I want to use Google Pay in a Firebase web app.
Assume that I in this case is you the developer.
Except when I sign out from the Firebase app.
Assume that I in this case is you the user, signing out of the web application and not the Firebase console.
The user signs in to a Google account in the app.
The web app uses a Google identity to authenticate the user - correct?
It seems to work fine.
Except when I sign out from the Firebase app. Then the Google Pay code still seems to work.
Is the scenario that you are describing the following?
User is not logged into Google
User signs into web app with Google identity and is presented to Google login screen
User clicks on Google Pay button from within the app - everything works as expected
User signs out of the web app
User returns to the web app after signing out of the web app?
User clicks on Google Pay button from within the web app as an anonymous user (from the web application's perspective) - which brings up the Google user's payment details and this is not what you expected
If so, then:
Step 2: two things happen
Google sets a cookie to maintain keep track of the user's identity
Google returns an auth token to your app, your app will generally use this to maintain session state using the auth token
Step 3: using the cookie that was set in step 2, Google present relevant payment methods
Step 4: signing out of the web application should clean up the user's web application session state, but it wouldn't sign the user out of Google
Step 6: because the Google cookie is still present, Google Pay continues to present the user's payment details
From my perspective, this is working as intended.
The web application's session is separate from the Google session, think of it as the web application using Google to bootstrap its own session. Once bootstrapped, they are disconnected from one another.
The user could sign out of Google after bootstrapping and that shouldn't affect the web application. If the user logs into Google as different user, they will receive a different Google Pay profile, and they should be able to fulfill payment with the second Google identity's details despite signing into the web application as the first Google identity.
You should be able to verify this behavior by visiting https://pay.google.com/ after signing out of the web app, then again after signing out of Google, and then signing in again with a different identity.
I have tried my best to search the web before asking this question. I've seen similar questions on stackoverflow, however, none has been answered satisfactorily for a long time now. This is one more attempt to get this recurring question answered.
The Problem
How to build an ASP.NET MVC 5 website which uses "Windows Auth" for Intranet users and "Forms Auth" for Internet users? We'd like to accomplish this using ASP.NET Identity. Moreover, we don't want to use Active Directory Groups for authorization. For Intranet users, we want to authenticate them using Active Directory and then fall back to ASP.NET Identity to manage their roles and other profile data.
It'll be nice if we don't ask the end user to choose auth method. The web app should log in intranet users seamlessly. They shouldn't even know that there is a login screen. Likewise, the internet users shouldn't be asked to enter their domain credentials. They should see form based login screen right away.
Is there any recommended way of solving this? Or could you comment if any of the following are proper solutions?
http://world.episerver.com/blogs/Dan-Matthews/Dates/2014/8/Mixing-Forms-and-Windows-Authentication/
https://github.com/MohammadYounes/MVC5-MixedAuth
http://mvolo.com/iis-70-twolevel-authentication-with-forms-authentication-and-windows-authentication/
FYI This is 2004 article, may not be helpful now:
https://msdn.microsoft.com/en-us/library/ms972958.aspx
IIS configuration
Enable Anonymous Authentication status in IIS for the whole site and Windows Authentication for some folder under root directory (for example, /WindowsLogin). In this folder place aspx file (for WebForms project) or create ApiController (for MVC project).
Site setup
On login page add button “Login with Windows/ActiveDirectory account” (in similar way as it is common practice to add buttons Login with Twitter, Facebook, Gmail, etc.). When user presses this button, they will be redirected to the page or controller in /WindowsLogin folder, which require Windows authentication. If site uses some Single Sign-On functionality, locate it in that page or controller, in other case just save Session for Windows users there. If user accessed that page or controller, they had been authenticated as Windows users already.
One of the possible ways could be creating two sites in IIS, but having the same target folder, where sources of site are located. First site is for internal users with enabled Windows Authentication mode and binding to 80 port, while second site is for external users with Anonymous mode enabled and binding to 8080 port, for example. Then, on firewall you will have to configure NAT, that all requests coming from within local network or VPN, will be redirected to local IIS server on port 80 and all requests coming from Internet, will be redirected to port 8080 of IIS server.
The term for this is Mixed-Mode Authentication. I have done this multiple times. You only need to tweak your main site. Here is how I have done it.
Keep your main MVC site as-is but run it as Anonymous vs. under Windows Auth.
Internal Site
Create a Redirect URL Site: Setup this site as Window Auth so you can pull the User ID from Active Directory. Give your users this URL and/or make it the link they click on your Intranet. Then this site calls your MVC Site and passes the user credentials (login id).
a. This can be done either via an encrypted string on the URL or encrypted value in a cookie. You can encrypt with an expiration date/time value too.
b. (Speaking from Forms Auth) Create a Forms Authentication Ticket with that user ID. Run any other login logic you have. Done.
External Site - No Changes required. Let the users login as-is.
Are you wanting to handle forms and AD authentication from one URL? I have used thinktecture (claims based auth) as the framework for WIF and marshaling various forms of authentication. However to handle if from one URL I had to handle some logic at login that associated the user to AD or Forms based. In a more recent project, this was handled at user management when we created the user account (it was associated to AD of Forms Auth). Then when the user logged in they would preface the AD domain name as part of the login. There are a number of ways to implement this, this was just one I have used. An example, instead of requiring the domain, just use the username, then check for AD or forms based flags on the username and then handle authentication accordingly
EDIT
Just an update in re-reading your question. Are the internet users and intranet users the same? If so you need to just go forms based auth across the board and manage the users in the product DB independent of AD. If they are the same then they could login prefacing the domain name to username. if you wanted to rely solely on AD.
I did a proof of concept of this some time ago, at my previous job, so the details are hazy and I don't have any code to refer to...
The requirements were:
Single URL for internal (LAN) and external (internet) access
Two types of users, people on the domain and external (non-AD) users
Windows authentication for domain users both internally and externally
The ability to enter domain logon details when using iPads (no windows auth)
The core idea in the solution I came up with was that we used Active Directory Group Policy to add a custom string to http request header user agent, the content doesn't matter, in fact we used a long random string of characters.
https://technet.microsoft.com/en-us/library/cc770379.aspx
Then the landing page for the site checks for this, and if found redirects to a virtual directory, with windows auth, that checked their AD account, populated the ASP.NET authentication token and then redirected them to their home page.
If the custom header isn't there then it just displayed the normal login form.
The only other thing was to add an AD email/password check to the normal login form so that if a domain user accessed the site from a non-windows device (iPad) then they could use their normal login details.
Why not put your website code on the server, robocopy it to two separate websites and just handle the changes in authentication by configuring the web.config. (one would be setup with anonymous and one with windows authentication.)
It's not as snazzy as other methods but it's relatively painless. There are two sites but the content (except for the web.config) are identical.
I wish to allow users with Google, Facebook, etc accounts to access my site however can I get them to utilize two factor authentictaion to access the site? Assuming it is posisble, how do I need to do, consider, etc?
You need to use OpenID to allow users to authenticate to your site via their Google or Facebook accounts. See:
https://developers.google.com/accounts/docs/OpenID
once you have OpenID enabled on your site. Users who have Google or Facebook two-factor authentication enabled will still be able to authenticate to your site assuming they succesfully pass 2-factor to Google or Facebook.
Jay
I am trying to implement OpenId for an internal web app. Our college is on Google Apps for Edu, so we have the suite of Google OpenID and OAuth exposed to us.
I would like my login page to have the standard username and password, and additionally a button on the side that will authenticate internal users to our app domain.
I have followed the example here http://www.dotnetopenauth.net/developers/code-snippets/programmatic-openid-relying-party/ but it seems that the rules are different for the google apps id than a general google id.
Any help or further documentation would be helpful.
I have the same problem as you.
For your Google Apps login, your relying party URL is https://www.google.com/accounts/o8/site-xrds?hd=example.comsite-xrds?hd=example.com
Where you replace example.com with your URL.
However, As far as I can tell, dotnetopenauth does not handle the protocol extensions google uses when it returns.
However, using https://www.google.com/accounts/o8/id works perfectly fine.
Using this url, you pass off users to Google to login. Google will check for cookies and prompt for a login if required. if not it'll just confirm with the user that they want to associate their authentication with this site and pass you back.
Still trying to get dotnetopenauth to accept the new url: https://www.google.com/accounts/o8/site-xrds?hd=example.com