I've read some related questions, but they are not 100% related, as the requirements vary a bit.
I have a .NET5 web application, some kind of custom CRM for the company I work in.
We have multiple users (employees, my colleagues), which can create quotations, etc.
Also, they can send these quotations to customers. Every user has its email account name attached to it.
The current way this application works is that I've created and enabled Gmail API for each email account, and authorized it, by myself, manually.
The problem is that every time we need to add a new user (new employee for instance) - I need to enable Gmail API of his email account (company's one, but it doesn't matter), add the credential file and token manually to the server, authenticate it, and only then - the application can use the email.
I know that there are many sites (like Monday, etc) - that have automations and integrations with Gmail, and any time I want some integration - I get notified with the OAuth screen, and approve it. I want the same thing in my application.
I understand that I have to create some kind on "Gmail global credential", which will be "added" with account tokens or something like that (every app user will oauth and allow access)?
Just can't find the correct documentation for it.
My backend is written in Blazor Server, .NET5.
I would appreciate if one could explain the main stages of this procedure.
Thanks!
Related
I have a Windows Service which currently sends emails of office 365 users using their email and password via the older smtp method.
Microsoft is turning this ability off very soon.
Currently I use mailkit and c# within a windows service
The only details I have are the users smtp username and password
My app has no user interaction ability as it runs on another box
I have read many ways about how to send email with oauth2 and ms and it seems a lot of people do it differently, and their is no clear path. I have seen such as using ms azure registered applications and different azure library's.
So my question is, what is the easiest route to take regarding a new non user inactive service being able to still send email on behalf of a user.
Most of the users I deal with are not able to setup up azure and it's products as their are small companies with limited it support.
I feel like I have perhaps gone down the wrong path of trying to use azure graph
So what is the correct, most similar to smtp and simple route to recreate a simple email sending windows service using c#
Thank you for your time in reading this
As far as I know Microsoft usually recommends the use of the GraphApi for this stuff.
The preferred way would be to use delegated permissions, i.e. your application has the permission to send an email in the name of the logged in user. If I understood you correctly that is not an option for you because you want to send the mails from a non-interactive background service.
That means that you application itself needs the permission to send an email in any users name. Obviously this is a much broader permission and you should think about if you really want to do it this way. Also, if you are in some kind of corporate context, you might also have to involve and get consent from the data protection officer or the like.
On the technical side such a permission is called an "application permission" thus you need the Mail.Send application permission which requires admin consent i.e. not the individual users of your application decide if they what to give you permission to send mail in their name (this would be delegate permissions) but an AAD admin has to consent for all of them at once.
See https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0&tabs=http#permissions
and https://learn.microsoft.com/en-us/graph/permissions-reference#application-permissions-38
I'm trying to create a program that sends messages to groups from time to time. If I'm not mistaken, the only API I see that send messages is "Create Post" which is the "Team Messaging" section. This API uses Glip permission. The test messages that I was sending is being sent to the developer Glip-App account, when I logged into the Glip-App account, the page didn't look like the regular RingCentral app. The UI is different. I have a feeling, that I am working on the wrong API.
I also have few more questions. My program is only required to send messages, but in order to apply for production, I have to practice other API calls as well, such as Get, Delete, Update etc. I'm not sure why it is like that. Also, I had to practice all the permission given, but the only permission I have given is Glip and it's still in the red.
Finally, the test messages that I've sent, showing the user's actual name on the Glip App page. Is there a way that I can use an alias?
The test messages that I was sending is being sent to the developer Glip-App account, when I logged into the Glip-App account, the page didn't look like the regular RingCentral app.
There are two developer sandbox accounts for RC App now, one for the new App and one for the legacy app. At this point, you should be using the new URL. The legacy URL still exists for testing purposes and will be retired at some point in the future at which time the URL should redirect to the new URL.
New: https://app.devtest.ringcentral.com/
Legacy: https://glip-app.devtest.ringcentral.com/
My program is only required to send messages, but in order to apply for production, I have to practice other API calls as well, such as Get, Delete, Update etc. I'm not sure why it is like that. Also, I had to practice all the permission given, but the only permission I have given is Glip and it's still in the red.
This should not be the case. Please contact the support team regarding this.
Finally, the test messages that I've sent, showing the user's actual name on the Glip App page. Is there a way that I can use an alias?
If you are posting using the credentials of a user, the user's name will show up since the user is being represented, not an app. You can also post into a team using a webhook or chatbot in which case other names will appear.
While developing an on-premise, intranet-only REST API server for my company, I managed to completely confuse myself regarding authentication issues.
I have:
A REST web server implemented in C#, using self-hosted Nancy, running as a Windows Service
A C# client that can query the server, run by a user in our company
I do not have:
Any form of access to our Active Directory and/or domain controller, apart from what any application running under Windows normally has
Any way to influence AD settings or configuration
Active Directory Federation Services (ADFS) (I think. We use Windows 7 and Office 2010, just to give some perspective on the state of the software landscape)
Azure Active Directory (AAD)
I want:
A way for the server to authenticate that a request is made by a user of our company
It is perfectly fine if the client has to sent some additional authentication data with each request, as long as it does not contain the user's password in any form
I do not want to:
Have to set up any additional software (my server must be minimum configuration and maintenance, so the average user can install and run it)
Install / configure / maintain an IIS server (see above)
Use ASP.net (way too big for my needs, plus see above point(s))
Handle user passwords in any way (company policy and common sense)
Impersonate the user (I only need to validate the authenticity of the request)
Implement my own user account database. We already have half a dozen services that need their own username/password combinations, I do not want to add yet another one
I have read articles that show how to use Windows authentication with IIS, or how to use Azure Active Directory (AAD) with Nancy. Other questions here have already informed me how to authenticate username / password combinations against the Active Directory. However, none of these satisfy all of my requirements or have requirements of their own (like AAD/ADFS) that I cannot meet.
It seems that Kerberos/SSPI might be what I want, but it seems very involved and quite complicated to get working with C#. It is possible I will have to go this route, but I could really benefit from some minimal working example (the accepted answer provides a C# implementation/wrapper, including an example project, but I can't seem to be able to make heads or tails of it).
Maybe I am naive, but what I image the solution to be is something along the following lines:
The client queries a service (AD, Domain controller, ...?) for some form of authentication token, using the credentials of the currently logged in user
The token is then sent to the server together with the username, as part of the request that needs to be authenticated
The server extracts the token, and queries the same service (AD, Domain controller, ...) whether the token is authentic, valid and belongs to the user in question
Is this possible at all? Ideally, with some sort of ready made library that I can plug in to my projects (I'm reaching, I know)?
You can do this with stateless authentication and Jwt. Send a username and password to "/ auth" (example) and "/ auth" will search the AD (example) and validate if the user exists, then create a Jwt token with the name of the user on load. When you make a request, you will only send a Jwt token and Nancy validates the token.
We have an application which we need to allow users from our customer's systems to be able to sign in without seeing another log in screen.
What is the best way to provide an SSO type experience for our customers? I have tried to research Azure ACS and Windows Identity Framework but they all seem to be based on this idea of a common log in popup/screen which all sites use. Unless there is another aspect to this federated identity system I don't think that will work for us. Basically our customers are education institution which have students who sign in and use their own web applications/portals. These customers purchase access to our application and want their students to be able to click a link from their portal and automatically sign into our system.
From looking around it seems important to know that these systems are running on completely separate domains. For some legacy systems we have asked our customer to provide simple api endpoints for a very custom sso implementation. What I'm looking for is any information about a more standard approach for SSO.
SAML 2.0 is the standard for single-signon. Your clients would need to have some authentication mechanism on their sites that can be translated into a SAML call to your application.
When they sign the student on, they should make a quick call to your application, passing you the username of whoever is logged in. In return, you generate a token, store it in a DB along with the username, and send them the token. They append that token to any link to your app in GET form, and it "uses up" the token (removes it from the DB) but signs them in to that account.
Upon generating the token, you can also remove one "credit" from that applications allowed requests, or whatever else you want to do there.
Our specific needs required us to roll our own SSO type system using some simple secret token handshakes.
Say I have 3 google accounts and 3 facebook accounts and want to an webapp for viewing the inbox / events for all 3 accounts together. Would that be possible?
I can think of the following options:
Using the javascript api's only. (Don't know if it would be possible to have multiple users authenticated at same browse session or switch between the users without reentering passwords?)
Merge the inboxes / events on server using some c# api for gmail and facebook. Would those api require a browser session, or would it be possible to store some sort of a authentication token?
Thanks a lot for any suggestion!
Larsi
It is definietly possible to do that with Facebook by using its OAuth authenitcation and corresponding service calls to retrive data. I don't know if gmail supports something like this.
Facebook API/Auth reference: http://developers.facebook.com/docs/authentication/. Note that you'll either have to call services yourself or have one application Id per account you want to pull data for as library provided by Facebook stores user information in cookies named with application Id as prefix.
You need two separate browser sessions, possibly storing cookies in different places (if you want to remember who's logged in) to be logged in to these websites as two users at the same time. Some of them will even free up sessions by examining the IP address; if the same IP has two or more open sessions, all but the youngest are discarded.
The idea is, a computer is used by one person, and that person is supposed to be one user and interact with the web app in one session. That allows for the best overall use of resources. There are very simple ways to enforce this server-side, that are hard to "game" client-side.