I need to export a list of groups in G Suite to compare with the source from a recent migration from another mail provider. I'm stuck, trying to get Postman desktop client to connect via api to the Directory API of our g suite instance.
Basically I'm an API noob and have no idea how to get the two to talk. I've setup an OAuth2 client ID and Secret, but not sure of what settings to use in Postman to get authentication up and running. Using Authorization code or Client ID as the option for "Grant Type", either way I get a 401 error.
The only field I haven't entered anything in is the "Callback URL" not sure where to get it from. Seeing mixed info in Google's documentation. Do I need a service account or just the OAuth ID and secret?
Closest I've gotten is: "Invalid parameter value for redirect_uri: Missing scheme: /" using the Authentication code grant type. Left blank but I'm almost sure that is referring to the callback url.
What am I missing here? Or where do I find the callback URL if that is all?
Here is a script that should handle authorization and export a CSV of all your groups.
https://github.com/jmathai-google/all-groups-in-customer
Related
I'm following this tutorial here to attempt to authenticate using Token Based Authentication with Netsuite:
through postman using Netsuite's Postman environment, but I continue to receive "401 Invalid login attempt".
When I check the Login Audit Trail, I see that there is no role being assigned to my authentication attempts -- it's just blank. To me, this indicates that the token is not properly assigned to the User/Role, but I've walked through the directions several times and everything appears to be setup properly.
I've seen other similar posts about this, but those seem to boil down to the Netsuite Account ID formatting. However, my Netsuite Account ID is all numbers, so I don't think this is a factor.
This should work fine assuming you have created an integration and an access token. Configure Oauth 1.0 in postman with the following fields filled out correctly:
signature method (should be HMAC-256)
consumer key (from the integration you created in netsuite)
consumer secret (from the integration you created in netsuite)
access token (from the access token created in netsuite)
token secret (from the access token created in netsuite)
realm (your account id, if using a sandbox, make sure the realm looks like 1234567_SB1, with an _ and not a -)
You won't be able to complete TBA using postman because using netsuite TBA requires a callback URL that netsuite will redirect you to with the necessary credentials (access token and & token secret).
I'm having this exact same issue. I have custom code written in Salesforce APEX that is connecting to NetSuite just fine. We also have a Workato integration that is connecting to NetSuite just fine.
No matter what I do in Postman, I get a 401 Invalid Login response. I'm losing my mind...
I finally got this to work for me. Postman had a request header of "Connection"="keep-alive". Once I removed that it worked fine! Wow.. I've been trying to get this to work for weeks, looking at it every few days for an hour or two. What a frustrating error message "Invalid Login".
I have some applications served to my company users on EKS (i.e., Jenkins). In company we use Google Workspaces (GSuite) for email and stuff. So I want to allow users to login with Google creds to those applications I serve. I figured out I could use Cognito to achieve it but I cannot connect those and flow end with Google showing 403. Error: app_not_configured_for_user. In their documentation I can find:
Verify that the value in the saml:Issuer tag in the SAMLRequest matches the Entity ID value configured in the SAML Service Provider Details section in the Admin console. This value is case-sensitive.
but how do I debug it? I do not see a logs from neither AWS and Google sides :/
I think I followed all possible guides and I cannot find what I'm doing wrong. I found that Google has this page but they do not provide exact scenario for AWS Cognito. Anyways all of those are very similar so I guess I shouldn't have problems, but I do have.
What I did:
In Google Admin (one for workspaces) I created "Web and mobile app" of SAML type
I downloaded metadata file
In AWS Cognito console I created User Pool
I created IdP provider and uploaded metadata file there
I created application client
Using those values I filled fields ACS URL and Entity ID in Google Admin using values:
ACS URL: https://my-domain-i-just-created.auth.us-east-1.amazoncognito.com/saml2/idpresponse
Entity ID: urn:amazon:cognito:sp:us-east-1_myPoolId
I also selected Name ID format to be Persisted
In attribute mapping I mapped email value to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
In AWS Cognito I enabled HostedUI and also created mapping of http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress to email field.
And now when I click View Hosted UI in AWS console it will redirect me to Google authentication and after it directly to before mentioned 403 app_not_configured_for_user page.
I tied it 3 times with slightly different configurations of mapping, signed responses, etc. but nothing gets me past that error.
Anyone tried to integrate it?
How to troubleshoot the 403 app_not_configured_for_user error related to SAML apps from the Google Workspace Admin console
The first thing you need to do is to grab a HAR file recording the whole login process and find the SAML request. Steps can be found here.
Once you get the file you can open it using that tool and search for SAMLreq at the top right (see image).
After that you will get a list of values containing information. You will have to check one by one until you find the one that has the SAML request in the request tab (see example below).
Once you get the value from the SAML request, copy it and you can use this tool to do a SAML decode and find the entity ID. You can use Ctrl + F and search for saml:Issuer to find the value faster. If the value does not match, then you know you have an error and you will need to contact the support team from the app to see which value is the correct one.
In case the value matches I would recommend opening a ticket to check with Google.
I'm trying to setup a VPN connection using a federated login with Google IdP following these instructions.
Previously, I had configured a saml-provider with Google and it worked fine to authenticate users to the AWS console through Google using ARN roles
WHen I setup the VPN connection, it successfully opens the browser and asks me to select my google account, but after selecting the account I'm getting an error message from Google
According to this help section
Verify that the value in the saml:Issuer tag in the SAMLRequest matches the Entity ID value configured in the SAML Service Provider Details section in the Admin console. This value is case-sensitive.
So this is a problem coming from AWS and not from me ? Is Google IdP compatible at all with VPN authentication ? (I found this doc that mentions compatibility with okta)
Edit
Thanks to some of the answers below, I managed to make it work with Google IdP. Here is a screenshot of relevant SAML Google app screens (note that for groups I ended up adding the employees department, but I guess anything else would have worked)
To be able to save an ACS URL starting with http:// in the G Suite interface, use the trick given by teknowlogist: open the inspector > network tab, perform the request to save an URL with https, then right-click copy it as cURL, replace https by http, paste in regular console, and you're good.
I found a workaround to not being able to input http://127.0.0.1:35001 as the ACS URL on the GSuite SAML app page. The Google admin console only does client-side validation for the https requirement, so you can use the Chrome console to monitor the network call made when modifying the ACS URL.
Then, you can copy this as a curl command and change https to http
#Ted Schroeder —
Previous approach (or, plain Google doesn't work)
I just used a reverse proxy:
mitmproxy \
--listen-port 35000 \
--mode 'reverse:http://127.0.0.1:35001' \
--set keep_host_header=true
If you change Google SAML's ACS URL to be https://127.0.0.1:35000 and click "Test SAML Login", Google will take you to https://127.0.0.1:35000, whose traffic will be redirected to http://127.0.0.1:35001. In the browser I get:
Authentication details received, processing details. You may close this window at any time.
However, using the SAML-tracer extension, I found that there was a URL mismatch (https://127.0.0.1:35000 vs. http://127.0.0.1:35001). Seems like the AWS VPN Client is broadcasting its expected URL as being http://127.0.0.1:35001. So this doesn't seem viable.
Current approach (or, Auth0+Google works)
I tried using Auth0 instead, and got it to work! There's a few hoops — for instance, create a new Auth0 application, go to Addons and enable SAML2 Web App, set Application Callback URL to http://127.0.0.1:35001, and then in Settings use the following:
{
"audience": "urn:amazon:webservices:clientvpn",
"mappings": {
"user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
"email": "NameID",
"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"given_name": "FirstName",
"family_name": "LastName",
"upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
"groups": "memberOf"
},
"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect",
"signResponse": true
}
Then users, if they download the VPN config from AWS and use the AWS VPN Client app, will be taken to an Auth0 login screen where they can login via Google. Voila! (And then for security, you need to add Auth0 Rules to grant only certain users/groups authorization.)
I don't have a full answer yet, but I have the beginnings of one and I actually got past the 403 error above. The key to all this can be found in the AWS Client VPN information here: https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/client-authentication.html
Look for the section entitled "Service provider information for creating an app".
The key is that these are the ACS URL and the Entity ID that need to be used. Unfortunately, G Suite won't let you set the ACS URL to a non-https URL and apparently the AWS Client VPN app won't provide a secure URL for the ACS URL (where the SAML Authenticate response goes).
So, if you set the Entity ID to "urn:amazon:webservices:clientvpn" and have the G Suite SAML app in place according to the instructions, you'll get past the 403. However, since the ACS URL can't be specified you get whatever error message you're likely to get from the ACS URL that the authentication response goes to.
Example scenario
If you set it to https://signon.aws.amazon.com/saml" like you would for AWS Console SSO, you get an error from the AWS sign in that the SAML response was invalid.
And if you set it to https://127.0.0.1:35001 then you get a message from the browser that the "site can't provide a secure connection".
If anybody gets any further with this, I'd love to hear about it. In the meanwhile, I'm going to be looking into non-AWS OpenVPN clients that might actually support G Suite as a SAML IdP.
#alexandergunnarson
Since I don't have the ability to comment (thanks so much for making this easy stackOverflow) I had to edit my answer to get it past the censors.
Unfortunately, we don't have, and probably won't have for some time, G Suite Enterprise because it's too expensive for our startup environment. So OIDP is not a viable option for us now. I figured this would work. Good to know that it does.
I was too having the same issue. In my case, I needed to turn on the two-factor authentication for the account that I was trying to log in with.
I am trying to use the Google Contacts API and the Python / GDATA client handlers to access Contacts via OAuth 2.0 for users in the domain. I'm ultimately wanting to create a web service to add contacts for users, but the first step is getting this test working.
I can access my own Contacts just fine if I use the default URI. However, when I pass in the email address to construct the URI for another user, I can't seem to access the other user's Contacts. Here is the code that I'm using:
client.GetContacts(uri=client.GetFeedUri(contact_list=userEmail))
A 403 error is returned when I execute this.
gdata.client.RequestError: Server responded with: 403
Your client does not have permission to get URL /m8/feeds/contacts/<userEmail>/full from this server.
Mostly just trying to understand if what I'm attempting here is even possible. In the Email Settings API, for example, you can get authenticated to the domain and pass in a user's email to list their labels, add filters, etc. So, I would anticipate that the Contacts API would work the same, though handled slightly differently, i.e. modifying the URI, instead of just passing in an argument to the client handler. Please let me know if I am wrong in that presumption.
For authorization, I'm getting the details using flow_from_clientsecrets, then getting the token to authorize the ContactsClient for the domain. Again, I can access my own contacts fine, so authorization seems OK, but I can't access other users' contacts.
client = token.authorize(ContactsClient(domain=domain))
Seems like I'm missing something with respect to accessing other users. Is anybody able to assist me over this hump? Here are some things that I've checked / confirmed:
Contacts API is enabled for the project
Scopes have been authorized for the Client ID in the control panel > Manage 3rd party access
I am a Super Admin in the domain.
Thanks for your time!
I figured out the answer here from another post with exceptional detail:
Domain-Wide Access to Google GDATA APIs
You need to use "Service Account" authentication. For some reason, I was thinking that would only work with the newer discovery-based APIs. But, service account access also works for GDATA APIs. I can access all the Contacts for users in the domain now.
When I use the Google Analytics Input Step, all I have to enter is my account username and password for the Authorization. From there, the step looks up the Domain Table ID for me. So by just giving this step my username and password, choosing the id and the metrics, I am able to retrieve all of the information I need--no other authorization required.
However, I am trying to recreate this by using the HTTP Client Lookup step (with a Generate Rows step before it). I gave it the following URL, as described by http://code.google.com/apis/analytics/docs/gdata/v3/reference.html:
https://www.googleapis.com/analytics/v3/data/ga?ids=ga:{*My Domain Table ID*}&start-date=2010-08-01&end-date=2012-04-01&metrics=ga:newVisits
and filled in the Http Login and Http Password fields with my username and password (exactly same as in Google Analytics Input step), respectively. However, when I preview the results of this HTTP Client step, the transformation returns an error that says that Login is required.
I have also tried this with the REST Client Lookup Step (with a Generate Rows step before it). I chose the GET HTTP method, the JSON application type, and filled in my HTTP Login and password for authentication. When I try to run this, it does not return an error, but in the result field of the preview output it says "Invalid Credentials."
What is the Google Analytics Input Step doing differently from the HTTP Client Lookup and REST Client Lookup steps? And how do I access the same information using those lookup steps?
I want to be able to access API's from other web sites as well, not just from Google Analytics, so it is important for me to be able to do this for any API.
Any help appreciated!
I have made a request to google analytics using HTTP client step, and it works perfect.
First, you need a token from Google Analytics:
https://www.google.com/accounts/ClientLogin?accountType=GOOGLE&Email=xxxxxxx#gmail.com&Passwd=xxxxxxx&service=analytics
This token is a long string.
The token is going to step client as HTTP header. The parameter must be called:
Authorization = token
Others parameters:
GData-Version=3.
After you add the request parameters. (ids, start-date, end-date, metrics, filter, segment)
You also have to add the key to your profile id, as the last parameter.
This request returns a XML. Use XML parser step to get metrics value.
which Kettle version are you using? as far as i know there are some changes in google api
read this bug report:
http://jira.pentaho.com/browse/PDI-7942