Currently we have a typical web application, which all the clients access and login using their credentials.
One of the client does not want to login using their credentials, instead they will be passing username, fname, lname in the URL and they should be automatically be logged in if they have an acct or else we need create user account on the fly and log them in.
The web app should act the same way for the rest of the clients. How can this be achieved. Do we need to use any single sign on methodology (SAML, etc)?
Overview of requirement:
Request URL -> Determine if Client is A -> if yes then check the values passed in the url exists in the db -> if yes then log them in automatically -> if no create a record with the passed values and then log them in
---> if client is not A then take them to Login screen
If you are planning to base your decision only on some URL values to allow automatic login, you are creating a very biiig security loophole here.
Instead you should have some configurable mechanism, where system admin maps some IP addresses to specific user. This way when user requests for a page, you check if the IP from which request has come in, belongs to some specific client. If yes, then log him/her in else send them to login screen. This is also a bit of security hole, but a smaller one, because people will not gain access until they know which IPs are mapped to users and until they use some ip spoofing software.
Probably you can put a dual check of URL keys and IP mapping, that will make it tighter.
Best option is to use single sign on technologies like live id authentication. but it will require more efforts, and still requires users to login with live-id for the first time.
edit-->
If you are using your custom authentication mechanism, then you have 2 options
1. Change your login page to detect the request IP and have automatic login for selected users
2. Write a http handler which will check where the request is coming from and auto login the selected user accordingly.
I hope you understand what all things are involved in "Auto Login" which i am talking about. e.g setting the session variables/username, displaying the username on page etc.
Related
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!
I would like to track anonymous user actions as if the user would be authenticated. The goal is to let users perform actions(normally reserved to authenticated users), save it in Database with a special status (not visible until user will log into the application).
For example,
an anonymous user reply to a comment.
The system detect that the user is not logged in, save the comment with special status 'waiting for authentication'.
The system ask user to log in, in order to complete the registration of the comment.
User log into the application.
The system check for 'waiting for authentication' status and update/associate entries to the user authenticated.
Have you any suggestions / experiences to implement this type of functionality? Maybe Symfony has already in feature/bundle for that?
What you are trying to do is simillar to Lazy Registration, which is a proven concept. It is well implemented here at stackoverflow. It allows you to post messages after providing an email address. It works similar to this one:
http://www.90percentofeverything.com/2009/03/16/signup-forms-must-die-heres-how-we-killed-ours/
However, if you really want to go your way, without asking user for an email address, I would recommend storing data at browser local storage. It would save you a lot of work on backend side. Data would be transferred to the backend only when user registers. This way you will also prevent database pollution with users who never registered. http://blog.teamtreehouse.com/storing-data-on-the-client-with-localstorage
You could use ip address but it won't be very effective because one user can access your website from many ip addresses (wifi, 3g/4g connection ...).
You can rely on cookies but once he logs in from another device you can't do anything about it.
IMO, you should save actions and link them to a uniq token that you send to the anonymous user, once he's authenticated he can provide the generated token and then you save actions for that user. Becareful to not forget removing saved anonymous-actions once they are "identified".
Here is the scenario...
I have a site:
http://internet.com
and I set a token(cookie, something like that) from http://internet.com when a user has SUCCESSFULLY logged in.
I also have http://web.internet.com.
On http://web.internet.com I want to display data to users that have that token/cookie/etc available to them.
Here is the use-case
user logs into http://internet.com (asp.net framework hosted on different server - this is our primary product that requires a subscription / username & login )
user then has access to a section that is hidden from plublic view on http://web.internet.com (wordpress site hosted on goDadday - this site contains a knowledge base that we do not want to make public unless they have done [XXXXX] )
both sites are hosted independently of each other and do not share a common username and password
======
Another scenario is to set up wordpress to allow a specific section as a jsonp response. but only if the user is logged in at http://internet.com to allow the user to have access to the jsonp response located at http://web.internet.com
Any ideas from you beautiful people?
It really depends on the level of security you require. You can log a user in to a Wordpress site without a password by using wp_set_auth_cookie, however if you are just validating that a user is logged into the ASP.NET site and then using JSONP to load a page that set's the auth cookie, it will work, however you definitely have some security gaps.
A better solution would be to set a domain level cookie for .internet.com with a token that can be read by any server in your domain. The Wordpress site could then check is_user_logged_in(), and if not take that cookie value and make a back end call to the ASP.NET site to verify its authenticity, and then call wp_set_auth_cookie(). A simple web service would likely be the best option. You would still need some level of mapping between usernames on the ASP.NET and Wordpress site however to know which user_ID to pass.
Let suppose, I am building an asp.net website which has login scenario in it. I want to provide a certain functionality to the website that if the user is already login on computer 1 and now try to login on computer 2, so he will be allowed to remain login on computer 2, while automatically logout him from computer 1.
I also know that http is a stateless medium, so whenever user interact with computer 1 and try to interact with the page, it will get noticed at that time.
You need to store the additional data (the computer currently 'logged in') in the database, or application state. Then when you process the authentication request - check to see if the machine you stored matches the one requesting authentication - if it does not, you would force the user to log-in and store the new computer (ip address) in the database/application state.
In case Tony's suggestion does not fulfill your purpose, You need to generate a hash comprising of "UserLoginName" + "HOST_NAME" +"TIME" (or any combination you like) and store that hash in your Database against that loginName and also send that hash to the user in a Cookie.
On subsequent request you can check through a handler or module if that specific cookie is submitted and contains the value matching your database, if it matches then the user is coming from the same machine and no need to update anything , if not user is coming from some other machine either the cookie shall not be there or would be containing some other hash value so you should send him to Login page again and upon login just recreate the hash and update it in your database against his login.
Hope this shall work.
very simple question:
I have admin site in my web project. So, how can I make it safe?
What I have until now:
Database handled user with userID and userlevel
on the pageload of the admin master page (which includes all admin sites) there is a clause to check if userID is okay (get the user from database) and if userlevel is right
If Not, redirect to Default.aspx with normal master page
if yes, go trought
How safe is it really?
Edit:
The userID is saved in a session on the server.
There is no way to save the login (no cookies).
The user must login to get the userID in the session
The login is saved in a database table user_log with username, password, ip, loginsucceeded and userID
The basic idea looks ok. It all comes down to how you are getting that UserID to make the checks against. If the userID is being passed as a querystring, then that is very bad. If it is stored in a session via sometype of pre authorization then it is better. If you are using SSL, IP checking, etc it will improve your level of security.
The main thing is HOW you are getting the userID to verify against. That is where the exploit will occur. Secure that process and you should be ok with your setup.
Edit: Based on your update this looks ok but it also depends on how secure you really need this to be. How secure is your sign in page? Are you using SSL? Any worries about session highjacking? Why not store an IP with the userID and verify the request IP against the stored IP when doing the UserID fetch from the session?
There are so many security solutions out there. You need to decide how far you need to safely go to ensure the level of security that is necessary for your particular application.
We use integrated windows authentication.
In IIS manager, click the "Directory Security" tab
Uncheck "Anonymous Access"
Check "Integrated Windows Authentication"
This lets you administer who has rights to your admin site by modifying domain accounts instead of using a roll-your-own solution. You can still get the logged-in user's credentials via the Environment class, which can be used to associate any web-specific properties for each user that you want to store in your database. This also has the advantage of automatically handling timeouts, relogin requirement if browser was closed, etc.
Your solution looks almost fine, though it sounds as though you're adding individual user accounts to the SQL server instead of handling everything through the ASP.NET service account login. I'd avoid adding individual user accounts into your database. In ASP.NET, unless you're jumping through some useless hoops, the ASP.NET service account is what is authenticated for DB connectivity, not the user that's logged into the site.