I have read many questions like my question title, none of them give me a solution.
I am implement a website (using struts2 framework) and I dont know what is the most secure way to check if user is already logged or not. My site has the payment feature, so I should really be careful about this.
All the solution I have read are similar like this:
// Is there a "user" object stored in the user's HttpSession?
Object user = session.getAttribute (USER_HANDLE);
if (user == null) {
// The user has not logged in yet.
}
else {
// the user has logged in
}
I was wondering is there any chance some bad guys can create a fake session object like the user object and then can logged in the system without a valid password?
I also want to know is it practice way, at every required logged in page, not just check the user object is not null, but also check the username and password in the database?
Maybe you should use a security framework like spring security or Apache Shiro.
Security issues are always based on your requirements, in simple which kind of security you want ,because there are various layers of security regarding web. But as you have mentioned, This you can achieve using Struts2-Interceptors, because It provides you terminology to perform some essential operation before and after your action is called.For example refer this link.
Related
JHipster implements several best practices for authentication and authorization.
Mainly described here: https://www.jhipster.tech/security/.
But I still do not see an example how to design a solution, which does not involve putting user verification logic all over the place for a very common use case.
Let's say you have a WebPage using REST-API like BankAccountResource from JHipster Sample App and you want to restrict this to only ADMIN role or currently logged in User. Let's say you have 50 of such services for your customers: BankAccount, Address, BillingAddress, UserData, Devices... For every resource a GET and UPDATE must be restricted. Also loading device /api/device/{id} might not include user-id.
How do I prevent UserA from loading UserB's device by guessing it's id?
How do I avoid planting that code in every method?
I guess JHipster/SpringSecurity has concept/objects to handle such use cases. Could you point me, explain how to use them please?
Maybe this question helps a little bit: Restrict URL access control by id in jhipster
Spring Security hast PostFilters to check if an object e.g. loaded by a method may be accessed. If you need more control you can use Access Control Lists for fine grained access control.
References:
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#domain-acls
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#method-security-expressions
Hard to find a meaningful title. I hope I get clearer now.
I'm building a service which is similar to doodle regarding the authentication model. The user can "create" something (using a form). There will be two different views. One for the creator where he can modify his settings and another one for public access.
I don't want to force users to register / log in. So I came up with a URL structure like doodle has:
/{some-id} -> public access
/{some-id}/admin/{some-token} -> settings page for the owner
The question now is how I can deal with this best. Currently I pass the token to all admin related Methods. But I don't feel comfortable with that.
I also thought about some server side session. I found two meteor packages but they are both not actively maintained anymore.
Another idea was to misuse the built in user management but without the user to recognize it. But I don't think that's feasible.
So now I'm asking you if you have a nice way of dealing with this. I hope I made clear what I want to do.
There are many ways of doing it. One way is to reuse Accounts package.
You user id is {some-id} and the password is {some-token}.
When you create new page. You create new user on server side using Account.createUser.
When you enter url /{some-id}/admin/{some-token}Meteor.loginWithPassword.
I've looked hard into this article about OAuth Authorization Server with OWIN/Katana: http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
The article does tell us how to set up a basic Auth server but seems to omit a lot of information and code. I'm particularly interested in the implicit grant flow. They did provide the login page and the "permissions" page, but I'm confused:
Where is the code that decides whether the authenticated user has granted the client? This can't be done "behind the scenes" because we NEVER told any middleware "component" the path "/OAuth/Authorize".
Where is the code that actually redirects the user back to the client's website, along with the auto-generated access_token and other values?
I'm suspecting that there is a proper way to "construct" the ClaimsIdentity object (particularly the scope claims) before passing it to authentication.SignIn(claimsIdentity) in /OAuth/Authorize, so that it would automatically redirect the user back to the client with access and refresh tokens.
The MVC Actions of /OAuth/Authorize and /Accounts/Login seem to always return View() even after successful authentication and granting, thus never forwards the user back to the client's website. This seems like I would have to manually determine when to return Redirect(Request.QueryString["RedirectUrl"]);, and figure out the encrypted values to pass along with it. This doesn't seem like I should be generating the exact response.
What did I overlook?
As #(LittleBobby Tables) said your questions are very broad.
Based on how you asked the question you actual understand the topics but not the how?
I suggest you look at the full source code at
http://code.msdn.microsoft.com/OWIN-OAuth-20-Authorization-ba2b8783/file/114932/1/AuthorizationServer.zip
Your answers are either present or will lead you in the right direction
Has anyone successfully implemented the Google Identity Toolkit, an implementation of an Account Chooser. I followed the initial steps here, but I still have a few questions, as I don't quite know how to handle the entire data flow. I'm using Clojure / Compojure in the back-end:
http://havethunk.wordpress.com/2011/08/10/google-identity-toolkit-asp-net-mvc3/
http://code.google.com/apis/identitytoolkit/v1/acguide.html
A) don't quite understand how ID Provider authentication, fits into my data model
when implementing the callbackURL, what data should I expect, and
how's that session state managed by GITkit (and all Account Choosers)
B) Is there a way to set this up the 'callbackURL' for development.
the identity provider would need a URL that it can redirect back to
C) How can the GITkit / Account Chooser workflow let my users register an account that's native to my app?
Thanks in advance
The questions aren't entirely clear, but I've done an implementation of GITkit in ruby and can give you some pointers.
A) The callback URL is what handles the assertion from the identity providers. Rightnow GITKit only does OpenID, so the URL will contain an OpenID response either in the query parameters or as the POST body. You'll need to do a few things:
1) Call verifyAssertion in the gitkit API and pass the params/post body. This will return a JSON response that contains the user details (assuming assertion is valid). There are some other checks you should do as well
2) Decide what to do with the assertion. If it is an existing user, most likely you'll just establish a session and save the user ID. If it's a new user, you can either create a new account and start a session immediately, or defer that and redirect them to a signup page.
3) Render HTML/JS to notify the widget. There are different status codes and data you can return that changes the flow.
GITKit itself doesn't really manage session state, that's up to your app. Some of the reference implementations have code to help, but it's not part of the API. The widget does have some state that you can control with JS (add account, show as logged in, etc) and uses local storage in the browser.
The docs give some details and example code for how this should be implemented.
B) Of course. The URL is just configured in the javascript widget when you call setConfig() It can be set to localhost or any staging server for development. So long as your browser can reach it you're OK.
C) By "native", I assume you mean where they're signing up with just a username/password instead of using an IDP. If so, the user just has to enter their email address when logging in. If that email address matches a known IDP it'll attempt to authenticate with OpenID, otherwise if it's a new user it'll redirect to whatever signup page you configured in the widget. That signup page would just ask the user to create a password like you normally would. You should also return whether or not accounts are 'legacy' (password) accounts in the userStatus checks.
Hope that helps.
For anyone's future reference. I was able to resolve the issue. You can follow this thread of how's it's done in Clojure.
I got it working with Ring/Compojure, and another fellow showed me his solution in Webnoir.
HTH
I am trying to find the best way to verify if the user is logged in and what role they are on, I'm thinking of a few ways to handle this.
1: Store the login status and role in a invisible control and read it.
2: Use a web service that WatiN can direct to that will return method calls
Any other ideas?
Does logging in produce visible changes in your UI? If it does, I would test for the existence of the markup which underlies these changes. If it doesn't I would ask myself the question, "What changes does logging in produce from a user's perspective?" I would then test for the existence of one or more of those changes. This might be something like the correct loading of a page that only a logged in user can access or the existence of a button or link to access content only provided to authenticated users.
This is what WatiN is designed to test: correctness of application function from the perspective of an actual user. I would hate to see you have to resort to adding hidden fields or extra web services just to support your testing tools.
We check this in exactly the way Waylon suggests.
public bool IsLoggedIn
{
get { return !this.loginLink.Exists && this.logoutLink.Exists; }
}
HTH!