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.
We have gone through the authentication overview but it doesn't answer our question so reaching out to the experts here.
Our web application once loaded on the browser for a user makes requests to our service on Cloud Run. We would like to secure our backend service so only our Domain can access this and not some user using Postman, or a shell script to access / update data.
end-user-access auth
Because the user doesn't have to be always signed in, we would like Cloud Run to respond to the requests, even if there's no auth token present. This eliminates the end-user access to service option for us.
service-to-service auth:
Because it is the browser, and not another service in our GCP platform that's making the request, even this option doesn't work for us.
The user data in our backend is secure, because those end points require Auth tokens, however, pages that don't need auth token are insecure, and could be vulnerable to DDOS or bot/scraping attacks.
How can we secure our Cloud Run service so only calls from our Web Application are responded to and not others?
You can't be sure that the web application is the sender of the request. Indeed, in the web environment, you send your code on the client side. From here, the users (good or bad) can go into your code and understand how it works, what are the header of the request, how these headers are built,...
Complex, and inefficient things can be imagined... Maybe, the best way is to plug an API Gateway and to perform rate limit for the users. Like this, even if the user uses an automated thing, they will be limited. I wrote an article on the Cloud Endpoint Rate limit. Not sure that is the best product for this, maybe Apigee can fit better your requirements.
EDIT
What I would like to say in the first paragraph is "it's not possible with Cloud Run and with any other web technology".
I'm trying to understand the process of login to a website using the Network tab on Google Chrome because I have to use that process for autenticate accounts on an mobile application.
The login is completed when I reach the page "HomepageStudente.do", but I don't understand how to replicate all this on Postman. I've tried to do this:
Right-click on the SSO request
Copy as Curl (bash)
And it seems to work, but when I do the same thing with the second request (POST) I get a different message compared to the one on the Network tab.
Those 3 calls are based on automatic redirect by the browser, and I don't understand how to replicate it on Postaman. Is this possibile to do? Any other suggestion on how to use those requests for authenticate an account outside the website (example mobile app)?.
Thanks
I'm using SoapUI 5.2.1 and accessing a IIS hosted web service on my domain. The web service has windows authentication enabled.
When I browse to the wsdl using internet explorer, it asks for my credentials, then shows the wsdl.
When I do the exact same with soapui, it prompts for my details, then fails and when I check the http log it sayus 'unauthorised: access is denied due to invalid credentials'.
But I'm entering it correctly, I've even tried various permutations of domain\username, username, leaving the domain text box blank or entering it there.
Any ideas?
I needed to provide a lot more info than would fit into a comment...
The other setting that I was referring to is detailed here : https://www.soapui.org/soap-and-wsdl/authenticating-soap-requests.html. If you are sure its windows credentials authentication, then use the NTLM setting. You may have to restart for the settings to take effect.
"Domain – add this for NTLM authentication challenges. If you are authenticating NTLM, make sure to note the following in your configurations:
File > Preferences > HTTP Settings tab > uncheck Authenticate Preemptively preference
for NTLM v2 provide your username as "DOMAIN\USERNAME" or at least as "\USERNAME""
If you still have issues, you can use BURP suite or Fiddler or similar proxy tools for proxy setup. BURP is an extensive security testing tool and may even be an overkill. Fiddler is a proxy. Check out these two links:
Burp : Testing web service with SoapUI and Windows authentication
Fiddler: Using fiddler with Windows Authentication
I'm new to the SSO world and I've recently installed WSO2 Identity Server 5.0 and done my best to hook in a service provider but I just can't seem to figure out how to make SSO happen.
Here is my current situation and goal:
I have a MojoPortal website where a user can log in. From there, the user can click a link to our FTP site powered by GoAnywhere. We want the user to be logged into the FTP site just by clicking the link instead of having to log in to it as well. The FTP site is SAML2 enabled so I chose the WSO2 ID Server to give SSO capabality between my mojoPortal and goAnywhere sites.
Here is what I think needs to happen - sanity checks welcome:
1. User clicks to access the FTP website and my mojoPortal website needs to create a SAML request and send it to the ID server. I can't seem to get a grip on doing this from an ASP.NET page.
2. ID server gets the request and validates it (you can test the request in the "SAML Request Validator" tool in the WSO2 console, right?)
3. ID server sends a response to the GoAnywhere FTP site which can be simulated with the SAML Response Builder tool in the ID server console.
4. The FTP sites says either OK or NO to access.
5. Not sure what happens next - how does the user get redirected to the FTP site.
So I have big issues: I don't understand the flow in great enough detail and I'm also having difficulties in getting the technologies to work together.
Any comments / help at all are greatly apprciated!
MojoPortal website - is this SAML2 Web Browser based SSO supported? If yes, then the solutions is clear.
You just have to register your 2 sites in WSO2 IS as SPs.
Then what will happen is , once the user log-in to the MojoPortal website, he user will have a live login session, therefore once he clicks on the FTP site, he will be able to access it without having to log-in again.
Hope this clarifies your doubts.