I am working on application using GWT platform, and now i want to add security part. What is the best practice to do this?
My requirements for security are:
having user authorities;
hide some places from users without required authorities;
hide some elements on page from users without required authorities;
secure server side from unauthorized requests;
comfortable managing all of this things (like in spring using annotations or something like this )
having user authorities;
Model your users with permission atribute, like
private int user_type;
hide some places from users without required authorities;
Use the concept of Gate Keeper
A Gate Keeper is Singleton that obligates you to inherit a method called
boolean canReveal()
Using this, you can call server and search for user permission, then reveal or not the presenter called.
If a Presenter need security, just add #UseGateKeeper on it Proxy interface, like:
SomePresenter extends Presenter<V,P>{
#UseGateKeeper(YourGateKeeper.class)
SomePresenterProxy extends ProxyPlace{}
}
This will block users without some permission to access a presenter.
hide some elements on page from users without required authorities;
A good question, I've never seen this type of security in GWTP Projects. But you can always use Widget.setVisible(false) ;D, but I don't know if gwtp has a good practice for this.
secure server side from unauthorized requests;
GWTP GWTP makes it possible to link each of your ActionHandlers with a server-side ActionValidator that determines whether or not the current client can execute the action
You can hide some server calls using ActionValidator's.
read this
comfortable managing all of this things (like in spring using annotations or something like this)
As you can see, many of this security concepts use Annotations and other's stuff to manage easily your Application.
Related
I have been trying to implement an authorisation scenario in my loopback architecture, I am well aware of the default authorisation that is being provided by loopback, but I'm using auth0 as my user management platform.
I am having user type in the auth0 metadata and now I want to allow certain HTTP methods on those particular loopback entities based on the attribute in the user object.
There might also be scenarios where for certain users I will have to hide a few properties of a model while open them up and show in case of others. If there is any other framework that might serve my purpose I am happy to restructure the whole system. Any suggestions would be helpful.
I have a GWT application that resides within a single web page, which I believe is fairly typical. I am in the process of securing it, and I need advice on choosing a proper approach. My ultimate intention is to check for presence of authenticated session on every gwtrpc server call.
In the past when dealing with servlet/JSP-based web application, I used filter and filter-mapping definitions in web.xml. And that worked like a charm considering that such applications usually consisted of many web pages, and redirection to a login page went right along with it. But in case of GWT and its often-used single screen nature, I feel that overriding RemoteServiceServlet's processPost() function may be a better approach. My intention would be to check for presence of an existing session, and then throw an appropriate exception if needed. The client would then react accordingly (i.e. login popup, etc) by determining the course of action based on whatever exception is thrown back to it.
I am aware of other existing solutions such as Spring security, but I would really like to hear opinions on my idea. Thank you.
I don't think that you should check for an authenticated session yourself. Let the application container deal with that. Of course, in order to do that, you will need a login-config section and security constraints in your web.xml file.
A good way to secure specific parts of your application is to check (prior to the actual display of the screen) if the current user is allowed to. From your remote servlet you can call getThreadLocalRequest().getUserPrincipal() to get the actual user (null if not authenticated) and getThreadLocalRequest().isUserInRole("admin") to make the autorization.
Hope this is helpful for you !
Im using GWT, GAE to make a web app.
I looked at a bunch of tutorials regarding implementing a login system but most of those tutorials implement it so it's mandatory to login to access the web app. How would I go about making it so that anyone can access the app but if they want to use account specific functionality, they they have the option of signing up for an account.
There are two parts to it.
First, in your client code you check if a user is logged in. If so, you allow access to the "closed" parts of the app. If not, you show a link/button to login and hide tabs/views that are accessible to authorized users.
Second, in your server code you specify which requests do not require authentication and which do require it. This is necessary if a user somehow figures out how to send a request without using your client code.
For example, in my code some requests have checkSession() called at the very beginning. If no authentication object is found for this user in session, this method throws LoginException to the client. If the authentication object is present, the request continues to execute normally and returns requested data to the client.
Further to Andrei's answer, if you want a framework to manage the sessions for you, you can use GWT-Platform, which has an excellent Gatekeeper feature.
I use it for mine and I have a LoggedInGatekeeper class. Simply add #UseGatekeeper(LoggedInGatekeeper.class) to the constructor of each presenter proxy and it checks if the user is logged in. If you want anyone to be able to access that page simply annotate with #NoGatekeeper. Easy!
It takes a bit of setting up but it's a great MVP framework. There are maven archetypes and samples etc.
Hope this helps.
In my Cake 2.3 app, I have an action that's called via ajax. Since I'm using the Security component, I had to use $this->Security->unlockedActions, otherwise the action would fail.
However, unlockActions doesn't work when $this->Security->requireAuth() is called. Is this a bug? Do I have a misunderstanding of how CakePHP handles security?
Why doesn't unlockActions override requireAuth?
SecurityComponent::requireAuth() adds that action to an array of required actions, stored in SecurityComponent::$requireAuth.
If you take a look at the Security Component's startup code, you'll find that SecurityComponent::_authRequired(), the method that checks the $requireAuth array, is called before the unlocked actions are even checked. I imagine if you require an action to be authorized, that should take precedence over telling the app that it doesn't.
I would still consider this a bug (or incorrectly documented), as it clearly states in the documentation:
There may be cases where you want to disable all security checks for
an action (ex. ajax request). You may "unlock" these actions by
listing them in $this->Security->unlockedActions in your beforeFilter.
This is a new feature so it might be good to open up a ticket explaining the confusion and see what the core team thinks about it.
I should also note here that disabling the Security Component for ajax requests isn't always necessary. I have several apps that successfully use the Security Component, along with CSRF checks, side-by-side with ajax.
Authentication is very different from security.
Security protects against several ways to hack into your website, while the auth components handles the clearance of your users. When a member is updating his profile, I do want to verify that it is a logged in member (authentication), but i might not want to use the security component for the action he is calling.
I need a gear for custom authorization in business logic classes. It has to be permissions based system, but I can not decide how to apply authorization rules to methods.
My first thought was to apply custom attributes to method
[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
// some code goes here
}
My business logic class has interface, so I can use, for example, Unity Interception behavior and check in runtime if current user has required permissions. And throw an exception if he has not.
But now I'm concerned about reliability of this method.
Usually the reference to business logic class injected by unity container. So there is no problem because it is configured to apply interface interception mechanism.
But what if some developer will instantiate my business logic class directly? Then no interception will be applied and he will be able to call any method even if current user has not permissions to make some actions or even he is not authenticated.
Also somebody can change unity container configuration, turn off Interception extension completly. Again my authorization system will not work.
I saw ASP .NET MVC is using similar mechanism for authorization. Authorization rule is applied only when request came by standard way (IController.Execute). I think this is not a problem in this case because end user of controller (web user) has no way to access controller class directly.
In my case end user of business logic is a programmer who develops front end and he can intentionally or unintentionally screw things - create instance of business logic class and call any methods.
What can you suggest me? How do you deal with this kind of problems?
Thank you.
The .NET Framework supports a mechanism for declarative permission verifications that does not depend on Unity interception or other "external" AOP. In order to take advantage of this, your attribute must inherit from System.Security.Permissions.CodeAccessSecurityAttribute. The System.Security.Permissions.PrincipalPermissionAttribute that is included in the BCL is an example of using this mechanism to evaluate user permissions. If it does not suit your needs, there's nothing stopping you from creating your own attribute that does.
If your constructors are internal and your objects instantiated from a factory, a developper won't be able to bypass your security by error.
If someone really, really wants to create your objets without the security, he could still do it using reflection, but this would have be pretty intentional to do so.