Common storage for all the browsers - html5

I want to maintain common storage across all the browsers in the client machine. Ex. for IE and chrome browsers I want to maintain some key in the user machine. Is this possible?
My scenario is I want to allow a single user to login from a single machine and no restriction on the type of browser/number of browsers user is using.
Basically, we want to allow if user logins from multiple different browsers at a time from the same machine but not from a different machine.
To achieve this we want to maintain a key in user machine/local storage as well in server side for the first time login. Send the same key to the server when the user attempts next log-in from any browser. If the shared key is matched with the server key then allow the user to login else doesn't allow.
I know HTML5 Local Storage and I tried it but it is local to a specific browser.

Related

Authentication in a SharePoint environment

We are developing a Intranet portal that uses integrated authentication, but a few sections of the site will be exposed to users who are not in the domain. For those users we plan to use anonymous access. However, our display logic for the entire application is based on the user logged into the portal, so we are not fully comfortable with this approach. The URL has to be same for both types of users and transitioning between both the environments has to be seamless.
We tried using user controls in pages to authenticate but things didnt pan out. When the page is reached the standard windows authentication grey box pops up.
Is there any way to intercept the request at the IIS level like an HTTP application?
If applicable we would disable anonymous access and for unauthenticated users we will impersonate with a least privileged domain account and redirect to the home page.
SharePoint isn't really designed for the scenario you describe of mixing types of authentication. It dedicates a web application to one type of authentication. You can then 'extend' that web application to use another type of authentication on another address. For example, your intranet portal would use Windows authentication. It could then be extended to use anonymous authentication on another port or domain name.
One option for what you describe is to configure two separate web applications. One is for users that need to authenticate. The other is for anonymous access. Configure the content in the appropriate locations and link between the two as necessary. Users within your domain should not receive a login prompt when connecting to the authenticated site if you use this approach. Users outside your domain will receive a login box and won't be able to access.
Consider using forms authentication for users outside your domain if they need to access your intranet. (Once again the 'forms authenticated' part of your site would be extended to a unique domain name or port.) This would mean they will be prompted to enter their credentials in a form on the page when first connecting.
Read more about authentication on the Authentication Resource Center.
A couple of final points... If you can use SharePoint's default authentication mechanisms rather than writing your own controls, use them as they are well tested and secure. Also, don't be tempted to change SharePoint's IIS settings unless you are certain there is no other way to do what you need. SharePoint regularly updates these itself and may overwrite your changes (or give you grief in other ways).

SharePoint (WSS) Authentication Across Multiple Domains

First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.

Tableau Server On Remote Desktop

We have deployed a tableau server on a Remote Desktop in an offline mode. Now when the business is trying to access the tableau they get a message that only 2 users can sign in at the same time.
We have more than 50 users who need to access the reports and more than 2-4 need to login simultaneously. What are the option we have.
As this is an offline mode deployment, can we give them some URL or anything else they can access the reports from.
The website and ip we had shared had to be white-listed and added to the safe sites by the IT group policy.
Adding answer as someone may also come across the same scenario.

Storing data on browser

I am on the process of modifying a database driven web application where a user may have multiple sub-accounts assigned to employees, these accounts only have access to certain areas of the main account.
The modification I am looking for is to have the application be accessible even when there is no internet or the connection is dropped.
All the users always have internet (cable or ADSL), the application is intended to run on a desktop; However there are cases where the internet connection drops and I need to store the transactions made by the employees so when the network comes back the data is sent to the server.
I been looking at solutions and seem to be stuck with local storage and a 5mb limit, I guess 5 mb will be ok if the internet fails for an hour or so but what if there is a longer wait?
Then my other issue is that the employees usually have access to only 1 or 2 computers max and they have to log-in and out constantly sharing the computer so how do I store those users credentials to allow them log in when there is no way for me to communicate with the server and validate?
Does anyone have any thoughts on what maybe my options?
I decided to go with the web server route.
I will set-up the server with the bare minimum data and logic.
Also decided to process all transactions through it which will also make the whole application faster, then the communication with the internet server can take its time without disrupting local processes.
There is also a monitor that works with a nodejs server which I will be moving locally so I can spare some server resources.
I guess this turned out to be a much better solution.
And about #DylanWatt password concern, I will have a different hash key for local database and remote database if the network is down the transaction stays only local once the network is back up I will wait for the user to re enter the password and then send those transactions on their way to the remote server along with the entered password.

Is there any reliable way to identify a device from a web app?

I'm working on an Html 5 application which works offline using local storage and application cache.
One of the requirements is to restrict the user to a single device (to prevent data ending up in local storage on a public machine for example). It should also be possible to identify a particular device when connecting and trigger a remote wipe.
I'm currently storing a token in local storage that is matched against the user's record on the server each time they reconnect. But a savvy user could of course simply copy this across to another browser /device.
Is there a better way of doing this?
Note: I cannot use native code / deploy inside a native app, so javascript only. I think this means I will struggle to get any unique device id.

Resources