We've done a poor job of removing deactivated users from Okta groups. I would like to clean that up but there is now way to do so via the UI. I tried this in Postman but receive an error that the HTTP method is not supported by the endpoint.
{{url}}/api/v1/groups/00g1avm8w61q5ChdB0h8/users/users?filter=status eq "DEPROVISIONED"
I also tried:
{{url}}/api/v1/groups/00g1avm8w61q5ChdB0h8/users?filter=status eq "DEPROVISIONED"
and
{{url}}/api/v1/groups/00g1avm8w61q5ChdB0h8/users/filter=status eq "DEPROVISIONED"
Does anyone have any suggestions?
If you go to the deactivated user, check the groups tab and there should be an X to click to remove the user from groups even though in group management interface it only lists active users.
It can be done via the UI, it's just not obvious. It's possible this was changed since the question was asked but given the UI's a bit confusing it's still worth putting out there.
Related
I have an application and I use Cognito + Identity provider to use google accounts as my users. In Cognito, I have several groups, and in my application itself admin users can add users to groups, remove them from groups, and so on. The thing is, for these changes in the user to be reflected, the affected user needs to logout and in again in the application.
Having a new token fetched on every page load/request does not seem like a good practice. Therefore, I was looking for a Cognito function that would allow me to log a certain user from all it's active sessions. I looked for functions such as logout and revoke, but they require that I have the affected user's access token - which I obviously don't. After that I started playing around with other functions that could have the same effect, such as AdminForgetDevice - I thought that by forgetting a device maybe Cognito would log you out, but that is just used for 2FA, which my application doesn't support.
Seems to me a pretty basic thing what I'm trying to do, and kind of impossible to think that Cognito doesn't support it. Am I asking the wrong question? Is there an endpoint to accomplish this, or a different token-retrieval approach that I should use? I just want to make sure that if a user's groups were changed, those changes reflect immediately. My approach right now is forcing all that user's sessions to end.
I reached out to AWS support asking about this, and their official answer is that Cognito has no action to end all sessions of a specific user immediately. But I came to a solution on my own. You have two options:
1. User global signout and wait 1 hour until the user session is expired.
Not a fan of this solution. If you removed access from a user, makes no sense that the user can still use their old permissions for an hour.
2. Make your interface aware that the user should be logged out and use the logout function
This is the approach I'm going with. The moment an administrator changes a user's permissions, I am creating a notification for that user. The interface, once the user accesses it, know that there have been changes to that user because of the notification. The interface, then, in possession of the user's accessToken, can simply call the logout function.
I've built a CRM webapp with Django for a specific lead heavy industry. It's working for both gmail and outlook users. Through MsGraph and Google API, the user is able to give authorization via Oath2 to the app to access their inboxes. The app then grabs and parses emails from various sources.
Each lead source always sends the lead emails with same subject. This makes the lead emails easy to identify from the users inbox. Unfortunately, the subject of EVERY email that comes in has to be searched to find the desired lead emails. Unfortunately, Identifying by sender isn't an option, and wouldn't change the issue. Each email would still have to be searched.
I have a couple of colleagues beta testing right now.
As I think about taking on new users that may be outside of my colleagues, I am starting to think the webapps unrestricted access to a user's inbox via the available scopes isn't the best approach for trying to attract new users. I would be suspicious of any 3rd party program wanting to access all of my emails, even if just searching for specific emails.
I use Google's watch() and MsGraphs subscriptions to do this while the user is offline. It doesn't appear that Google or Microsoft allow for any kind of message change filter based on what's in the subject line.
Are there any methods that I have not been able to find in either Google API or MsGraph documentation that would limit access to only the emails that meet the subject search criteria?
Would this even pass either of their security checks to get 'Published Status.'
Reading through the Google docs, it looks like you can set authorization scopes that limit access to just labels and basic settings. This should allow you to filter messages by subject and apply labels to those filters.
Of course, the subject filtering doesn't have anything to do with authorization. But fine tuning the authorization is better than allowing write access to an entire mailbox.
I would say in general, the more open the permissions are, the less likely you are to get approved. Google wants you to only have access to what you need to achieve the product's purpose, nothing more.
https://developers.google.com/gmail/api/auth/scopes
There definitely isn't a way to set custom permissions based on subject. In fact, I don't know many APIs in general that allow you to define custom permissions that granularly.
That said, it doesn't seem like you even need read access to message headers, let alone message body content, to achieve what you want to do in Gmail.
I assume Microsoft has similar scoping, but I'm not sure.
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've set up a Django/python web application running on Google Cloud Platform's Kubernetes Engine pods, and secured by GCP's Identity-Aware Proxy.
It all works great, but there are two things I'm not sure how to accomplish.
1) How can I restrict the users to a specific domain, just like the hd=my_domain.com URL parameter does on OAuth2 logging in? That makes the sign-in page only show emails with that domain in the list to click on.
2) How can I enforce that the user logs in with a password, instead of just simply clicking on the account? This is just like when you go to admin.google.com, or security.google.com and even though you're logged in, it forces a password. I know how to go to /gcp/clear_login_cookie to enforce a new login session when I want to log them out, but not sure how to enforce a password is entered. This I believe is called the "user presence test."
Any help is greatly appreciated, I've poured through documentation and have searched various ways on Stack Overflow to no avail.
Both of these items are on our roadmap, though I can't offer a specific timeline.
I don't see an entry in Issue Tracker for either of these. I'll try to remember to add that next week (at which point I'll add the links here), or you can do it yourself: https://issuetracker.google.com/issues/new?component=190831&template=1162609
Thanks for the suggestion, and sorry I don't have a better answer for you!
--Matthew, Cloud IAP engineering
Scenario:
I have an administration-application which manages the user accounts for another application. Now I would like to place an user-specific-link (e.g. Click here to login with user1) in the administration-application allowing the admin to directly log in with the user in a separate browser window or tab (target="_blank").
Problem:
When the admin clicks two or more links and opens two tabs with tab1=user1 and tab2=user2, the last clicked tab overwrites the session-variables of all other tabs. Sure... that's how sessions work, but I wonder if there is a way to let the admin manage multiple user interfaces with one session in multiple tabs? But I don't see a possibility to identify a specific tab in the browser so that I could say "in tab1 is user1 and in tab2 is user2 logged in ...
Question:
Has anyone done something similar and likes to share the basic idea of solving this?
EDIT:
One possible solution could be to add an parameter to the URL with the userid and hand it through to every page, right?
As your edit points out, the way to do this is with a url variable that specifies who the user should be.
There are a number of security issues with this approach tho.
I'm assuming that your initial link is doing some sort of security check to make sure that the initial "log in" of the user is an authorized request. You'll need to do a similar thing for this method. If your initial request is something like http://example.com/page.cfm?userid={id}&authtoken={encryptedtoken} I would then put that userid into the session scope as a valid userid that the admin can impersonate. The more links they click on the more users they can impersonate. On subsequent requests you check the requested userid against the allowed list in the session and either allow or deny the impersonation.
You'll also need to update all the links on the site so that they include the userid in them. The easier way to do this is to cheat and user jQuery or such to rewrite all internal urls with the userid appended. You would conditionally include that javascript based on the above check.
Lastly you'll likely want to prevent these urls that include the userid from appearing in search engines, if it's not a fully locked down site. You'll either need to use canonical urls to remove the userid, or set x-robots headers to tell search engines not to index the urls where the userid has been specified; or both.
That's the most primitive method of getting different "sessions" for multiple users in the same browser. However you'll then bump into issues if you're using the session scope for anything meaningful, because each tab will try overwriting the other. You'll need to overwrite the normal site session variables on each request, or you'll need to create different structures in the session scope for each userid that is used. How much of a problem this is depends on your application.
It's a do-able thing, but probably a lot more work then you were hoping for.
The other option is to get the admins to use Google Chrome with multiple profiles and copy and paste the login url into different profile windows. A slight inconvenience for them, but a lot less work for you.