So there are actually two web services involved,
1) SP 2013 executing a web service which reaches out to data from a SQL Server DB
2) ASP.Net page executing a web service that reaches out to data from SP2013 (like items in a list).
1 seems feasible I think because SP2013 authenticates users at the AD level and the service would execute as the user. If the DB allows read access to all there should be no issue, right?
2 I'm not sure about. Would the service be executed as something like "ASPNET USER" or "NETWORK SERVICE" or something that's not the user account? Meaning the service would get access denied because "ASPNET USER" doesn't have access to the SP site/etc.
Yes, you can consume data from SharePoint 2013 in your ASP.Net application or in any other platform. But instead of creating a new web service to make it (avoid querying the SharePoint SQL Server database directly), you could use the native SharePoint web services.
To consume data in lists, libraries, etc from your portal you can use the lists.asmx web service with the GetListItems method.
When you call the GetListItems method, you can identify the user credentials:
myListsService.Credentials = new System.Net.NetworkCredential("user",
"password",
"domain");
See this link: http://msdn.microsoft.com/en-us/library/lists.lists.getlistitems(v=office.12).aspx
How to return List Items: http://msdn.microsoft.com/en-us/library/office/ms429658(v=office.14).aspx
Related
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 am working on application whose details are as follows:
Its 3 tier architecture. Web Tier (ASP.Net MVC) -- Service Tier (ASP.Net WebApi 2) -- Database Tier(MS SQL 2014).
Application will also have native mobile apps as clients which will consume Service tier.
Service Tier (Web API) uses individual username/password in conjunction with OAuth for authentication and authorization.
User details are stored using ASP. Net Identity system. ASP. Net Identity database tables are in same database as that of application database.
There will be no direct calls from clients i.e. web or mobile apps to database and every request has to go via service layer.
Users of web client and mobile apps will be authenticated against asp.net identity database which is part of application database.
I have partially implemented above architecture however facing one challenge i.e. once user is authenticated, OAuth token will be issued from service layer which will be valid for one day. But how and where should I securely store this token in Web Client (ASP.Net MVC app) so that user needs to login only once in day and not for every single request that it makes.
One option I can think of is once user is authenticated and token is received in web client then store it in in-memory session storage and use it for further requests. However down side of this is, it will reduce scalability of application and will require sticky sessions in load balanced environment.
Is there any better way I can handle this situation? Also want to validate above architecture if its correct architecture?
i'd like to recieve comments on the way i'm trying to build an asp.net web application which uses a WCF service that is hosted in another asp.net application. Both applications will live on the same machine, but the app with the WCF service will not be accessible from the outside. there will be two web servers sharing the load behind a load balancer.
The app pool of both applications will use the same local user account (web server is not part of a domain) and so i was thinking to use WsHttpBinding with windows security for communication between client and internal wcf service.
The fron-end asp.net app uses forms authentication through a custom membership/role provider to athenticate and authorize users. The user database is in a sql server database.
i need to somehow pass to the wcf service the user details (username + roles) so that in the wcf it will be possible to validate and authorize according to the roles of who is logged in the front-end. I read i need to use "support tokens", but i haven't figured out how to use this.
I read also something about claims and WIF, which seems interesting but have no idea how i could use these in my scenario.
is there anyone who can give me recommendations about the architecture and maybe also show me how to pass the username to the wcf service and also show me if possible to use claims based authorization?
First of all, if both servers are behind the corporate firewall on a corporate LAN, I would strongly suggest using netTcpBinding instead of any http based binding. NetTcpBinding is much faster due to encoding the message in a binary format.
As for username / password: your ASP.NET front-end server could set the client credentials for the user calling for the WCF service - after all, the ASP.NET servers do have access to the ASP.NET membership database, don't they?
Or if you cannot pass on the user's credentials, you could pass on some headers to your WCF service that would describe the user - actually, you probably only ever need the user's unique ID - since the WCF service could fish out the rest of the info from the ASP.NET user database again, if really needed.
As for claims - I don't think they'd be a good idea here - you don't really have to deal with a multitude of different authorization schemes, and you're not using any federation (e.g. allowing users from a different company or domain to use your services) - so those obvious benefits probably won't really be applicable to your case.
I have inherited a conventional three tier web app with ASP.net 2.0 for the UI, .Net web services (ASMX) in the middle tier and SQL Server 2005 for the DB. This is currently an intranet application with the only users being company employees. Currently the application uses Active Directory (AD) authentication.
At the login screen, the user is presented with username / password dialog. The middle tier makes a simple call to the AD to check the username / password. If ok, then a sessionId guid is generated and sent back to the UI. This sessionId is then passed on every subsequent call from the UI within the session. All methods in the middle tier first check the validity of the sessionID against a simple session table in SQL Server, before processing the request.
I now need to make the web services middle tier of the application available to a new UI that will be available to the public internet. I don't need to worry about authentication because that will be managed by the new UI. However, I don't want to leave the web services completely open without any security. I just want to be sure that the system calling the services has permission to do so. I don't want to burden the new UI with having to maintain the sessionIds currently used.
Any views on the best way to secure the services when being called from the new UI? I guess I could use x509 certificates but I've done this before so I'm not aware of any disadvantages (performance?) or how to go about the implementation.
The new UI has been developed used .Net 3.5. We can install .Net 3.5 on the middle tier so I guess we could benefit from using WCF?
I don't believe this is a problem that is suited for cryptography. It would be better to limit access to your web service using an IP restriction. If this data is being transfered over an insecure connection like the open internet, then you could use ssl to verify the client and server as well as keep the transmitted data safe. You could also use VPN which is probably the easiest to implement.
I am concerned with your session table. I believe this introduces a lag time for revoking user accounts. If this session doesn't have an expire time then it would make it impossible to revoke a user account. After a user has logged in how do you kick them off?
One solution is to have the ASMX web service query active directory for each request, if your AD server isn't under a heavy load then this should be fine. Keep in mind that AD is a very efferent database in its own right.
If I have an application (on C#) that runs under a user context (ex. DOMAIN\StandardUser) which makes a call to a Web Service, which has the web service worker process running under a different context (ex. DOMAIN\WebServiceUser), and that web service connects to a SQL database, which user context does the database connect from, the StandardUser or the WebServiceUser?
Thanks,
use integrated security, so your user context will also use for web service.