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'm running Django on an Apache server on Ubuntu and the activation of a new account via a link in an e-mail fails sometimes. I've checked my access logs and I can see that the activation link is opened by an EC2 server (whois lookup gives an AWS resource, IP is not the public IP of my own server). Any ideas who/what this could be? I have TLS enabled in settings.py for sending emails: EMAIL_USE_TLS = True.
So the reason for failing the activiation is because the link is already openend, but I'm worried what happens there. I've seen this happening 3 times with completely different user agents for 3 completely different account-activations but from the same IP address.
The first thing that came to my mind is that maybe an e-mail client is opening the links to generate a preview? Like, to show a screenshot when the user hovers the link.
Why do you make links usable once? You can use a token that is valid until the account is actually activated (and disable the link if the account is not activated for a certain amount of time).
I am attempting to connect to the Google Analytics API using Matillion ETL on an AWS EC2 instance in an effort to load a data lake.
When I try to add the callback URL into the Google Developer Console http://ec2-99-99-99-99.compute-1.amazonaws.com/oauth_redirect.html, I get the error:
"Invalid Redirect: domain must be added to the authorized domains list before submitting."
I do have amazonaws.com added to the Authorized Domains on the OAuth Consent screen. If I add, compute-1.amazonaws.com/oauth_redirect.html, it accepts it. So I know it's recognizing amazonaws.com, but not for my specific EC2 instance
I was thinking it was because it's a sub-sub-domain, but I'm not sure if that matters. Based on other posts such as this other people have been able to connect.
I've also tried adding a new record set in Route 53 instead of the AWS provided URL, but I don't know how to change the default callback URL in Matillion. I've sent their support team a separate question about that, and will let you know if that resolves it.
I do think this is a problem on the Google side that should resolve it though. Could there be some setting in the Google console that I'm missing to allow this?
Edit: Using the Route 53 URL instead when signing into Matillion will force the OAuth config to use that instead when getting the callback URL. I'm able to connect to Google Analytics now. I will leave this post up in case anyone else runs into the subdomain.subdomain.domain.com issue with Google
As suggested in https://stackoverflow.com/a/36112649:
You can use free DNS by http://xip.io/. So for IP 99.99.99.99 use
http://99.99.99.99.xip.io/callback. And it would be resolved to
http://99.99.99.99/callback.
Further, make sure the redirect URI in the .env file or other similar configuration in AWS is set to http://99.99.99.99.xip.io/callback.
I'm doing PoC of some GSuite custom solution which needs to listen to changes on users resource. I've created a GSuite account, linked it (and verified) with mytestdomain.com. It's also verified in API console. Basically followed instructions from https://developers.google.com/admin-sdk/directory/v1/guides/push
and fulfilled all requirements from there.
Unfortunately when I try to register my web hook I'm getting following error:
Watch request denied by backend [403]
Errors [
Message[Watch request denied by backend] Location[ - ] Reason[watchDenied] Domain[push]
]
I stuck with it and don't know where too look for more details about that error.
I'm using a certificate generated by Let's encrypt, but tested it with https://www.ssllabs.com/ssltest/ and got rank A. How to check if Google API treats Let's Encrypt as trusted CA?
Problem wasn't anyhow related to Let's Encrypt certificates. They're working just fine with Google's push notifications. I've contacted with Google support and with their help I've established that sending a request with showDeleted parameter set to true was a root cause of above problem.
Support guy claimed that documentation was copied from list method and that parameter cannot be used with watch method and they're going to update docs of watch method in API reference. (However it's still there).
Have took 2 day, can't find a good method.
1.AWS Linux instance have pre-install sendmail, I only need to send out email. But don't how to configure sendmail and other package.
2.Try to use AWS SES, however it needs to verify domain, which means I need to deal with AWS Router 53. After reading very complicated document and "create hosted zone", the AWS SES domain verification still "pending" after 24 hours. I am guessing maybe the default EIP domain name, like "ec2-***-amazonaws.com" is not a qualified/Registered domainn ?
As a newbie for SMTP setting, really don't know what to do? Since even if using a free mail server, it seems still need to 'verify domain', if aws default domain name "ec2-***-amazonaws.com" is invalid, how can I pass the domain verification?
By the way, since sendmail is pre-install, and this website is very simple, small group used, how to set configuration and other package to do email server on this instance itself?
Any suggestion is appreciated!
Thank you
It's much easier if you configure email from your Django app directly to a third party email provider, effectively by-passing the local sendmail configuration altogether. Trying to set up an email connection to AWS/SES on the server itself is also a pain, it's also much easier to configure the Django app to connect directly to AWS/SES
You have three very popular choices to setup email from Django:
Set up a connection to Gmail/Google apps .- If you'll be sending a lot of email volume I wouldn't recommend this option, because they block you easily if you use it to relay a lot of email.
Set up a connection to AWS/SES.- You mention you already tried this, but now try to set the connection inside Django using the Python packages boto and django-ses, this will make the email setup much easier. In addition, boto is also useful if you plan to use some other AWS service like S3.
Set up a connection to Mandrill.- This is another provider, not as big as Google or AWS, but they provide good service with decent free email volume and you can also set up a connection directly from Django.
Take a look at this article -- which I wrote -- that describes all the set up steps for all three providers in detail:
http://www.webforefront.com/django/setupdjangoemail.html