Securing GWT Clients With AcrIS

let’s face it fellow developers, our applications tend to grow. and especially with new features and fancy features. and some of them are supposed to be hidden, unless the users are privileged to see its beauty. and to have privileged users you need a fancy login screen with various user roles behind. and as you already know google web toolkit is the right choice to develop your application... but there is no support for securing (it is better to say - hiding) your dialogs, panels, features from curious but unprivileged users. so don’t lose the attention and let me show you how to do it using acris-security .

and what would you say about this piece of code?

public class customerpanel extends securedcomposite {
...

    @secured(grants.security_management)
    protected textbox securityid;

...
}

would you expect that it will show a pretty neat text box only to those who have the privilege to see and manage sensitive information about a customer? yes! this will do the thing. and it will also differentiate the permission to just see (but not change) the text box and to actually change the value. but one step at a time...

common lifecycle of a “secured” web

let’s assume the following lifecycle of our example web application that presents a user with a login panel.

if the user is allowed to access the restricted area represented by a “secured” form, it will display it and applies authorities to the fields of the form. after the user fills the fields and saves the values he will log out. in case the user is not allowed, an informative page will pop-up and if the web is available for public access it can offer a registration form.

the aim of acris-security is to:

• provide access to user services and offer couple of default implementations (currently spring security)
• allow developers to implement client-side security using annotations and also have full programmatic control
• be open to various extensions (own concepts of user relations to authorities, user services, ways of defining security constraints on components,...)

client security

enough of theory, let’s jump into an example. for the purpose of this article i will use the showcase available for acris-security. the showcase uses security annotations and also gwt’s uibinder. the first and one of the most interesting panels is the customerpanel with fields ready to be secured:

public class customerpanel extends securedcomposite {
	interface customerviewuibinder extends uibinder<widget, customerpanel> {}

	private static customerviewuibinder uibinder = gwt.create(customerviewuibinder.class);

	@uifield
	@secured(value = grants.security_management, permission = permission.create)
	protected textbox name;
	
	@uifield
	@secured(grants.security_management)
	protected textbox securityid;

	public customerpanel() {
		initwidget(uibinder.createandbindui(this));
	}
}

as you can see @uifield and @secured (from the package sk.seges.acris.security.client.annotations) are not fighting against each other and live in perfect harmony. also you can note a constant in grants interface. a grant is a friendly representation of the authority describing what for it is. and an authority is a string token representing "what the user is allowed to do". authorities are stored per user in a storage (database, file,...) or are “computed” e.g. from a user’s role (or using your own design of relations between users and authorities). a grant isn’t a sufficient description of what exact representation a component is. there must be an information about permission specifying what the user can actually do with the component secured by the grant. the authority wraps the grant and the permission into one string representation.

so if you annotate a component with grants.security_management (string “security_management”) you implicitly say that if the user has authority::

• role_security_management_view - he is allowed to just see but not change the value of the component
• role_security_management_edit - he is allowed to put a value in there

and of course you can override this behaviour as in the case of “name” text box where the create permission is required. more about the theory and vocabulary is available in the concept section .

acris-security is in symbiosis with spring security and if you are already using spring security’s authorities you can reuse them on the client side directly. you just need to strip the “role_” prefix and be conformant with the grant/permission stuff.

fields are annotated, let’s instantiate the panel:

customerpanel customerpanel = gwt.create(customerpanel.class);
customerpanel.setclientsession(clientsession);
container.add(customerpanel);

because acris-security (and also uibinder in this case) uses deferred binding we have to use gwt.create call to correctly instantiate the panel. you might notice the middle line setting a client session. the client session (usually single for the application or part of the application’s context) actually holds the inforamtion about user and its session/conversation. there (apart of other possible values) is stored the user object with authorities and a session id. after successful log-in the session is filled with the information and by injecting the session to the panel it will be able to compose correct representation based on available authorities.

every panel willing to be secured must implement isecuredobject interface. if you are extending gwt’s composite it might be handy to use securedcomposite and don’t bother with implementing required methods.

log me in please...

alright, we have secured the panel but now we need to log a user in somehow. to separate client and server side and to allow also different implementations there is iuserservice interface available negotiating user’s credentials with an authentication and authorization service. this can be for example spring security authentication manager with a chain of providers (ldap, cas, database,...).

there is a default user service integrated with spring service called... userservice . of course you can use your own/already existing implementation but it has to extend iuserservice interface.

final iuserserviceasync userservice = gwt.create(iuserservice.class);
sessionservicedeftarget endpoint = (sessionservicedeftarget) userservice;
endpoint.setserviceentrypoint("showcase-service/userservice");
endpoint.setsession(clientsession);

user service is standard gwt rpc service. calling login method and filling client session will prepare everything relevant for further securing the panel:

userservice.login(new userpasswordlogintoken(username.gettext(), password.gettext(), null),
	new asynccallback<clientsession>() {
		@override
		public void onsuccess(clientsession result) {
			// copy the information about user and session
			// so secured components can rely on it
			clientsession.setsessionid(result.getsessionid());
			clientsession.setuser(result.getuser());
			loggedincmd.execute();
		}

		@override
		public void onfailure(throwable caught) {
		gwt.log("login failure", caught);
		}
	});

the actual placing of the panel is deferred to the loggedincmd.execute(); call where a new panel is instantiated and put to the parent container.

conclusion

this was a simple example showing how you can quickly enable your application with security using acris . its focus is on the integration of client and server and to easily control security on the client sidein a variety of ways. what it does not do is to focus on the server side security as such because that is solved by frameworks of your choice (like spring security does). it only bridges your server side choice with the gwt client.

we just scratched the surface about what acris-security is capable of and next time we will take a look at runtime security, how to reapply security constraints after re-logging as different user and maybe more.