I am new to tableau. I have this complicated problem in our system, where I am trying to use trusted authentication to by-pass tableau login. We have installed Tableau server (ex: 1.2.3.4) and have added the webserver (ex:1.3.3.4) to its trusted hosts list. In order to connect to the servers, we use Cisco VPN our IP is dynamic.
The tableau reports are to be integrated to a asp.net web application hosted in the webserver (1.3.3.4), which has an existing login mechanism. So, I would like to avoid/by-pass the tableau login. To achieve this, I am trying to use trusted authentication. When I tested this in the webserver (1.3.3.4) as mentioned in the link : http://kb.tableau.com/articles/knowledgebase/testing-trusted-authentication, it returns ticket value only when I send the client IP. But when I try to access the embedded tableau reports, I am unable to get the reports. Instead, I get "Could not locate unexpired trusted ticket" error. Also, I am unable to find ways to retrieve VPN IPs of the clients from my webserver. My requirement is to find a proper way to avoid tableau login (using trusted authentication) while embedding the reports in our asp.net web application.
Is there any other possible way of implementing the same or am I missing something? Since I can't find any proper examples for the same, I am posting this question. Kindly provide me your valuable inputs in finding a suitable solution.
Thanks in advance.
Related
Can someone please help me with the query shown below?
I am running DSS server in my development server. I want to connect it to my local machine's SQL Server 2014 with servername using windows authentication. I wasn't able to find any documents related to this.
I added jtds jar in the repository/components/lib folder but still getting below error
In the Dss I configured with below details but getting below error(PFA screenshot)
Error:
Driver class com.microsoft.sqlserver.jdbc.SQLServerDriver can not be loaded
Can you please help me, how to define the connection parameters in the DSS to connect my local SQL Server with Windows authentication ?
Thanks
Mahaboob
Bit of a convoluted answer so here goes.
You can use Windows Authentication with DSS, there are many articles describing how to do this. Just google it. However, the limitation is that you must run the DSS service to impersonate a domain user, then, set the username in the connection string and, magic, the user will be impersonated and you will be connected.
Its not all good news. You will be limited to impersonating one user per DSS instance. So unless you can have a single user configured for all the SQL DB's you will use... you get the point.
The simplest way is to enable SQL Authentication. If you are in a corporate MS type shop, then your DBA'a may advise this is not a good practice. In my case, we were successful in granting special business exceptions to enable SQL Auth.
I hope this is helpful
I found the issue. It is due to sqlserver jar file is missing.
we have to place sqljdbc.jar file into repository\components\lib location to get rid of driver class error. please download the jar file from https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11774
But my question still remains that how to establish a connectivity to a sqlserver using windows authentication?
I am being driven slowly and inexorably mad by the setup of IIS to allow access to Exchange Web Services from ASP.NET website that uses Windows Authentication. I have found literally dozens of articles on how to set this up, each of which seems to say something different, or else describes a process to me that fails when I duplicate it, presumably by there being some assumed knowledge on my part.
Application uses windows authentication to identify the user.
Application sends emails using EWS such that the email ends up in the users "sent items"
Exchange is hosted on a separate server than the web server, so I am assuming the "double-hop" I have read about issue is occurring. I am not a sysadmin, so I do not really understand this.
Is there some clear way for me to setup this up to work, and then potentially troubleshoot the problem?
Yes, from your description it certainly looks like a double-hop problem. It's non-trivial to fix, basically you need to setup delegation between the web server and the exchange server to for the web server to be able to use the kerberos ticket issued when the user logs in to the web server.
I have yet to deploy a single solution that actually does that. We have always ended up either using a service account (with appropriate access rights to exchange, mailboxes etc.) or place the web application on the exchange server. Neither option is particularly elegant, but in most cases operations teams have been unwilling to set up delegation or known how to do it properly.
If I pass in some Ids from an Asp.net application to SSRS server to render reports - how do I make sure that Ids are not read/modified by the end user?
One way I guess is to use ReportViewer control in Asp.net app and have SSL implemented, but is that foolproof? or are their better/alternate ways to implement security in such an app.
Three levels you could do for security purposes:
Change the default port on the SSRS server to something other than 80. EG: Change it to 81 and then someone needs to connect via: http:// (servername):81/ReportServer. Using a different port makes traffic not on the common internet port of 80 may be a good way to hide usage. This would also require that on the server hosting this port that you open this port up under Windows Firewall settings for use with this application.
Use the HTTPS with a certificate to determine that connection is valid between a host and target.
Set up only a single user on the SSRS Site aside from a local admin. Give that user read only rights. Set up your application to authenticate to the ReportViewer via remote mode but HARD CODE this value into your method, do not put in an app or web config. This way someone would have to have access to source code to be able to view user, they would not be able to get into the SSRS site to even see the user if they were not a local admin on the server hosting SSRS.
Those are my ideas anyways. Most of the time people have problems with SSRS being too secure to just get in versus yours you want more security. I hope some of this helps as I know that this method I cannot say is 100% foolproof(nothing is IMHO) but it now has added a level of complexity in adding a different port as well as a dedicated user with minimal permission only viewable by one other account but can be hardcoded in front end applications.
You can also add your security to your report level. Use User!UserID to capture who is logging into your report. and check that with a dataset you create from the application database that manages the access rights to the reports. This way, you can filter the data from showing for wrong users.
Note: Please consider this as another layer to your system security and Do not rely only on this. There are ways that a power user can go around this.
Im currently in the process of exposing our internal CRM system to the web so our employees can use it outside out network. The data is being surfaced to our web application via asp.net WebAPI.
We have SSL setup on the website. But am thinking how else I can make sure the WebAPI is secure from malicious use. My ideas are:
Tracking what IP addresses are accessing the WebAPI and only allow addresses that we have validated are from employees. Problem with this having dynamic IP addresses we might be constantly updating a data store of valid IP addresses.
The user has to login to the system. So every request to the webapi will send across their login details which will be validated before the webapi will process any request.
Pass the device ID of the device using the webAPI and validate (pretty much the same as IP Address tracking in idea 1)
Having a unique clientside generated access token which much match up at the server side.
Has anybody got any advice on my security ideas I outlined? Is it to little or is it overkill?
Just want to make sure the data cannot be hacked, because my butt would be on the line if it did.
Thanks in advance
I would actually choose a totally different solution - updating valid dynamic IP's will be hell.
I would:
Create a new Project using the "Intranet Application" instead of using "Internet Application"
Host the application on your local office network
Set up VPN to your Office for your colleagues
Would this solution be possible for you?
I have ELMAH setup on an ASP.NET site and I would like to use the elmah-loganalyzer on it remotely, while still keeping ELMAH secure from prying eyes. Basically, I want to be able to search the logs from home in an emergency without busting out the work-laptop and using the super-slow VPN.
I know I can secure ELMAH using forms authentication and/or IP addresses via the web.config as addressed elsewhere. The problem is that the elmah-loganalyzer can't login with forms authentication (that I know of) and I would want to check it from a dynamic IP address, so those options are out. The elmah-loganalyzer can login as a Windows user, but the website is not using that form of authentication.
Does anyone know of another way to secure ELMAH that the loganalyzer can use, or a way to secure just this one section of the site with Windows Authentication?
Just use it to connect directly to the database. Forms and Windows auth are used for protecting the web-based handler but the log analyser can connect directly to the DB (obviously with the appropriate credentials).