I want to be able to retrieve emails from a gmail inbox but I cant find a way to properly authenticate in a server environment. Traditional authentication uses this: https://developers.google.com/identity/protocols/oauth2 however I don't have access to a web browser with javascript within a server environment so I cant authenticate. A service account wont work because I wont be able to access inbox of my main email address through it. Thanks.
The best solution I could find is to create the authentication tokens on computer then use a shell script to automate the transfer of the files over ssh onto the server.
If you have the permission to temporarily open a port on the server, then you can use the built-in authentication server:
flow = InstalledAppFlow.from_client_secrets_file(client_secret_file, scopes)
cred = flow.run_local_server(open_browser=False, port=port)
By setting open_browser to False the script is going to print the url to the command line, you can then open the link locally in your web browser and after the successful authentication you Google is going to redirect you with your token to the websever running on your server. You can see this functionality in action in a script I use to sort my email using machine learning.
Related
The problem: I'm getting errors from Google while attempting SSO through Azure AD and can't even begin to guess why or how to go about debugging the issue.
The story:
My org is looking at leveraging Microsoft's nonprofit benefits by setting up Azure for web hosting and Sharepoint to start with, which also entails using Active Directory. As it stands right now, we've successfully gotten our website running and accessible to the world on our custom domain, and our AD is populated with a copy of what's in our Google Workspace directory so we can use Active Directory as our authoritative directory.
We've been trying to implement SSO with the Azure/Gsuite connector, to have them auth with their Azure credentials to get into GMail, Docs, Drive, etc, but Google Workspace seems to choke. I have gone over the setup instructions repeatedly, ensured we're using all of the proper URLs in the Connector's SAML settings and in Workspace's "SSO with third party IDPs" settings, the proper certificate is in place... Provisioning is set up but not active, and I have successfully provision-on-demanded my account and an unprivileged test account.
Here are my settings in Azure:
Here are my settings in Google:
And to test this here's what I've done:
I open up a fresh InPrivate/Incognito window.
I go to https://myapplications.microsoft.com/ and am prompted to login. I use my unprivileged test account credentials.
Upon auth I click on the Connector app to attempt to go to my Gmail inbox.
After a wait on a white screen, I get a Google error screen with "Invalid Email - We are unable to process your request at this time, please try again later."
If I disable the SSO settings for my org in Google Admin, I'm able to log into the account just fine with Google, get to the gmail inbox, etc.
Conversely, if I attempt the same steps with my admin account, I get a similar page with a slightly different message, "Server Error - We are unable to process your request at this time, please try again later."
I have been bashing my head against this for two whole nights and can't make any headway. What gives? I can't even figure out how to debug these errors.
Somebody (me) failed their perception check repeatedly because the problem was that the Unique User Identifier SAML claim in Azure was set to user.mail instead of user.userprincipalname as it should have been as per the tutorial.
I'll see myself out now.
Sorry that my question might be repetitive but none of the solutions provided in other links have resolved my issue. Below is my situation
We have ASP.NET Core 3.1 Web application to which we are trying to use Azure AD so that users can login with our Enterprise Credentials. We started with ASP.CRORE MVC default template and enabled to Use Organization credentials and Authentication is working in our Local environment. We are now trying to deploy this app to other internal environments. So we have deployed this to two of our internal servers and configured IIS to refer this website with http IP's assigned. I was able to create Azure App registry for this application and was able to add the http IP's through Manifest, added the clientId to the appsettings.json file and the authentication is working if we refer the website using the http IP's. I have also tried by assigning https IP's assigned to the same websites and added them to Azure App Registry and again the authentication is still working if we refer the website with either of the 2 https IP's.
Now we have decided to create URL something like https://ourwebsitename.companyname.com which resolves to either of the http IP's using F5 Load balancer. I was able to add the URL to the azure app registry and using the same clientId in appsettings.json in the same way how the app is working with http or https IPs. But somehow when we refer the website URL
https://ourwebsitename.companyname.com we are getting the error as mentioned in the title of the question and I did observed after I hit the URL, its getting redirected as redirect_uri=httpXXXX instead of https which I thought may be the reason of the issue but unable to resolve. I have googled it and tried with various solutions but none resolved and so I am posing it again hoping for a luck if someone can provide me a solution.
Following are the links which appeared close to my situation but didn't work for me
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-5.0
https://github.com/AzureAD/microsoft-identity-web/issues/115
Thanks in advance.
I looked at the sample you provided, and it does not provide the redirect_ url key in appsettings.json. So, based on my experience, it should have a built-in redirect_ url. Otherwise, the aadsts50011 error will not be reported.
To deal with this kind of problem, you can try a general solution:
When you visit the application url , you will be redirected to the login page. Decode the authorization request url, you will find redirect_url, copy the value of redirect_url and paste it into the azure portal, and try again.
For the redirect URL, it should start with https, if you need to start with http, you must configure it as http://localhost.
I have a React app that needs to communicate with several AWS services, each requiring secret keys and I know that I should not hard-code them into the JS.
I found this:
How do I hide API key in create-react-app?
Which basically confirms the following:
* Do not store true secrets in your JS
* Do not use env files either, because they are added to the JS at compile time.
* Use server-side code to deal with secret server-to-server communications, i.e. use a proxy
But my question is now one of clarity on this or "next step". My proxy server now handles all of the private communications with AWS. However, how do I confirm my app's identity to the server? In other words, if open the proxy up, anyone will have access to my AWS content. However, my actual users are not authorized to access my external services directly, so I can't just pass through those credentials.
My idea is to set up an application ID that will redirect only to the associated URL, but is that secure enough? The appID is in the JS, but the ID will only allow the proxy to send information back to the URL on record.
Thank you,
Wayne
I think your best bet would be to use AWS Cognito.
Users will auth with it, get back a token which can have IAM access rights attached to it if that is what you desire
Our customers want to send emails from our java appengine application using their email accounts, with their smtp servers. Is that possible? Verifying all their email addresses in appengine is NOT an option. Would it be possible to send email from an appengine application using an external SMTP server?
Thank you very much.
No, there's no way for an App Engine app to make a connection to an external SMTP server. If you want to do this, you'll need to find or build a webservice that sends email via an HTTP-based interface.
It's possibly to do today, but requires some indirection. If they set up a web form (cgi script, web app , whatever) that forwards to their SMTP server (after making the appropriate authentication checks, of course), then it's a simple matter for an App Engine app to make a POST.
I'm plan on deploy a Java application to Google AppEngine and use federated login (still experimental according to Google). The application is pretty simple Java EE application which expose RESTful interface for simple CRUD operations.
I then want to be able to authenticate to this application using Windows Client Application written in C#.
I think the application should be able to open a window with a browser in ti which will present the login page of my web application and after successful authentication I should be able to get the login token or a cookie to use in the rest of my HTTP requests.
Is it possible to do such thing using federated login? I've found a post explain how to do it using google proprietary login.
Thank you,
Ido.
I've manage to make this work much easier then I thought it would be.
When I send HTTP request to my web service I get 302 Found response with response header name Location which point to the login page.
I use WebBrowser control, register to it Navigated even and navigate to the URL in the Location header.
When the Navigated even fire I use the code from this answer to get the cookies container.
I check each cookie until I find one with the name ACSID and store it.
For every web request to my service I add cookie name ACSID with the value saved at step 4.
This is not the most secure way of doing this. I will add check for the domain of the cookie but this looks good.