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.
Related
I have added these 2 identity providers (refer attached images) to Google Cloud -->Identity Platform
Email/Password
OIDC Connect (oidc provider)
Now if you see there is a User section as well under Identity Platform
So I have added some random users which are non gmail users (refer image), like xyz#abc.com, which I want to authenticate with the help of Google Cloud (it when this user comes to login, I will hit API endpoint /login and in login server side code, I will redirect to Google Cloud to Authenticate this user using OIDC Authorization flow)
I need Java code to :
Using some java code, First choose the provider as OIDC provider (oidc-auth-provider).
Make call to Google Cloud which should use this Provider (oidc-auth-provider)
This oidc-auth-provider should look up the users which I have created under Users section (refer image)
Google Cloud after verifying user exist, should send back with Auth Code
using Auth Code I will call back to Google and get ID token/JWT token
I was referring to this link :
https://cloud.google.com/identity-platform/docs/web/oidc
If you search "Signing in users with OAuth" this section on page, that is what exactly I am looking for, but the problem is it has given a UI code example using Firebase API example, to create OAuthProvider instance (which will choose provider), but I need server side code example instead, I am not sure if I can use this Firebase API on server side java code for a web application? Any suggestion that how can I do similar things from a server side Java code?
added Providers under Identity-platform
Added users manually which I wanted to authenticate
I have created a new project in Google cloud console to experiment with Google OAuth flows. I have therefore set up OAuth web app client credentials using
APIs & Services -> Credentials -> Create Credentials -> OAuth Client ID -> Web Application
I want to be able to experiment with postman to request authorisation codes, access/refresh tokens etc. Once in the Create OAuth client ID I therefore add a postman callback URI (https://oauth.pstmn.io/v1/callback) to the credentials' Authorised Redirect URIs as described here. However when I click CREATE at the bottom of the Create OAuth client ID screen, the screen does not update and just keeps spinning. I have waited for over 20 mins but to no avail. Is this a callback URI validation problem such that Google won't allow me to add this redirect URI to the credentials? I have tried to add the domain oauth.pstmn.io to the authorised domains in the project settings but to no avail. When I don't include the redirect URI, the credentials are created with no problem and I am returned to the main APIs & Services -> Credentials screen.
The user that I am using to make these changes owns the project and therefore I do not suspect it is a Google user permissions issue. I have also added the minimum number of fields (project name and support email) to the OAuth consent screen settings. I have also tried this whole process logged in on a different machine.
It seems that at least one api scope needs to be added to OAuth consent screen->Scopes before you set a redirect URI. This video explains the entire setup.
https://documenter.getpostman.com/view/8296678/TzXtGzS2
you can use this public collection to learn more about how to set up auth token for google APIs
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 building an AspNet Core 2.1 website using Azure AD B2C authentication, based on the example code I found here.
I can authenticate against the Google identity provider. But instead of showing a custom page based on the attributes I selected for the signup/signin policy in the Azure AD B2C portal, all I get is the normal Google authentication page asking me which Google account I want to authenticate against.
I was able to display a custom page listing all the attributes I'd defined in an earlier version of my project, which used the deprecated microsoftonline.com domain. But now that I'm using the recommended b2clogin.com domain the page is no longer appearing. I don't know if that change has anything to do with the missing page, but I thought I'd mention it.
My appsettings.json file is:
{
"AzureADB2C": {
"ApiScopes": "https://ridemonitor.onmicrosoft.com/api/user.read",
"ApiUrl": "https://ridemonitor.azurewebsites.net/hello",
"CallbackPath": "/signin-oidc",
"ClientId": "**redacted**",
"Domain": "ridemonitor.onmicrosoft.com",
"EditProfilePolicyId": "b2c_1_ProfileEditing",
"Instance": "https://ridemonitor.b2clogin.com/tfp",
"RedirectUri": "https://localhost:44305/signin-oidc",
"ResetPasswordPolicyId": "b2c_1_PWReset",
"SignUpSignInPolicyId": "b2c_1_SignUpIn"
},
"Logging": {
"LogLevel": {
"Default": "Warning"
}
},
"AllowedHosts": "*"
}
Update
I've configured two identity providers for my app, Google and Microsoft Account. The Microsoft Account provider does, in fact, display a customized page listing all the attributes I set in the Azure AD B2C portal when I authenticate it. It's just the Google route which has stopped displaying the custom attribute page.
The redirect uri in Google Cloud Platform -> Credentials is:
https://ridemonitor.b2clogin.com/ridemonitor.onmicrosoft.com/oauth2/authresp
which is the url I should be sent to, and used to be sent to by the Google identity provider, and is the url the Microsoft Account identity provider sends me to when I try to log in.
It looks like I need to update something in my Google configuration, but I'm not sure what.
Update #2
Using the Chrome developer's console, and Link Redirect Trace, I tried to see how I ended up on the pages I ended up on after clicking both the Google and Microsoft Account signin/signup links.
The Google button lands me on the generic Google login page. The initial redirect (there are several subsequent ones) appears to be:
https://accounts.google.com/signin/oauth?client_id=769952297467-qhqd9brt7pl4sra1hnjhnnqchce2h6f1.apps.googleusercontent.com&as=c-8m6tr-h2tUDpRHqIApkQ&destination=https://ridemonitor.b2clogin.com&approval_state=!ChR4aFltdld5TGNwWUEyUlA1R0R6TRIfczBDdExlN01TRElYa013TWpqbVNUV1h5alREUVloWQ%E2%88%99ANKMe1QAAAAAW7K6uQbexonsHodkbBOebSymUYB1yufO&oauthgdpr=1&xsrfsig=AHgIfE8msp705-PG2II5uHWqjoODqYSLPg
The initial redirect for the Microsoft Account button is:
https://login.live.com/oauth20_authorize.srf?client_id=704398a8-908a-4512-9cc0-4453014b4714&redirect_uri=https%3a%2f%2fridemonitor.b2clogin.com%2fridemonitor.onmicrosoft.com%2foauth2%2fauthresp&response_type=code&scope=openid+profile+email&response_mode=form_post&nonce=TQsICDEyv245x1E4pkQynQ%3d%3d&state=StateProperties%3deyJTSUQiOiJ4LW1zLWNwaW0tcmM6ZjBlYmQ4OTUtNmVjYS00NzBhLWE4ZDYtY2U4NTgyYzFmZmNjIiwiVElEIjoiNzIwZDg5NDEtNmM2Zi00YzIzLWI5MWEtZDMyZjJjODA5Yjk4In0
Comparing the two initial redirects, what's interesting is that the one for Google does not contain a parameter for the redirect_uri. Which I presume is the place the browser should be sent after a successful authentication.
Yet my Google credentials page would appear to be set up correctly:
Or am I maybe not configuring stuff in the right part of the Google ecosystem? I thought I was following some Microsoft directions regarding Google credentials, but...
Do you get any error messages?
Try using your browser's dev tools to check any error logs and identify the CSS styling that took effect in your html elements. It's possible that your custom classes are being those overwritten by the Google default styling.
You can edit the CSS within your browser's dev tools and then update the CSS files in Azure Blob Storage when you are happy with them.
Refer also to this thread and this one to see if these issue might be similar to yours.
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.