WebException using reportviewer - asp.net

I'm trying to connect to ReportingServices through the ASP.NET web ReportViewer control:
rvContract.ProcessingMode = Microsoft.Reporting.WebForms.ProcessingMode.Remote;
rvContract.ServerReport.ReportServerCredentials = new ReportServerCredentials("myUsername", "myNetworkPassword", "DOMAIN");
rvContract.ServerReport.ReportServerUrl = new Uri(ReportConfiguration.ReportServerUrl);
string rptPath = ReportConfiguration.RootPath;
if (!rptPath.EndsWith("/"))
{
rptPath += "/";
}
rvContract.ServerReport.ReportPath = rptPath + "AdminReports/Contract";
List<ReportParameter> reportParams = new List<ReportParameter>();
if (MkoSession.AccountId.HasValue)
{
ReportParameter accountId = new ReportParameter("AccountId", MkoSession.AccountId.Value.ToString());
}
rvContract.ServerReport.SetParameters(reportParams);
rvContract.ShowParameterPrompts = false;
rvContract.ShowZoomControl = false;
rvContract.ServerReport.Refresh();
rvContract.DataBind();
The implementation of the credentials looks like this:
public class ReportServerCredentials : IReportServerCredentials
{
private string _userName;
private string _password;
private string _domain;
public ReportServerCredentials(string userName, string password, string domain)
{
_userName = userName;
_password = password;
_domain = domain;
}
public WindowsIdentity ImpersonationUser
{
get
{
// Use default identity.
return null;
}
}
public ICredentials NetworkCredentials
{
get
{
// Use default identity.
return new NetworkCredential(_userName, _password, _domain);
}
}
public bool GetFormsCredentials(out Cookie authCookie, out string user, out string password, out string authority)
{
// Do not use forms credentials to authenticate.
authCookie = null;
user = null;
password = null;
authority = null;
return false;
}
}
Just hard-coding my credentials while testing. Before check-in, we'll have to create a domain account for this.
I can hit both ReportService2005.asmx and ReportExecution2005.asmx (which is what my ReportServerUrl becomes) no problem through a browser.
When I get to the SetParameters call, I get a WebException. Looking at the headers in the Response within the Exception:
{RSNotAuthenticated: True
RSAuthenticationHeader: .ASPXFORMSAUTH
Content-Length: 206
Cache-Control: private
Content-Type: text/html; charset=utf-8
Date: Tue, 24 Sep 2013 16:15:08 GMT
Location: /ReportServer/logon.aspx?ReturnUrl=%2freportserver%2fReportExecution2005.asmx
Server: Microsoft-HTTPAPI/2.0
X-AspNet-Version: 2.0.50727
}
which seems as if it's telling me that I haven't logged in. If that's the case, how do the exact same credentials allow me to see the web services through a browser?
BTW, I did set breakpoints in each of the methods in my ReportServerCredentials implementation and saw each breakpoint hit. Not sure what that's telling us, but the NetworkCredentials interface returned my network credentials just fine.

I think I might've stumbled into it. In case anyone else is having similar troubles.
First, I poked around and found the reporting services web.config on the server. Saw that it was using authenticaion mode = forms.
So, then I implemented the GetFormsCredentials to return true and pass a generic username. I got this username out of the Users table in the ReportServer database.
No longer getting the WebException, but my ReportViewer isn't displaying either. So, not out of the woods yet, but it seems closer.
FWIW, I think I remember somebody saying we had weird custom forms authentication on our db server. So, for anybody who happens upon this, YMMV. All of that predates me, so I'm not really sure how to check it out.

Related

Windows User getting "access denied" from exchange server

I have a MVC Web Application makes use of Windows Authentication and Exchange Web Services. While in development, this worked great, since the application pool in IIS on my development machine is set to run under my windows user and the Exchange Server is on the same domain.
On the web server, though, all our applications are set to run under a system user that has access to all the database servers etc. The database connection uses Integrated Security, so I cannot impersonate a user over an application level.
I've been trying to impersonate the current windows user through the code as follows:
public abstract class ExchangeServiceImpersonator
{
private static WindowsImpersonationContext _ctx;
public Task<string> CreateMeetingAsync(string from, List<string> to, string subject, string body, string location, DateTime begin, DateTime end)
{
var tcs = new TaskCompletionSource<string>();
EnableImpersonation();
try
{
tcs.TrySetResult(CreateMeetingImpersonated(from, to, subject, body, location, begin, end));
}
catch(Exception e)
{
tcs.TrySetException(e);
}
finally
{
DisableImpersonation();
}
return tcs.Task;
}
public abstract string CreateMeetingImpersonated(string from, List<string> to, string subject, string body, string location, DateTime begin, DateTime end);
private static void EnableImpersonation()
{
WindowsIdentity winId = (WindowsIdentity)HttpContext.Current.User.Identity;
_ctx = winId.Impersonate();
}
private static void DisableImpersonation()
{
if (_ctx != null)
_ctx.Undo();
}
}
Then, the class that implements the abstract methods:
public class ExchangeServiceExtensionsBase : ExchangeServiceImpersonator
{
private ExchangeService _service;
public ExchangeService Service
{
get
{
if (this._service == null)
{
this._service = new ExchangeService(ExchangeVersion.Exchange2013);
this._service.Url = new Uri(WebConfigurationManager.AppSettings["ExchangeServer"]);
this._service.UseDefaultCredentials = true;
}
return this._service;
}
set { return; }
}
public override string CreateMeetingImpersonated(string from, List<string> to, string subject, string body, string location, DateTime begin, DateTime end)
{
//this.Service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, from);
Appointment meeting = new Appointment(Service);
string meetingID = Guid.NewGuid().ToString();
meeting.Subject = subject;
meeting.Body = "<span style=\"font-family:'Century Gothic'\" >" + body.Replace(Environment.NewLine, "<br/>") + "<br/><br/>" +
"<span style=\"color: white;\">Meeting Identifier: " + meetingID + "</span></span><br/><br/>";
meeting.Body.BodyType = BodyType.HTML;
meeting.Start = begin;
meeting.End = end;
meeting.Location = location;
meeting.ReminderMinutesBeforeStart = 60;
foreach (string attendee in to)
{
meeting.RequiredAttendees.Add(attendee);
}
meeting.Save(SendInvitationsMode.SendToAllAndSaveCopy);
return meetingID;
}
}
Then, the methods are accessed as follows:
public static class ExchangeServiceExtensions
{
public static async Task<string> CreateMeetingAsync(string from, List<string> to, string subject, string body, string location, DateTime begin, DateTime end)
{
ExchangeServiceImpersonator serviceImpersonator = new ExchangeServiceExtensionsBase();
return await serviceImpersonator.CreateMeetingAsync(from, to, subject, body, location, begin, end);
}
}
This still works on my local dev machine, but no matter what I do, the user accessing from the server keeps getting an access denied from the exchange server:
The request failed. The remote server returned an error: (401) Unauthorized.
I've tried leaving it on default credentials:
this._service.UseDefaultCredentials = true;
And attempting to manually set the credentials to the current (supposedly impersonated) user:
this._service.Credentials = new WebCredentials(CredentialCache.DefaultNetworkCredentials);
Also, I've tried using the Exchange ImpersonatedUserId object using the email address:
this._service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, from);
which returns the following exception:
The account does not have permission to impersonate the requested user.
By default and as a security measure, Windows will prevent you from delegating your credentials from the web server to Exchange. This means you cannot impersonate the user accessing your web site.
This is known as the "server double hop" scenario. The first "hop" is from the user's machine to the web server, and the second "hop" is from the web server to the Exchange server (Google will give you lots of hits on server double hop).
This is a good thing because it will prevent any hackers from moving around your servers.
The reason it is working on your development machine is that there is only one "hop" from your local web server to the Exchange server.
To solve it you need to allow the web server to delegate the credentials to the Exchange server. This is called Kerberos delegation and must be set up by your system administrator somehow in the Active Directory (which is beyond my knowledge).
I tried to change the AD object setting to Trust this computer for delegation.. (you need AD admin rights) but that didn't solve the problem.
My breakthrough was to set the Identity of the Application Pool (Advanced Settings...) to NetworkService. It worked also with LocalService and LocalSystem, but be careful because they have elevated rights.
What surprised me, that it didn't work with Custom account, when I entered the AD admin account that in reality got all the rights for the exchange system.
general infos about my application:
ASP.CORE 2.1 webservice
Windows Server 2016
IIS 10.0.x
internal corporate network

Basic Authentication with Resteasy client

I'm trying to perform an basic auth to the login-module which runs on my jboss using REST. I already found an StackOverflow topic which explains how to authenticate with credentials.
RESTEasy client framework authentication credentials
This does not work. Analysing the established connection with Wireshark I was not able to see an HTTP package with Authorization: Basic. After more research I found this article, http://docs.jboss.org/resteasy/docs/2.3.3.Final/userguide/html/RESTEasy_Client_Framework.html which describes how to append basic auth to ApacheHttpClient4Executor from resteasy.
// Configure HttpClient to authenticate preemptively
// by prepopulating the authentication data cache.
// 1. Create AuthCache instance
AuthCache authCache = new BasicAuthCache();
// 2. Generate BASIC scheme object and add it to the local auth cache
BasicScheme basicAuth = new BasicScheme();
authCache.put("com.bluemonkeydiamond.sippycups", basicAuth);
// 3. Add AuthCache to the execution context
BasicHttpContext localContext = new BasicHttpContext();
localContext.setAttribute(ClientContext.AUTH_CACHE, authCache);
// 4. Create client executor and proxy
httpClient = new DefaultHttpClient();
ApacheHttpClient4Executor executor = new ApacheHttpClient4Executor(httpClient, localContext);
client = ProxyFactory.create(BookStoreService.class, url, executor);
But this does not work either. There is no description how to append username and passwort for basic auth to the construct. Why is that information not associated with any class from httpcomponent?
One can use org.jboss.resteasy.client.jaxrs.BasicAuthentication which is packaged with resteasy-client 3.x and is meant specifically for basic authentication.
Client client = ClientBuilder.newClient();
ResteasyWebTarget resteasyWebTarget = (ResteasyWebTarget)client.target("http://mywebservice/rest/api");
resteasyWebTarget.register(new BasicAuthentication("username", "passwd"));
You can add a raw authorization header to your REST client by invoking .header(HttpHeaders.AUTHORIZATION, authHeader) in your client configuration.
The credentials must be packed in authorization header in the format of "user:pass", encoded as base64 byte array and then appended to the string "Basic " which identifies basic auth.
This is the whole snippet (inspired by this post on baeldung)
String auth = userName + ":" + password;
byte[] encodedAuth = Base64.encodeBase64(auth.getBytes(Charset.forName("ISO-8859-1")));
String authHeader = "Basic " + new String(encodedAuth);
authToken = restClient.target(restApiUrl + loginPath)
.request()
.accept(MediaType.TEXT_PLAIN)
.header(HttpHeaders.AUTHORIZATION, authHeader)
.get(String.class);
This worked for me in a Resteasy client. For information, when testing this with wget I had to use the --auth-no-challenge flag.
Consider the solution from Adam Bien:
You can attach an ClientRequestFilter to the RESTEasy Client, which adds the Authorization header to the request:
public class Authenticator implements ClientRequestFilter {
private final String user;
private final String password;
public Authenticator(String user, String password) {
this.user = user;
this.password = password;
}
public void filter(ClientRequestContext requestContext) throws IOException {
MultivaluedMap<String, Object> headers = requestContext.getHeaders();
final String basicAuthentication = getBasicAuthentication();
headers.add("Authorization", basicAuthentication);
}
private String getBasicAuthentication() {
String token = this.user + ":" + this.password;
try {
return "Basic " +
DatatypeConverter.printBase64Binary(token.getBytes("UTF-8"));
} catch (UnsupportedEncodingException ex) {
throw new IllegalStateException("Cannot encode with UTF-8", ex);
}
}
}
Client client = ClientBuilder.newClient()
.register(new Authenticator(user, password));
I recently upgraded to resteasy-client:4.0.0.Final to deal with some Jackson upgrade issues, and I noticed that setting headers seem to work differently (I was getting 401: Authorization Errors for every authenticated request that previously worked). I also couldn't find much documentation, (the 4.0.0.Final release is only a month old and has some dependency issues, if my experience is representative of the broader case).
The code previously injected headers into the ClientRequestContext:
public AddAuthHeadersRequestFilter(String username, String password) {
this.username = username;
this.password = password;
}
#Override
public void filter(ClientRequestContext requestContext) throws IOException {
String token = username + ":" + password;
String base64Token = Base64.encodeString(token);
requestContext.getHeaders().add("Authorization", "Basic " + base64Token);
}
}
then we set the filter on the ResteasyClient like so:
ResteasyClient client = new ResteasyClientBuilder()
.sslContext(buildSSLContext())
.hostnameVerifier(buildHostVerifier())
.build();
client.register(new AddAuthHeadersRequestFilter(user, pass));
However, this appears not to set the HeaderDelegate, which is where headers are retrieved in 4.x(?) and possibly earlier versions.
The trick was to register that filter on the ResteasyWebTarget instead of the client in the 4.0.0.Final version (you may notice the clientBuilder works a little differently now too).
ResteasyClient client = (ResteasyClient)ResteasyClientBuilder.newBuilder()
.sslContext(buildSSLContext())
.hostnameVerifier(buildHostVerifier())
.build();
ResteasyWebTarget target = client.target(url);
target.register(new AddAuthHeadersRequestFilter(user, pass));

Report Server Credentials and Missing End Point Exception

Actually what I needed was a step by step guide but anyway..
I have to show some rdl reports in a web-site using the ASP.NET report vievew and do all the necessary configurations for the Reporting Services. The users of the page should not deal with ANY authorization.
Here is my code for the report viewer:
rprtView.ServerReport.ReportServerCredentials = new ReportServerCredentials();
rprtView.ProcessingMode = Microsoft.Reporting.WebForms.ProcessingMode.Remote;
rprtView.ServerReport.ReportServerUrl = new Uri(#"http://mydomain/reports");
rprtView.ServerReport.ReportPath = #"/MyReports/PurchaseOrder";
rprtView.ShowParameterPrompts = false;
ReportParameter[] parameters = new ReportParameter[1];
parameters[0] = new ReportParameter();
parameters[0].Name = "OrderNumber";
parameters[0].Values.Add(orderNumber);
rprtView.ServerReport.SetParameters(parameters);
rprtView.ServerReport.Refresh();
Here is my overload for IReportServerCredentials
public class ReportServerCredentials : IReportServerCredentials
{
public bool GetFormsCredentials(out Cookie authCookie, out string userName, out string password, out string authority)
{
authCookie = null;
userName = password = authority = null;
return false;
}
public WindowsIdentity ImpersonationUser
{
get { return null; }
}
public ICredentials NetworkCredentials
{
get { return new NetworkCredential("myUserName", "myPassword"); }
}
}
I am able to login to "http://mydomain/reports", the default web site of the SSRS, using "myUserName" and "myPassword" (I am not sure if this is related). Still I am getting MissingEndPoint exception at SetParameters() method above. It says:
"The attempt to connect to the report server failed. Check your connection information and that the report server is a compatible version."
I am also responsible for configuring the Reporting Services for the necessary configuration for this scenario and I have heard that this issue is related to the config files in SSRS but I have no idea what to write in them. Any help is much appreciated!
The string provided for rprtView.ServerReport.ReportServerUrl should be for the Report Server service, not the Report Manager application.
Change this:
rprtView.ServerReport.ReportServerUrl = new Uri(#"http://mydomain/reports");
to this:
rprtView.ServerReport.ReportServerUrl = new Uri(#"http://mydomain/reportserver");
This page has some high-level info on the Report Manager interface, Report Server web service, and how they relate.

ASP.NET MVC Authentication Cookie Not Being Retrieved

I am having a hard time implementing "Remember Me" functionality in an MVC application with a custom principal. I have boiled it down to ASP.NET not retrieving the authentication cookie for me. I have included a snapshot below from Google Chrome.
Shows the results of Request.Cookies that is set within the controller action and placed in ViewData for the view to read. Notice that it is missing the .ASPXAUTH cookie
Shows the results from the Chrome developer tools. You can see that .ASPXAUTH is included here.
What may be the issue here? Why does ASP.NET not read this value from the cookie collection?
My application uses a custom IPrincipal. BusinessPrincipalBase is a CSLA object that ust implements IPrincipal. Here is the code for that:
[Serializable()]
public class MoralePrincipal : BusinessPrincipalBase
{
private User _user;
public User User
{
get
{
return _user;
}
}
private MoralePrincipal(IIdentity identity) : base(identity)
{
if (identity is User)
{
_user = (User)identity;
}
}
public override bool Equals(object obj)
{
MoralePrincipal principal = obj as MoralePrincipal;
if (principal != null)
{
if (principal.Identity is User && this.Identity is User)
{
return ((User)principal.Identity).Equals(((User)this.Identity));
}
}
return base.Equals(obj);
}
public override int GetHashCode()
{
return base.GetHashCode();
}
public static bool Login(string username, string password)
{
User identity = User.Fetch(username, password);
if (identity == null || !identity.IsAuthenticated)
{
identity = (User)User.UnauthenicatedIdentity;
}
MoralePrincipal principal = new MoralePrincipal(identity);
Csla.ApplicationContext.User = principal;
Context.Current.User = identity;
return identity != null && identity.IsAuthenticated;
}
public static void Logout()
{
IIdentity identity = User.UnauthenicatedIdentity;
MoralePrincipal principal = new MoralePrincipal(identity);
ApplicationContext.User = principal;
Context.Current.User = identity as User;
}
public override bool IsInRole(string role)
{
if (Context.Current.User == null || Context.Current.Project == null)
{
return false;
}
string userRole = Context.Current.User.GetRole(Context.Current.Project.Id);
return string.Compare(role, userRole, true) == 0;
}
The application also uses a custom membership provider. Here is the code for that.
public class MoraleMembershipProvider : MembershipProvider
{
public override bool ValidateUser(string username, string password)
{
bool result = MoralePrincipal.Login(username, password);
HttpContext.Current.Session["CslaPrincipal"] = ApplicationContext.User;
return result;
}
#region Non-Implemented Properties/Methods
public override string ApplicationName
{
get
{
return "Morale";
}
set
{
throw new NotImplementedException();
}
}
// Everything else just throws a NotImplementedException
#endregion
}
I do not think that any of this is related because the bottom line is that the Request.Cookies does not return the authentication cookie. Is it related to the size of the cookie? I heard there are issues to the size of the cookie.
UPDATE: It seems that the issue revolves around subdomains. This site was being hosted with a subdomain and the cookie domain was left blank. Does anyone have any pointers on how I can get the auth cookie to work with all domains (e.g. http://example.com, http://www.example.com, and http://sub.example.com)?
If you are trying to store the actual User object in the cookie itself, it is probably too big to store as a cookie. I am not too familiar with the MVC authentication stuff, but in web forms I generally do the following:
FormsAuthentication.RedirectFromLoginPage(user_unique_id_here, false);
The second parameter is for the persistency you are looking for.
From there I create a custom context (UserContext) that I populate via HttpModule that gives me access to all the user and role information.
Since I do not develop in MVC (yet) or CSLA, I'm not sure how much more help I can be. If I were you, I would also ditch the custom membership provider. You might as well just call MoralePrincipal.Login directly in your Authentication controller.
The rememberMe stuff should be set by the FormsAuthenticationService (in MVC2) or the FormsAuthentication static class in MVC1, if you're using the 'regular' AccountController's code. If you changed that code, did you remember to add in the (optional) boolean param indicating whether to use a persistent cookie or not?
It sounds to me like you're getting a session cookie, but not a persistent cookie.

SSRS Report Viewer + ASP.NET Credentials 401 Exception

I have a report saved on a SQL2005 reporting server, and I want to return a rendered PDF of this report. I've figured this out when working with a local *.rdlc file (and I've blogged about it), but not when the *.rdl resides on a reporting server. I am getting a 401 Not Authorized error at the line...
reportViewer.ServerReport.SetParameters(reportDefinition.ReportParameters);
Here's the method used to render the report.
public byte[] Render(IReportDefinition reportDefinition)
{
var reportViewer = new ReportViewer();
byte[] renderedReport;
try
{
var credentials = new WindowsImpersonationCredentials();
reportViewer.ServerReport.ReportServerUrl = new Uri("http://myssrsbox", UrlKind.Absolute);
reportViewer.ServerReport.ReportServerCredentials = credentials;
reportViewer.ServerReport.ReportPath = reportDefinition.Path;
// Exception is thrown on the following line...
reportViewer.ServerReport.SetParameters(reportDefinition.ReportParameters);
string mimeType;
string encoding;
string filenameExtension;
string[] streams;
Warning[] warnings;
renderedReport = reportViewer.ServerReport.Render(reportDefinition.OutputType, reportDefinition.DeviceInfo, out mimeType, out encoding, out filenameExtension, out streams, out warnings);
}
catch (Exception ex)
{
// log the error...
throw;
}
finally
{
reportViewer.Dispose();
}
return renderedReport;
}
The other thing that you're missing is the WindowsImpersonationCredentials class.
public class WindowsImpersonationCredentials : IReportServerCredentials
{
public bool GetFormsCredentials(out Cookie authCookie, out string userName, out string password, out string authority)
{
authCookie = null;
userName = password = authority = null;
return false;
}
public WindowsIdentity ImpersonationUser
{
get { return WindowsIdentity.GetCurrent(); }
}
public ICredentials NetworkCredentials
{
get { return null; }
}
public override string ToString()
{
return String.Format("WindowsIdentity: {0} ({1})", this.ImpersonationUser.Name, this.ImpersonationUser.User.Value);
}
}
Other things you may need to know...
This is running on an intranet, and impersonation is turned on.
Logging indicates that the impersonation user is being set correctly.
This does work when running in Visual Studio (http://localhost:devport), and it does work when running on my development box (http://localhost/myApplication). It does not work when running on our test or production servers.
I have tried solutions both with and without system.net.defaultProxy settings in web.config. Neither worked.
What am I doing wrong? Is it a server setting? Is it code? Is it web.config?
We did finally figure out the problem. Our network administrators have disabled double-hopping, so while the impersonation was correctly connecting as domain\jmeyer, the application was still attempting to connect to the SRS box with domain\web01$. Why is it set up like this? Because double-hopping is a massive security hole. (Or so I was told. Does this sound like something you would read on The Daily WTF?)
Our solution was to create a generic domain\ssrs_report_services user, and connect with that user with the following network credentials
public class CustomCredentials : IReportServerCredentials
{
public bool GetFormsCredentials(out Cookie authCookie, out string userName, out string password, out string authority)
{
authCookie = null;
userName = password = authority = null;
return false;
}
public WindowsIdentity ImpersonationUser
{
get { return null; }
}
public ICredentials NetworkCredentials
{
get { return new NetworkCredential("ssrs_report_services", "password", "domain") ; }
}
}
The above is the classic example solution that you can find all over the internets.
"Double hopping" is allowed - swith on Kerberos authentication ... (so long as it is working properly!)

Resources