Excuse the extremely newbie question...
Once I have verified the users login credentials, Where should I store the state for whether a user is logged in or not?
Once you have validated that your user is OK according to the backend, you can make ASP.NET set an authentication cookie for the user in the response by doing a FormsAuthentication.SetAuthCookie(username, persistent).
From then on, ASP.NET will decrypt that cookie in requests and extract the username from it, giving you access to it via HttpContext.Current.User.
To me, it sound like this is what you're looking for.
You don't normally need to store this state yourself. If you are using one of ASP.NET's built in authentication mechanisms (e.g. Form Auth) you can simply check: Request.IsAuthenticated
Related
In my iOS app I have my user authenticate against our Domino server and store the username and password. I have some web pages that I want the user to see and am loading them in a UIWebView. However, every time I try to go to the page I am being challenged for authentication. I think I need to send a post to the server with my username and password but I am not sure how to do that?
I've never done that with iOS, so take this with a grain of salt, but I think there are generally two ways to do it:
You can likely pass the UN/password combination along as HTTP Basic authentication in each request. I believe it's the case that Domino will honor those credentials even when session auth is enabled.
If you're using session auth, you can do what you intimate: POST to a Domino URL containing the ?Login command (typically, "/names.nsf?Login" is a good choice) with Username and Password parameters (along the lines of How can I login to Domino via Ajax? ). The resultant value of a successful login will contain an authentication token cookie (typically DomAuthSessId or LtpaToken, depending on whether or not you're using SSO). By including that in the Cookie header in future requests, you should be able to continue the login.
I don't know much about web authorization, but there is one page which after login into gives the user coockie of name AUTH_WEBSITE, and this website redirects to my website which is mvc. Now I would like to only check if this user has that auth cookie and if it has, then I would like to authorize it in my website as well.
Now, I assume that checking cookies this way and givin admin rights based on cookie is NOT safe because other user can create this cookie for him self right ? so what would be better ?
And what is best place in mvc to check if other user is already authorized or has this cookie to prevent forcing user to click login button ?
To solve this issue you can use 2 ways:
When you create your custom cookie, use encryption methods. Encrypt user's role, password, even id etc. So other people can not decrypt them all to create other legal cookie.
For security, the best way is that to check user is exist in system or not in every action start. In your Authorize attribute, take values from cookie and check user, if it just exist continue, else alert : cookie values are wrong.
Creating an angularjs single page application trying to use a RESTful API and I came across a problem that I can't seem to find an answer for. I was trying to prevent session hoping, one user logged in watching the requests figures out his account ID is 13. So he performs the same request but this time alters the request to get info for account ID 14.
So after the user logged in I was setting a session variable to his account ID and was going to strip the account ID out of the ajax requests. I then tried to access the Session from a class inheriting from ApiController. After looking around I realize that storing session information is not very RESTful.
So how would I go about ensuring that one account cannot access another account's information just because they watched the ajax requests and figured out how to manipulate the ajax request?
Is restful not meant to be used with users that need to authenticated and authorized? I was thinking of maybe hashing the IDs or something but I am not sure that is the right approach.
UPDATE:
I have token based authentication working now. But I am still in the dark as to how to prevent someone from fiddling with HTTP request and getting information that doesn't belong to him. For Example, I want to retrieve all the users for account with ID 14.
HTTP Get /users/14
I have a token so I know that the person trying to use the web API at some point authenticated themselves. I can lock it down to roles. But there is nothing stopping this authenticated person form fiddling/hacking with the request and doing the following
HTTP Get /users/58
Now the person has got all of account with ID 58's information. This is information does not belong to account 14 but now he can browse through other people's information.
I need someone of knowing that the request that comes from the browser and says it is for account with ID 14 that it really is account 14. I can put that information in the token but how do I check it in a handler or check it in the ApiController?
The problem you have described is not something unique to REST-based services. In fact, this is one of the top 10 OWASP vulnerabilities (Insecure Direct Object References). You will need to first identify the user and then authenticate the user. For identification, an ID is used, such as user ID. The identifier can be anything you want. After identification, you need to authenticate the user. This is done by authenticating the credential presented to the app, such as password. The identifier and the credential can be any thing, say the good old user name/password, or may be a token or may be an API key. It actually does not matter to the problem on hand. Once authenticated, you authorize the requests based on what the user can do in your app. The authz part is a must regardless of whether you use a token, certificate or what not. Hashing user ID or using some method to hide things is security by obscurity and is not a good practice.
Say, you are using a message handler to authenticate the credential submitted by a user. Once authentication is done you can store the account number associated with the authenticated user in the properties collection of HttpRequestMessage. This is done in the server side and no user can make the system store some random account number. Only the account number associated with the authenticated user is stored in the properties collection. With that, you can now authorize requests. Say, you can write an authorization filter that pulls this account number and compare it against the account number in the URI to determine if the request is allowed or not. By applying this filter against a GET action method, you can ensure only right folks can see right data.
For example, a user with user ID 'abc' and password 'pwd1' makes a GET request to /users/14. First step is, you will authenticate the user ID. If there is a user with ID 'abc' and password 'pwd1' in your store, you will consider the user authentic. As part of this authentication, you can pull the account number associated with the user 'abc'. Say it is 15. You will store 15 in request.properties. From your authorization filter, you can get the account number from URI, which is 14 and compare it against the one in the request, which is 15. Obviously the numbers do not match and you reject the request in the OnActionExecuting method of your filter with a 401.
What I described above is a simple approach. Better one (in terms of extensibility) will be to use claims but it will not be possible to explain all that here. You can get good amount of information related to claims-based identity from Dominick's blog.
Every request should be authenticated. If the credentials provided do not allow the user with account 13 to access data from account 14 then the request will be denied. The trick is to find a way to do authZ quickly.
You seem to be missing the information on how you want to implement authentication. As you correctly noted, using session to keep authentication information is not very restful. Here are the alternatives
Implement your own OAuth provider or use third party (for example
Azure ACS)
Implement STS provider (this is only for soap though)
Implement a custom token system, if you don't want to deal with
the above two. Basic system would take user id, salt it and encrypt with private key - but don't quote me on how secure that would be...
In all the cases, the authentication information is stored in the cookie, similar to session cookie. But it is still stateless.
The standard way on the web seems to be the oauth way, in fact the standard VS MVC template even comes with OAuth consumer implemented out of the box. So the question is, how do you link the oauth token to your internal user ID. That's really pretty simple, as you implement the "registration" step after the new user is authenticated - you keep user ID and oauth token in the database table, to link the two.
That link is quick to retrieve, and can be cached for speed. I have heard some people implement that type of credentials caching for some very big systems (google docs).
I've got a web application that needs to implement SSO with WIF. There is a STS already set up for authentication, and I can use it to log on just fine.
However the application also needs to accommodate anonymous users. So when a user first arrives at the website, I need to somehow check with the STS if he is already logged on or not. If he is, the STS would return his token (simple), but if he isn't, he should be simply returned to the website without any further authentication, so he can continue browsing anonymousley (how do I do this?). If he later wants to authenticate, he clicks the login button and we do the typical WIF authentication dance, which I have already in place.
So... how do I tell an STS to do nothing if a user isn't authenticated?
There's nothing special really with WIF. You just define in your app what requires auth and what doesn't.
In MVC you would use the [Authorize] attribute on controllers. In ASP.NET you can use this: http://msdn.microsoft.com/en-us/library/b6x6shw7(v=vs.100).aspx
You shouldn't mix authentications on your web site (relaying party).
All authentication related issues should be handled by the STS.
To achieve your goal you should allow anonymous users on your STS and return token to your web site (RP) with claims indicating user as "Anonymous" (or whatever You want to call him).
So basicly you have to "authenticate" user as unauthenticated :D.
This way you do not decide your GUI looks and availability based on whether user is authenticated or not but whether he has specific role or not (obviously user "Anonymous" wouldn't have any roles). This seems to me like a better approach.
Hope this helps.
I am reading a great Rails tutorial and came across a passage that I had a question about:
Box 9.2.Sessions and cookies Because
HTTP is a stateless protocol, web
applications requiring user signin
must implement a way to track each
user’s progress from page to page. One
technique for maintaining the user
signin status is to use a traditional
Rails session (via the special session
function) to store a remember token
equal to the user’s id:
session[:remember_token] = user.id
This session object makes the user id
available from page to page by storing
it in a cookie that expires upon
browser close. On each page, the
application can simply call
User.find_by_id(session[:remember_token])
to retrieve the user. Because of the
way Rails handles sessions, this
process is secure; if a malicious user
tries to spoof the user id, Rails will
detect a mismatch based on a special
session id generated for each session.
For our application’s design choice,
which involves persistent
sessions—that is, signin status that
lasts even after browser close—storing
the user id is a security hole. As
soon as we break the tie between the
special session id and the stored user
id, a malicious user could sign in as
that user with a remember_token equal
to the user’s id. To fix this flaw, we
generate a unique, secure remember
token for each user based on the
user’s salt and id. Moreover, a
permanent remember token would also
represent a security hole—by
inspecting the browser cookies, a
malicious user could find the token
and then use it to sign in from any
other computer, any time. We solve
this by adding a timestamp to the
token, and reset the token every time
the user signs into the application.
This results in a persistent session
essentially impervious to attack.
I don't understand what this is saying. I take from it that a unique session ID is created and stored on the client in a cookie. Then when that cookie is sent to the server on a request, the server knows that is the user in question so that the login can be persisted. However, if a malicious user stole the cookie, I don't understand why they can't log in from another computer. The author says this is solved by adding a timestamp, but I don't see how that helps. Further, the author says that the token is reset every time the user signs in, but the whole point is a persistent sign in, so I don't understand. Please help!
You are correct—a "Remember Me" cookie can be used to steal a login. The issue that they're trying to resolve are if someone steals your cookie, containing your unique identifier, and hangs on to it—they'd then be able to log into your account at any point in the future.
The usual solution is to invalidate all previous cookies every time that you log into your account using either the username/password or the "Remember Me" cookie, so that a given cookie will allow you to login a single time. The timestamp is how they're ensuring the uniqueness of each cookie.
If you're worried about cookies being stolen, a typical solution is to also store the IP address that the request came from, and if the IP address that the cookie is coming from doesn't match the IP address that the cookie was created from, deny the login and force the user to sign in. This can be inconvenient to users who are behind dynamic proxies, or who carry their laptop to and from work/home/coffee-shop, since their IP address will change all the time.
"Remember Me" is a security hole by design. The goal is to limit how much of a hole it is, and if you're designing a system that requires absolute security, it's not a good choice. If convenience is more relevant than security, using timestamps and cookie invalidation limits the potential security issues.
If you're interested in more information on this topic, the Security Guide section of Rails Guides has an entire section on sessions.