I'm using Qlik sense ver 2.1.1, according to the manual of Qlik sense:
4.1.1 Users and licenses
Before anyone can use Qlik Sense, they must be added to the system and licensed. There are two ways that users are added to Qlik Sense Enterprise.
Local Security Layer—Any user already in the operating system’s security layer (Local User Directory or Active Directory, for example) who tries to connect to Qlik Sense is added to the user directory. Those users are not granted access to any resources until they are licensed, but they appear in the user directory.
Directory Sync—After a User Directory Connector (UDC) is configured, users from that directory can be added or synchronized into Qlik Sense. Those users are not granted access to any resources until they are licensed, but they appear in the user directory.
The problem is that I don't want to use domain account to login QLik sense page. I have some pre-defined users on Qlik server for corresponding groups. But, when a new user access Qlik sense page, they're logged in as their domain accounts automatically, and even can't log out, then it's impossible to log-in by my pre-defined user.
How can I change the setting of Qlik sense to disable of this silly automatic log-in mechanism?
The problem you have is that the default Virtual Proxy created during the Qlik Sense installation always attempts to authenticate people against Windows accounts and it only uses Http Authentication to transmit credentials. (If you want something different, you have to create a different Virtual Proxy.)
If your users don't have a chance to type in credentials, it means the browser is configured to automatically supply them when the site asks. You have to turn that setting off. In IE, you can turn it off by going to Internet Options -> Security Tab -> Local Intranet (or whatever makes sense for you) -> Custom Level -> User Authentication (Scroll to the bottom). Set it to the "Prompt for user name and password" setting. Chrome uses IE's settings. In Firefox, go to "about:config", search for "network.automatic-ntlm-auth.trusted-uris", and make sure the domain of your Qlik install is not in the list.
Unfortunately, with Http Authentication, the only way to logout is to close the browser completely (unless there's some browser extension that works around that).
Related
If a .txt file is saved to GCS and clicked on through the developer console browser by an authorized user, the contents are displayed in the web browser. That's fine, but that URL can be sent to anyone, authorized or not, allowing them to view the contents of the file.
"Share publicly" is unchecked, and no changes have been made to the default ACLs. And this isn't specific to .txt files -- that's just the easiest way to replicate the behavior since they're displayed directly in the browser (so you can easily get to that URL).
How do I configure GCS to either disable direct download links or ensure they're compliant with ACLs?
EDIT: It appears that the link expires after a few minutes, which reduces the associated risk a little, but not entirely. I'm still extremely nervous about how easily an authorized user could use this to inadvertently provide an unauthorized user direct access to something they ought not...
Left vs. right-clicking on files
First, regarding the difference between left-or-right clicking: I could not establish a difference between left- or right-clicking on a filename in the Google Cloud Storage storage browser.
To verify this, I opened a Google Cloud Project and opened a private object in a private bucket and opened it using both methods. I copied the URLs and opened them in a Chrome incognito window, where I was not logged in, to verify that my ACLs were not applied.
I was able to see both of the URLs in the incognito window. After some time, my access to them expired. However, interestingly enough, my access to them expired just as well in the window where I was logged-in and authenticated to access Google Cloud Storage.
This is where things get interesting.
Security and ACLs for user data in Google Cloud Storage browser
TL;DR: I believe the behavior you observed, namely that the URL can be viewed by anyone, is working as intended and it cannot be changed beyond what Google Cloud Storage already does with automatic timeouts; let me explain why.
When you are browsing Google Cloud Storage via the Developers Console, you are using the storage browser on the domain console.developers.google.com which means that you are authenticated with Google and proper ACLs can be applied to allow/deny access.
However, the only things you can view on that domain are bucket names, object names, and metadata, not the file content itself.
If Google were to serve you file content on the google.com domain, it would create a security issue by allowing an adversary to force your browser to execute Javascript on your behalf with your Google credentials, thus allowing them to do anything you can do through the web UI. This is typically referred to as an XSS attack.
To disallow this from happening, Google Cloud Storage (and Google in general, e.g., cached web pages) serve user-originating data on a different domain, typically *.googleusercontent.com, where users can't take advantage of any sensitive cookies or credentials, since nothing that Google provides is served on the same domain.
However, as a result, since the data is being served from one domain (*.googleusercontent.com) but your authentication is on a different domain (*.google.com), there is no way to apply the standard Google Cloud Storage bucket or object ACLs to the file contents themselves, while protecting you from XSS attacks by malevolent users.
Thus, ALL users, even those that have direct access to the file, upon viewing them in their browser, will have the content served with a time-limited signed URL on a different domain.
As a side-effect, this does allow users to copy-paste the URL and share it with others, who will have similar time-limited access to the file contents.
Can anyone think of a neat solution for this; we operate an website service and sell to large organisations. Rather than have a logon for everyone, we'd like to be able to provide a direct link to our website from the organisation's Intranet page. We'd then like to check the referrer and if it's in our listed of 'trusted referrers', i.e. the intranet url, then we grant logon without asking for credentials.
I'm aware you can do $_SERVER['HTTP_REFERER']; to get the referrer, but I'm also aware that can be spoofed. Can anyone think of how we could achieve what we want, but while also guaranteeing it won't be hackable?
Thanks in advance
It's not exectly what you want, but to make logging on easier and ensure you don't need to store all the passwords you could use, for example, OpenID.
I think that there is no perfect and safe solution for this.
One solution would be to append tokens to the urls. It will work and it will be save, but anyone who knows the link (including token) will be able to login as that organization
Another solution would be to check the source ip. This can be done in different ways *apache, load balancer, app, etc).
Also a combination of token + ip could work (this token for that organization but only if the request comes from allowed_ips for that organization)
A more elegant solution (which I implemented for several big companies) would be to integrate you website login with the active record domain login. It is possible to use the current user window login as login into a website, using domain authorization. If a user is logged in into a domain, when enters your site will automatically login to the website.
This solution is much more easy to implement than it sounds. But, requires Active directory and workstation that connects to a domain to be in the company (this shouldn't be a problem, most of corporations are using windows on workstations and active directory for domain controller). Also is working best on IE only (direct login to the website). On other browsers the domain login popup will appear and user will have to enter again the domain password.
Also, I am pretty sure that can be made to work on linux environments, but I have no idea how.
I have an MVC2 site that now allows access to it via windows authentication and uses ASP.net Role provider to provide authorization. I am trying to come up with a way for the site to allow the user access to the site if his username is a member of certain groups so I won't have to sign up user in sql, but just sign up a group with access. Anybody have any idea how to do this? Is there a quick and dirty way? So far in my internet perusals I haven't found a quick and dirty way to do this? Any help would be great.
Thanks
Looking up Role/Group information for a User
ASP.NET provides a useful “Role Management” capability, which allows developers to map users into logical “Roles” that can then be used to better control end-user capabilities and authorization access. For example, as a developer I could create a role called “managers” for my web application, and then limit access to portions of the site to only those users within the “managers” role (note: I will be posting additional recipes in the future that discuss how to fully use the Role Management authorization and capabilities features more).
When using Windows Authentication, ASP.NET allows developers to create and populate roles from multiple sources. For example, a developer could setup the built-in ASP.NET 2.0 SqlRoleProvider to map Windows users to custom application roles that are store within a database. This approach is very useful for scenarios where there might be application-specific role mappings that don’t make sense to push into a centralized Active Directory tree/store.
ASP.NET also makes it easy to access central Windows and Active Directory group mappings from within an application as well. For example, if there is a Windows group on the Active Directory network called “DOMAIN\managers”, an ASP.NET application could lookup whether the current Windows authenticated user visiting the ASP.NET site belongs to this group by writing code like this:
If User.IsInRole("DOMAIN\managers") Then
Label1.Text = User.Identity.Name & " is a manager"
Else
Label1.Text = User.Identity.Name & " is not a manager"
End If
Note that the role/group look-up is done via the “User.IsInRole(rolename)” method that is a peer of the User.Identity.Name property.
src
http://weblogs.asp.net/scottgu/archive/2006/07/12/Recipe_3A00_-Enabling-Windows-Authentication-within-an-Intranet-ASP.NET-Web-application.aspx
we are looking into implementing Facebook Connect on our wiki service, http://www.wikidot.com. User-created sites span the *.wikidot.com domain, but also custom domains (like mine http://michalf.me), all handled by our single service.
We have a centralized account system. Users always log in (and create accounts) at www.wikidot.com and they are automatically logged in in all subdomains (cookie domain set to .wikidot.com - easy) and custom domains (automatically, via a series of redirects).
We would like to add FC into our login flow. Now, it would be great to get some clarification about FC Terms, which suggests using one App ID for every domain. In our case however user-created sites are not separate applications.
So, is it OK to use FC on one centralized website where our users log in (on www.wikidot.com) and expand user status on other domains connected to our service? This is how it works right now, without FC.
It would be great if we could get clarification from someone from FB to make sure we will not be violating any terms or policies.
Thanks!
It isn't possible (as far as I know anyway) to use the same app ID on multiple domains. FB allows use across subdomains, but I have found some difficultly with this even at times with the cookies. When you set up an app, you are asked to provide the domain for it. The domain you put here is the only domain that your app will work for. If your users are only ever signing in on wikidot.com, then I suppose you can use what you have already to move those sessions onto the other domains, but once you are on the other domain, you won't be able to use any of the facebook api features; any requests you make will fail.
I think the 'one app id for every domain' condition is more to target people who are trying to use multiple app ids for one domain. I think so long as you aren't transferring any data about the user to different domains/adverts etc, you should be ok. Essentially what you are doing is adding FB connect to your wikidot site, then a separate feature of wikidot is to keep you logged in on other partner sites?
I've got two separate homemade applications that need to communicate among themselves. One is a frontend application (asp.net actually), the other is a backend interface to an accounting application. The backend interface was not created specifically for this frontend - it is a generic interface that many other applications use to integrate with our product.
For the convenience of users we wish to provide a Windows Authentication in our frontend application. That means however that we need to pass the credentials on to the backend application which has to check them.
We do not wish to set up our frontend as a "trusted" application to the backend which can authenticate itself as any user. If the frontend was to be hacked, it would then also compromise the backend system.
As I understand it, one way to do it with Windows Authentication is Kerberos Delegation. However this requires to be explicitly enabled for the user that is to be delegated, and the machine which does the delegation (the server with our frontend). By default these options are disabled in Active Directory, and I suspect that many sysadmins will have their reservations about turning them on for all their users.
Also, I'm not really sure that this is what Kerberos Delegation was meant for. I don't need our frontend to impersonate the user that is connecting. I just need to prove that this user has authenticated itself to me.
How would you do this?
I'm not clear what you can and can't do with your use case but I can answer the question what Kerberos Delegation was meant for.
First let's talk about what Kerberos does prior to delegation. It is important to understand this part well because it is subtle.
Kerberos authenticates the identity of BOTH ends of a communication between two end-points across a network, those end-points can be interactive users or services running on a computer.
This is strong authentication so it will not allow a man-in-middle attack in any form. If set up correctly an end point can guarantee they won't be compromised. To the level of the service name (if you are connecting to IIs on a machine it is different than connecting to SQL Server on the same machine). It makes heavy use of modern encryption techniques and requires the use of secure certificates. The details of the authentication protocol are complicated and not worth going into now, but it involves about 20 different distinct steps of confirmation between the two authenticating end points and authentication server (in windows the Domain Controller is the authentication server).
So what the heck is delegation?
Delegation is a Microsoft extension to the Kerberos standard which
allows a trusted source to continue the authentication to another
end-point.
This allows you to act as a "man in the middle" -- however many settings have to be explicitly setup, certificates installed, etc to allow this to work. It is far from simple. (EDIT: Here is another SO answer on the details - https://stackoverflow.com/a/954154/215752)
So, for example, you could have someone authenticate to a website and then have the .NET code connect to an SQL Server AS THE SAME USER to read data with that user's rights.
Now to answer your question, since I'm not sure what you want to do I present three choices:
1) You want to connect to the back end system as the SAME user as the one authenticating at the website.
In this case Kerberos delegation is perfect -- it does exactly what you want.
2) You want to connect to the back end system as a DIFFERENT user than the one authenticating at the website (eg a service account).
In this case you don't want delegation. Kerberos to the website and Kerberos (as a different user) to the back-end will work great.
3) You want to connect to the back end system as the SAME user some of the time and as a DIFFERENT user other times. (For example, you need to validate this is a legal user for the back end system, but want to perform trusted actions as a system account other times. This is (in my experience) the most common use case.)
In this case you use both. Delegation for the connections which need to validate the user identity and then revert to the service account identity for the times when you need system access to the back end. (A previous question of mine went into the details of how to revert to the system identity on the .NET platform see How to "un-impersonate" (un-delegate?) in Kerberos.)
Here is a post describing how Kerberos works and how to set it up.
ASP.NET passing along Windows Authentication credentials
Actually Kerberos delegation is designed exactly for this use case. But the challenge here is craft this on a legacy system and with AD's settings that you do not want to change.
One possible hack is to have the Front End just send the user and the time of authentication but the backend can query the Active Directory Event Logs to determine whether that user has authenticated to the Front end. This requires you to use WIndows Event Log API.and also play around with Event Log settings in AD to log the issue of service tickets. (MY recollection is that this is the default)
-