On our intranet, I want to provide a website that certain employees can access. The work they do on the site will be recorded and tagged with their user-name for identification if the need should arise. Of course users have already logged in to their workstation and they have supplied credentials to our Active Directory.
Rather than maintain an additional set of user logins and passwords for the website, and forcing users to enter this second set of credentials, I am wondering if they can just be silently authenticated when they pull up the site? Somehow the webpage would have to find out their Active Directory user name as known on their workstation. (I see no reason it would need their password.) And then, for their work, the website can store their actions tagged with their user name.
So: I'd log in to my workstation as "Mark" in domain "ONU-AD". I'd pull up the webpage "resolveticket.php". That page would not challenge me for credentials, but it can access my username and store that with my various actions.
NOTE: I have seen some questions and answers here that were more specific. But my initial question is general: is there a piece of tech that can help with this? What is it? (for example, should I try to do this with Java?) Many similar questions are about ways to get this information in a server-side script. But I am simply wanting the webpage sitting on the client computer to be able to get the user name and perhaps place it in an input (type="hidden") on a web form.
Related
Is it easy for people to find "public" google sheets/docs?
Context: Storing some semi-sensitive data (individual user info, of non-sensitive nature) for an app beta-test in google sheets. Planning to migrate to some DB in the future, but for now, just using JavaScript to pull the data directly from the google sheets (since there are visualizations being dynamically updated by the sheets).
Yes, it's easy to get information. Search engines may index and cache the information. Then, there are bots, crawlers and scrapers. Do NOT put (semi)sensitive information in public. Implement google-oauth properly with google-sheets-api to get information. You can also use service-accounts
Yes, it can be easily accessed.
According to the official Google article Share files from Google Drive: when you set your file's General Access setting to public:
Anyone can search on Google and get access to your file, without signing in to their Google account.
What you can do:
In the case of your app beta-test in google sheets data, you may want to reconsider to change your file's General Access setting to one of the following (in descending order of security):
Restricted - Only people that you manually give access to can view or edit your files. When you click the share button, a prompt will show and you may manually add the users who can view or edit your files:
Afterwards, you may select a role for those users and then they can be notified afterwards through email.
On the other hand, you can share the link to others. A prompt will show like the one below if you send the url through Google Chat:
You may opt to select Don't give access which will result in the following view on the other user's end:
This would mean that if unauthorized users get hold of the file URL, they will still need to send an access request. If other users submit the request, an email notification will be sent to your mail inbox. Other users who also own the file will also be notified by mail.
Your Organization - If you use a Google Account through work or school, anyone signed in to an account in your organization can open the file. If you are an administrator in a work or school workspace, you may set how members can share content within the organization. The administrator can prevent the sharing of content with group members outside your organization. If external sharing is prohibited, only group members who are in your organization can access the group's shared content.
Anyone with the link - Anyone who has the link can use your file, without signing in to their Google Account. This option is least recommended because if the URL is leaked to unauthorized users, they can easily access the file.
References:
Share files from Google Drive
Share content with a group
Don’t make it public unless you want the public to see it. Use oauth to access.
Our web app. sends reports out to users which contain links that point to various items within our web app. (specific records). Users ordinarily have to login to our system to access it, so I am wondering what the best methods are of allowing one of these links to direct the user to the area of the system, without them having to repeatedly login.
When you create a link, you can note which user this link is for. When user clicks on the link, fetch information for the user. Guid in your url would guarantee that no other person can guess path for that users data. This will not technically authenticate a user. But will allow them to see data you need.
First of all it's bad idea to distribute user credentials even to a known email address.
You can generate a unique key for each customer and insert it in query string of included URL in the email. once user clicks on the sent URL, system discovers which user is dealing with and authenticates user. After successful authentication process it really makes sense if you disable the sent unique key.
Here's my scenario - I have the credentials for a couple of websites that need username and password to login. I would like to programmatically do this but just don't where to strrt.
For example, say the website is www.mywebsite.com and the the U: UserID and P: admin.
I am thinking something like this (this is of course pseudo-code): open("www.mywebsite?username=UserID,password=admin".
Can someone lead me down a path where I could learn more on how to do this?
Thanks.
This is note a solution, but when I need to analyze a site I plan to scrape data off that requires a login, I usually use Fiddler to record my session. It will show you all the data between your browser and the site, so you can build the exact URL and variables needed to login to protected sites.
I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...
I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.
But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.
My question is:
What are the reasons why I shouldn't do something like that?
I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!
Edit:
I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything legally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?
If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.
As a user, I don't trust your site with my password. Period.
The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.
The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.
As already said above:
The site (or the site owner) accessing your {google|yahoo|etc} account cannot be trusted not to change your password and kick you out of your account.
But I feel there are other good reasons:
Many people use the same password on more than one site ore account (some could have the same password on gmail and paypal) and the site owner could abuse that
The site owner doesn't want to be held liable for other site owners abusing your account
The site owner could not be able to store your username and password in secure fashion. The site needs to be able to access them automatically. So on the server hosting there is stored everything needed to access those credentials.
And the hosting usually happens in a shared or virtual server with the hosting company administrators (and sometimes - if the hosting company isn't too conscious - fellow users) able to access them.
Security and Confidentiality. Period.
Even some websites like Facebook discourage using this approach in their TOS i believe. If so, it will be illegal to do so.
When supporting a new web app in an enterprise environment, it is often necessary to log in as a specific user in order to diagnose a real or perceived problem they are having. Two opposing issues apply here:
Best practice is to use hashed or encrypted passwords, not clear text. Sometimes, there is a third-party SSO (single sign-on) in the middle. There is no way to retrieve the user's password. Unless the user provides it (not encouraged), there is no way to log in as that user.
Many web app's have personalization and complex authorization. Different users have different roles (admin, manager, user) with different permissions. Sometimes users can only see their data -- their customers or tasks. Some users have read-only access, while others can edit. So, each user's view of the web app is unique.
Assume that in an enterprise environment, it isn't feasible to go to the user's desk, or to connect directly to their machine.
How do you handle this situation?
Edit: I want to reiterate that in a large financial institution or typical Fortune 500 company with hundreds of thousands of employees all of the country, and around the world, it is not possible for a mere developer in some IT unit to be able to directly access a user's machine. Some of those are public-facing web apps used by customers (such as online banking and stock trading). And, many of those are intranet applications rely on Active Directory or an SSO, meaning that user credentials are the same for many applications. I do thank you all for your suggestions; some may be highly useful in other kinds of environments.
A number of these ideas inconvenience the user, either by forcing them to change their password, or by occupying their desktop for your debugging session.
Markc's idea is the best: augment your authentication logic to allow superusers to log in as a particular user by supplying not the user's credentials, but the user's name plus their superuser credentials.
I've done it like this in the past (pseudo-ish python):
if is_user_authenticated(username, userpassword):
login the user
else if ':' in userpassword:
supername, superpassword = userpassword.split(':')
if is_superuser_authenticated(supername, superpassword):
login the user
In other words, if the username and password don't authenticate, if the password has a colon, then it's actually the admin username and admin password joined by a colon, so login as the username if they are the right admin username and password.
This means you can login as the user without knowing their secrets, and without inconveniencing them.
For our web applications we use a process that for lack of a better term is defined as 'hijacking' a user's account.
Basically, administrators can 'hijack' a user's account with a simple button click. In the code, you simply use a unique identifier (user id works in a less secure environment) that then establishes the necessary credentials in the session so that they can then work within that user's profile. For a more secure environment you could use a unique hash for each user.
In order to ensure that this hijack method is secure, it always first verifies that the request is being made by an authenticated administrator with the appropriate rights. Because of this it becomes necessary for either the administrator's session to be hijacked or for their authentication credentials to be captured in order for someone to ever exploit the hijack function within the application.
I had 4 ideas. While I was typing 3 of them were already suggested (so I upvoted them)
Variant on idea 3 - impersonation:
To make this as "identical as possible" to a normal login with minimal code changes, you might add the ability to impersonate directly at login by supplying Admin credentials plus an alternate username, e.g. login as Admin:user, adminpassword. The system would treat this exactly as logging in as user with userpassword.
Idea 4: Can you access the password store? If so, temporarily replace the user's hash with the hash of a known password. (the passwords are often stored online in a database. A SQL Query tool can do the swaps )
An administrator should be able to change a user's password. Change the password for the user to something you know. You can then log in as that user.
Tell the user to reset his/her password after you are done debugging.
Usually by some sort of remote control software that can be used to view their desktop. If they're on a Windows terminal server, then the built in admin tools can be used for that. Otherwise I'd use something like VNC across an internal network, or an external service like LogMeIn (http://www.logmein.com/).
Could you have a testing environment where there is a regular cut of live data copied to (obviously sanitised to meet any security or data protection issues). A user similar in setup to the one having trouble could be used to troubleshoot or indeed the very user if this is allowed.
Use a remote desktop client as mentioned in other answers, but again this may not be practical for you. If you have these rights within the domain, I have heard of error handling even doing a screenscrape and including this in logs! but this sounds a little odd to me.
Could you have an admin tool to clone a user into a demo account?
The solution we have used in our web apps is to have the authN/authZ return the desired user as the effective user. We do this by having an admin feature to setup a masquerade, and then when we ask for the currently logged in user (current_user), we handle the masquerade:
def current_user_with_effective_user
if masked?
current_user_without_effective_user.masquerade_as
else
current_user_without_effective_user
end
end
alias_method_chain, :current_user, :effective_user