I am working on building a Reseller platform where Customers can buy Google app for Business and avail Gmail Services, I need to verify if user has setup MX records so that I can setup MX record verification automatically. So my questions are:
My assumption is, I can use Admin settings Api as a Reseller service account for this purpose, Is it correct?
What is the correct scope for calling this Api, Is this https://apps-apis.google.com/a/feeds/domain/ ?
Can I get working example to accomplish this, for example for domain verification I use Python Syntax.
service = build("siteVerification", 'v1', http=http)
followed by
response=service.webResource().insert(body=request_verify_domain,verificationMethod="DNS_TXT").execute()
I am looking for a similar example to verify MX records as a Reseller service account holder.
Thanks in Advance!
See an end-to-end codelab from Google in several different languages:
https://developers.google.com/admin-sdk/reseller/v1/codelab/intro
To Answer your questions:
You can validate sites on behalf of your customer domains using a service account on your reseller domain.
The scope for the site verification api is: https://www.googleapis.com/auth/siteverification
It is not possible to validate the MX records via the API. If the site/domain itself is validated, then you'll be fine. Mail will continue to flow (assuming you actually set up the mx records) even if the MX records are not "validated" on the domain. Basically, validating the mx does nothing more than get rid of the little nag message in the cpanel -- it's purely cosmetic. :)
Related
I am carrying out the OAuth verification in Google Cloud Platform, I received an email that said:
"Thanks for your patience while we reviewed your project.
Your project pc-api-XXXXXXXXXXXXXXX-XX has multiple unique domains in the redirect URI and origin URLs, many of which have unrelated applications. This is in direct violation of the Google API Services: User Data Policy, which requires that projects accurately represent their identity and intent to Google and to our users when they request access to Google user data.
Please follow the instructions on the Google API Console to:
Create new projects
Migrate your redirect URIs with distinct brands to different projects, and/or
Ensure that these projects accurately represent their true identity to Google users
You can find more information in the OAuth Application Verification FAQ. To make sure we don't miss your messages, respond directly to this email to continue with the verification process."
I have a web server, which checks the validity (domain-1.com) in-app purchases, and I also have a site with a different domain containing: privacy-policy and terms-of-service (domain-2.com).
My settings are as follows:
OAuth consent screen:
Home page application: https://www.domain-2.com/
Privacy Policy: https://www.domain-2.com/privacy-policy/
Terms of Service: https://www.domain-2.com/terms-of-service/
Authorized domains:
domain-2.com
domain-1.com
ID client OAuth 2.0 -> Authorized Redirect URIs:
https://game.domain-1.com:8443
I have a working service account.
I have successfully verified all 2 domains.
Where is the mistake?
I have found the solution:
I had 2 Google Cloud Platform projects for the same application.
I deleted a Google Cloud Platform.
I implemented all the configurations of the deleted project in the other project, and it worked!
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.
Brand new, checking out wso2 API manager 1.8.0. I work for a corp with multiple organizations/teams, so setting up multi-tenancy seems like the logical choice.
Following the quick start guide, I first created a new tenant, gave it a domain of "dev.api.myorg.company.net", added some users to it, and I can log in. I added one API.
I am able to hit the endpoint using the URL listed in the store:
http ://wso2server.company.net:8280/t/dev.api.myorg.company.net/apiname/v1/endpoint
But my expectation was that configuring this tenant with a domain would allow me to hit:
http ://dev.api.myorg.company.net:8280/apiame/v1/endpoint
I have pointed the dev domain to the wso2server IP, but when I try to access using the dev api I get:
http://pastebin.com/VNXjEv3y
Am I just missing something completely obvious? Is there extra work to make wso2 allow tenants to point their domains at it?
I have spent the last hour and a half googling and searching through tagged wso2 here, but google mostly points to the wso2 multi-tenant docs page, which is like a single page without any details.
Any pointers to better docs or suggestions for better search terms? Ive tried combinations of:
wso2 multi tenant tenancy domains hosts how to access
when you create an api in a tenant it will get the following url pattern
http ://**<IP-where apimanger is hosted>**:8280/t/<tenantdomain>/<apiname>/<version>/
where 't' denotes this api url is specific to tenant and tenantdomain denotes which denant
but for super tenant url will be as following
http ://<IP-where apimanger is hosted>:8280/<apiname>/<version>/
For tenanants, domain is just a name (not having mapping to ip).So APIM will not work as you expect.Because you need to specify the IP(or domain) where APIM is hosted in the url.
Does the Google Apps Email Migration API v2 support 2 legged oAuth1?
I've looked at this answer, but I believe it refers to the older version of the Email Migration API: Does Google Apps Email Migration API support 2 legged oAuth?
I have been able to authenticate an Email Migration API request using OAuth1 w/ tokens, but all of my 2 legged OAuth 1 attempts have failed. I have tried including xoauth_requestor_id and it has not had an effect.
There is some hinting in the docs that OAuth1 w/ tokens may be required, but I was hoping to confirm that that is the case.
For example the docs say: "If your application has certain unusual authorization requirements, such as logging in at the same time as requesting data access (hybrid) or domain-wide delegation of authority (2LO), then you cannot currently use OAuth 2.0 tokens. In such cases, you must instead use OAuth 1.0 tokens and an API key."
It seems clear there that "tokens" are referenced, however the word "token" is also used to describe the Authorization request header, so it is less clear that this means OAuth1 request tokens.
Any help is greatly appreciated. Thanks!
The section you are referring to doesn't seem up to date. You can have domain-wide delegation of authority using OAuth 2.0. It's called Service Account. Once authenticated, you do exactly the same that you used to do with 2-legged OAuth 1.0.
Here are the steps you need to get started:
Go to Google Developer Console
Create a project if you don't already have one
Go to APIs & auth --> APIs and activate the Admin SDK
Go to APIs & auth --> Credentials and click CREATE NEW CLIENT ID
Select Service Account and click Create Client ID
Download the p12 private key file (and keep it safe !)
Go to your Google Apps Admin Panel
Go to Security --> Advanced Settings --> Manage OAuth Client Access (Direct URL: https://admin.google.com/AdminHome?#OGX:ManageOauthClients)
Enter the Client Id you just created along with the scopes you'll need, separated with commas (In your case, https://www.googleapis.com/auth/email.migration)
Go to your favorite language client library documentation and find how to authenticate using the private key file you downloaded earlier and also impersonate your domain users.
Hope that helps.