I need to get Microsoft outlook details specially calendar & meetings of a person who invokes an ASP.Net web service via Windows authenticated page. Kindly assist how to connect Microsoft outlook calendar to ASP.Net Web Service.
Any given Outlook user's data is not guaranteed to be accessible from a web service or web application. If the user is using POP3 or IMAP account, their data will be stored locally on their PC and cannot be read without installing a custom client application to read their Outlook data and communicate back to your web server.
If they are using an Exchange Mailbox, then you can access that data from your web server via Exchange Web Services - but you'd need to authenticate with their password (or an AD token if you have that already in your web app).
Related
We have a hybrid Active Directory scenario - an on premises Active Directory server synced with an Azure AD tenant.
We are in the process of migrating our on premise Exchange email accounts to 365.
We have a SPA (JavaScript) that displays calendar events retrieved from a dotnet core web API.
The web API only allows access to users in a specific AD group.
The SPA uses the Fetch API to call the web API with credentials.
The web API currently uses EWS to connect to our on premise Exchange server to read calendar events, using its app pool identity.
The above systems have been developed in-house and run on our internal servers.
We want to update the Web API to read calendar events using the MS Graph API, on behalf of the user. We would like to use the simplest available solution.
We have tried to use the AcquireTokenByIntegratedWindowsAuth method but receive the following error: 'Integrated Windows Auth is not supported for managed users'. My limited understanding of why this doesn't work is because we do not have an ADFS on premise.
One of the Microsoft samples shows a SPA acquiring an access token and passing the token in the header as part of the web API call. This would require us to update the SPA and web API code. We're willing to do that if it's the only solution, but I am hoping someone might offer an alternative where we only need to update the web API.
Our client has SQL Server Reporting Service (SSRS) running on-premise in their corporate network. Right now the users access reports by using the standard/native web portal of a report server only from computers connected to their domain controlled corporate network where the SSRS server resides. We are currently building a custom web application that acts as a wrapper for executing SSRS reports. It is a standard ASP.NET Web Forms application and we use the ReportViewer control to display reports. The ASP.NET application is hosted in Azure App Service where we use the built-in authentication and authorization in Azure (sometimes referred to as "Easy Auth"). The SSO authentication uses the Microsoft (ActiveDirectory) identity provider. The problem is that the web application needs to pass network credentials when consuming the SSRS service and executing reports in a ReportViewer. Here is our code which works fine when passing hard-coded credentials to access SSRS:
When using the SSRS web service to pull the list of reports:
ReportingService2010 rs = new ReportingService2010(); rs.Credentials = new NetworkCredential("[USERNAME]", "[PASSWORD]", "[DOMAIN]");
When executing a report in a ReportViewer:
ReportViewer1.ServerReport.ReportServerCredentials = new CustomSSRSCredentials("[USERNAME]", "[PASSWORD]", "[DOMAIN]");
In my last code snippet the CustomSSRSCredentials is a custom class implementing the IReportServerCredentials interface which seems to be a standard practice to pass network credentials through the ReportViewer.
The problem with that approach is that I need to pass particular network credentials – both username and password. In that scenario I need to have a pre-defined service account which will have access to all reports in SSRS, for example.
What I am asking for is if there is any way to call SSRS service/reports on behalf of the currently authenticated user in Azure? The goal to use the authenticated current user when calling SSRS is to allow each user to run only the reports that he or she has been granted to access in the SSRS native portal. Is this possible?
I have a ASP.Net WebAPI service that is used by my AngularJS front end and I am making use of Owin and bearer token.
Now there is a need that we need to install an agent on the few of the client machines (developed in .Net core mostly) that is able to connect to our application and make similar calls. I can create a separate controller for this need, but want to host it in the same website.
How can I create a secure connection between this agent and the ASP.Net server hosted on Azure?
Currently I am looking at generating a Token during the agent installation based on the client MAC address and giving it with each call, but I am checking if there are any better way to address this need.
Any help in this direction is welcome.
Regards
Kiran
It seems that you’d like to enable only valid “agents” that installed on the client machines to communicate with your server, if that is the case, Azure AD provides Native Application to Web API authentication scenario (a native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API that is secured by Azure AD), you could refer to it.
I've got an ASP.NET (.NET 4.0) application that uses Windows Forms Authentication. This authenticates against Active Directory and works just fine.
This web app calls an ASP.NET Web Service(.NET 4.0) on the same server. Both the app and the service are running on IIS 6.
The web service calls a SQL Server 2005 database in the same domain using "Integrated Security=SSPI" as part of the connection string.
I want the web service and the database connection to use the credentials of the logged in user of the web app.
I've tried dozens of combination of settings from dozens of web sites, but nothing has worked. I'm on my second day and haven't gotten anywhere.
Is this even possible?
In my latest attempt, I added this code in the web app before calling the web service:
svc.Credentials = System.Net.CredentialCache.DefaultCredentials;
But inside the service, User.Identity.Name returns the value of the user who started the web server.
What you're trying to do is called "delegation". It means that the end-user is authenticated with the web server, and then the web server tries to use those credentials to gain access to the SQL Server. But the SQL Sever does not trust the web server, it only trusts the domain controller. So the request fails.
Besides not working, delegation has another disadvantage. Because each user would use different credentials, SQL connections would no longer be pooled. Each credential would have its own pool. That would be a major resource hog even at low user counts.
For more information, check out this MSDN article.
TL;DR: Give up on delegation and move to SQL auth.
Inside my ASP.NET application, I would like to add an iframe where I can display the emails from our exchange server for the logged in user. The web application uses forms authentication with custom authentication (passwords are hashed and stored in db).
Is there a way to show OWA within my web app without prompting the user for password (OWA uses windows authentication)? Can I use impersonation in some fashion or establish a trust between my IIS server and the server running OWA?
Has anyone tried this before?
If you are using an iframe for that, then it is a separate process in terms of authentication. Requests from the iframe are sent to OWA server just as you had opened the page in full screen.
However, it is possible to configure your Exchange server to allow windows authentication, see here: http://support.microsoft.com/kb/300656
This way you will authenticate with windows forms authentication to your web application and with windows auth to the OWA server.
I think you would have to have the Windows authentication be the authentication source for the website - or at least map accounts in the website to accounts in OWA
DNN does something a little like this with its Active Directory security provider. Might look at the source of that for some ideas - http://dnnauthad.codeplex.com/