I'm following the "Gauth authentication" portion of Djangae's documentation but I'm running into some unexpected behavior.
I've configured urls.py and settings.py as specified by the documentation (the current settings are mostly a result of using the Djangae Scaffold) but at no point are users prompted to authenticate using or link their Google account. I've tried un/setting DJANGAE_CREATE_UNKNOWN_USER but this has no impact.
I've also tried running commands inspired by sitepackages/prod/djangae/contrib/gauth/tests.py in my local shell in order to verify that the back-end configuration is correctly configured and that users can actually be authenticated against AppEngineUserAPIBackend but that fails because my User model (djangae.contrib.gauth_datastore.models.GaeDatastoreUser) seems to be missing required attributes: AttributeError: 'GaeDatastoreUser' object has no attribute 'user_id'.
So, am I misunderstanding how this is all supposed to work and must take some additional steps to get Google Sign-In working? Or have I (likely) misconfigured my application? (I'm happy to include genericized versions of my config, but as I said, they've come directly from Djangae Scaffold or the documentation.)
UPDATE: Interestingly, if I remove the --headless flag from my Behavior suite config, I see the expected behavior. The browser (Chrome) is being redirected to https://accounts.google.com/Login?continue=http%3A%2F%2Flocalhost%3A8080%2F
Environment:
Djangae (0.9.11)
Django (1.11.19)
It turns out that this is the expected behavior. In the local sandbox, users are prompted for an email address and (by default) a "user" is created for them and they are automatically logged in.
From App Engine's "Users Python API Overview" document:
Google accounts and the development server
The development server simulates the Google Accounts system using a
dummy sign-in screen. When your application calls the Users API to get
the URL for the sign-in screen, the API returns a special development
server URL that prompts for an email address, but no password. You can
type any email address into this prompt, and the app will behave as if
you are signed in with an account with that address.
The dummy sign-in screen also includes a checkbox that indicates
whether the dummy account is an administrator; that is, whether the
account has the the Viewer, Editor, or Owner primitive role, or the
App Engine App Admin predefined role. If you check this box, the app
will behave as if you are signed in using an administrator account.
Similarly, the Users API returns a sign-out URL that cancels the dummy
sign-in.
The unique ID for a User object in the development server is
calculated from the email address. Two unique email addresses always
represent two unique users in the development server.
Personally, I think this design is very flawed. I don't know what Google thinks about the Twelve Factor manifesto, but this behavior is a flagrant violation of article 10 (Dev/Prod Parity), which is summarized as "Keep development, staging, and production as similar as possible". I see no reason why the full auth/redirect flow wouldn't work in the local sandbox and, at the very least, users should be able to opt into it. (I would love to find out that this is an option.)
The most concerning part about this conditional behavior is that the user object's API is different, which is why I was seeing the error mentioned in my question ('GaeDatastoreUser' object has no attribute 'user_id'). The local user also has no nickname method.
Related
I use google Ouath2.0 with passport.js in my Next.js/Node.js web-app. Registering and logging in works as expected. However, anyone with a google account is able to register, regardless of being in the test users list. The app is unpublished, and so only test users registered by me in the Oauth Consent screen should be able to register and login.
Does anyone know how to fix this? As far as I have understood it, login when not registered as a test user should simply fail. I have seen this asked elsewhere with no answers, and I am not able to contact google as that requires a paid support level.
I had a quick look at this and observed the same (incorrect) behavior; I too was unable to restrict authenticated users to the list of test users:
Created Apps Script Web app (for a quick win)
Associated a Cloud Platform project with it
Enabled Gmail API in the project and added one of its "restricted" scopes
Added one Google account to test users
I was able to login using the test user and any other Gmail account regardless of whether I included a Gmail restricted scope.
One thing I observed but am unable to explain is that I was not presented with the app's (project's) OAuth Consent Screen. Each time I logged in (incognito), I was prompted by the standard Google login screen only. I expected to be prompted by the OAuth Consent Screen before accessing the app. This likely explains why identities aren't being limited to the test users but I'm unsure why I'm not seeing the consent screen.
Even without Google paid support, you may file issues like this using Google's public issue tracker and these will be seen by Google Engineering.
I recommend you file under "Cloud Platform > Security & Identity" and let someone within Google triage:
https://issuetracker.google.com/issues/new?component=187167&template=1162765
I'm developing a webapp which allows users to log in with their Google accounts, using OAuth2.0.
I've created an OAuth2.0 client ID, configured the OAuth consent screen with the Publishing status set to 'Testing', and added a test user.
The frontend of my app is built with React, and I'm using a package (react-google-login) to handle the flow. I can successfully sign in with the Google account I added as a test user, and retrieve the basic profile information needed.
The problem is I can also sign in with other Google accounts, which have not been added to the list of test users. I imagine that Google should simply not issue access tokens for accounts which are not in the list of test users.
I feel like I've misunderstood something about the OAuth process, or I have configured something incorrectly. I would appreciate if anyone had any pointers?
Thanks.
It is indeed bugged.
I was in the same spot as you, assuming I had misunderstood something. After reviewing my code over and over with no luck, I made a Stack Overflow post, in which I was advised to post to Google's bug tracking system. After doing some troubleshooting with Google they confirmed the bug, and they are now working to fix it (for a little while already).
I included this thread as an example when talking to Google. I meant to post an update here after getting in touch with them, but I forgot, sorry!
The buganizer thread with more details:
https://issuetracker.google.com/issues/211370835
Is it possible you're only asking for the email scope?
It appears the test user filter and possibly the whole concept of the 'app' being in test mode exists only inside the consent screen feature.
For some reason, Google doesn't show the consent screen if you only ask for email.
So... maybe that means you don't need a consent screen, and therefore don't need to care what that feature thinks about your app (that your app is in test mode and needs to be verified before going into production).
Or maybe it's a bug? Or maybe just because you can do this doesn't mean it's allowed by Google's terms. Maybe they just haven't implemented preventing that use case.
Anyway, it may help you to know that if you add a more significant scope like the Calendar API then the following things will change:
Non-test users will get a message like "The developer hasn’t given you access to this app." and won't be able to complete oauth
Test users will get a message like "Google hasn't verified this app"
Test users will see a consent screen
Basically, everything starts working as expected.
By the way, just putting "email" or "profile" for scope seems to be an old way of doing things, and all the newer scopes want you to use a full URL for the scope (despite google themselves not using the full URL when you're configuring your scopes).
For example, if you want the email and calendar scopes, you can put this value for your scope field:
email https://www.googleapis.com/auth/calendar
Or you can use this equivalent value:
https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/calendar
Not suggesting you add a scope like email for the sake of it, just that it sheds light on what's happening, and if there's a scope like that that you need anyway, adding it will solve your problem.
I have developed a small application for submitting some data to database server(Oracle 11g). When we are reviewing security of this small application, we observed as follows:
1. We have deployed django with https and all secure configurations like Secure Cookie and Secure Session, No Cache, etc.
2. Using BURP tool for this sample review
3. We have created two different user in this system say Normal User and Admin User
4. Opened 2 browsers(Mozilla and IE 11), On mozilla we login with Admin user and captured session id using burp tool.
5. On second browser we login with Normal user and replaced session id Normal User with Admin User.
6. whoila......On second browser, I got Admin user access by just changing the session id
I have used default session backend for this application.
I would like to know whether this is flaw in django and how to resolve this issue..
Thanks in advance
This is an inherent risk of using session-based identification. It's called session hijacking, and if you search for that term you will find lots of information.
Mitigations generally have one of two goals: making it harder to steal the token, or making the damage less severe if it is stolen. In the former camp are techniques like using HTTPS and SESSION_COOKIE_HTTPONLY. In the latter are things like limiting the length of a valid session (SESSION_COOKIE_AGE). In the end, though, it's difficult or impossible to stop someone from impersonating another user if they get their token, since that's the very thing that establishes identity.
I am a 30+ year programmer, but almost all of it was in the semi-conductor world and none of that was with web sites. I have been given the task of getting wso2is to work with 1 new app and eventually add the already existing apps. Most of the terminology is foreign to me. I have read much of the documentation, it is beginning to make sense. I can get it to run and create some of the items needed, user, role, permissions and claims. But there are some concepts that I don't get from the manual.
Ok I know that what I need to get out of it is simple authorization.
Person->web_app->wso2is->authorization->web_app
We will eventually have several apps that our internal users wish to forgo multiple logins.
So if I have AppA and AppB and I want to use both Apps. I login to AppA, it sends authorization request to IS and it sends back true/false that all is good for AppA, but now I need to get into AppB from the same browser, new tab. It is my understanding that wso2is is single sign-on (SSO). So it looks like I would have to sign also to AppB completely independent to AppA. Our developers are looking to use curl to communicate with IS. So how does IS tie all this together?
I'm very confused.
I understand users, roles, permissions and claims, at least I think I do.
I've managed to add users with REST and SCIM. I've had no luck in getting ANY of the samples to work.
Hope it is not too late to answer this question. I will try to expalin the steps as simple as possible.
Add App A, as service provider in WSO2 IS.
Add App B as service provider in WSO2 IS.
Note: Both apps can be ( and should be) fully independent to each other. By that I mean, App A can be java, App B can be a .net application. They can have different certificates for encryption etc.
When you try to log in to App A in new browser session, it will redirect you to WSO2 login page and there you can authenticate yourself with user id and password.
Now when you try to open App B in same browser in new tab, WSO2 will not ask you again for user id and password, rather it will allow you to access App B. All this happens because of SSO.
This is SSO in the simplest way.
I am working to set up SSO for our intranet the idea is that a user would login to their workstation using their active directory username and password. Then a small application would run at login that would send some uniquely identifiable information,user name, and computers MAC address to the server were it would be entered into a database with a time stamp. Then when the user accesses the intranet a java applet would send the users mac address to the server and compare it to the database entry to see if it finds a match within a given time frame, if it does then it signs the user in and removes the entry from the database.
Unfortunately our intranet is not running on IIS so I can't use NTLM to do authentication which would be easier but not cross browser compatible which is one of the requirements. NTLM is also not an option because our intranet is only accessible in the form intranet.company.com and as far as I know NTLM does not work with addresses in that form.
Okay now onto the question. I am currently in the process of creating the client authentication application in C++ and need a way to get some unique identifier or token that would differentiate a legitimately logged in Active Directory user from some one who got a hold of the application and changed their local username to an AD user.
Yes I know this is probably the wrong way of doing it but right now it seems like the only option. If you have any suggestions beyond not doing it please let me know. Also I am aware of the huge gaping security hole it creates if you can think of a way to patch up that hole with out NTLM be sure to let me know.
AD is just Microsoft's implementation of Kerberos. One of the core features if Kerberos is to create such permission tickets. So, on that side your solution is not a hack at all. It's just the validation part that looks like a car crash.
However, I'm entirely lost at the client-side problem you have. The entire point of AD or Kerberos in general is that you can't spoof an authenticated user. You just ask the OS for a ticket for the logged-in user. It doesn't matter who gets hold of your app, or or what his local username would be. The OS knows precisely who is logged in.