Spring Authentication With DWR

[ole.ersoy]

OK - So I changed the login method to looks like this:

public void login(String username, String password)
{
Authentication authentication =
new UsernamePasswordAuthenticationToken(
username,
password);

authentication =
authenticationManager.
authenticate(authentication);

if (authentication.isAuthenticated())
{
SecurityContextHolder.getContext().setAuthenticati on(authentication);
};
}

I catch the exceptions on the client side like this:

    var authenticationErrorHandler = function(errorString, exception) 
    {
    	  console.log("This execption occurred: " + exception.javaClassName);
          console.log("ERROR STRING IS: " + errorString);
          if (exception.javaClassName == "org.springframework.security.BadCredentialsException")
          {
              console.log("This occurred: org.springframework.security.BadCredentialsException");
          }
		  else
		  {
			console.log("Authentication Service Offline.  Try later.");
		  }
    };

    var authenticationCallParameters = 
    {
      async: false,
      callback: function() {console.log("Authentication Attempted");},
      errorHandler:this.authenticationErrorHandler
    }

    AuthenticationService.login(
    		"ole", 
			"olespassword", 
			authenticationCallParameters);
	
    AuthenticationService.login(
    		"ole", 
			"wrongpassword",
			authenticationCallParameters);

I think DWR automatically converts subclasses of java.lang.exception with the following in the configuration file:

	<dwr:configuration>
	    <dwr:convert type="exception"
	     			 class="java.lang.Exception">
	    </dwr:convert>
	</dwr:configuration>

[ole.ersoy]

Just tested getting authorizations as well:

	var printRoles = function(/*String[]*/ roles)
	{
		for (role in roles)
		{
			console.log("Role: " + roles[role]);
		}
	}
	
    var authorizationCallParameters = 
    {
      async: false,
      callback: this.printRoles
    }
			
	AuthorizationService.getAuthorities(
		authorizationCallParameters);

Seems to be working fine.

I guess that's it. Should we put a note out on the DWR mailing list? I'd be happy to do it, unless you want to?

[ole.ersoy]

Incidentally I also tested logout:

    var authorizationErrorHandler = function(errorString, exception) 
    {
    	  console.log("This execption occurred: " + exception.javaClassName);
          console.log("ERROR STRING IS: " + errorString);
          if (exception.javaClassName == "java.lang.NullPointerException")
          {
              console.log("java.lang.NullPointerException thrown when trying to get authorities");
          }
		  else
		  {
			console.log("Authorization Service Offline.  Try later.");
		  }
    };
	
    var authorizationCallParameters = 
    {
      async: false,
      callback: this.printRoles,
	  errorHandler: this.authorizationErrorHandler
    }
			
	AuthorizationService.getAuthorities(
		authorizationCallParameters);
		
    AuthenticationService.logout();
	
	AuthorizationService.getAuthorities(
		authorizationCallParameters);

It works as expected.

[nickar]

I didn't saw your code on getAuthorities.
I'm having some trouble with the serialization of GrantedAuthority objects.
What's your dwr config for that?

Just to kick off another aproach to this, perhaps would be usefull to create a method to test 'callability' of methods.
Something like SecurityService.isCallingAllowed(method).
What do you think?

You can write to dwr mailling list if you want.
Perhaps answer to my thread on this!

Regards and congrats to both of us !

[ole.ersoy]

I kept the Authorization code the same.

package com.example.security.authorization;

public interface IAuthorizationService 
{
	public String[] getAuthorities();
}


package com.example.security.authorization.impl;

import org.springframework.security.GrantedAuthority;
import org.springframework.security.context.SecurityContextHolder;

import com.example.security.authorization.IAuthorizationService;

public class AuthorizationServiceImpl implements IAuthorizationService
{
	public String[] getAuthorities() 
	{
        GrantedAuthority[] grantedAuthorities = 
        	SecurityContextHolder.
        	getContext().
        	getAuthentication().
        	getAuthorities();
        
        String[] authorities = 
        	new String[grantedAuthorities.length];
        
        for (int i = 0; i < grantedAuthorities.length; i++)
            authorities[i] = 
            	(String) grantedAuthorities[i].toString();

   		return authorities;
    }
}

I expose the AuthorizationService like this:

    <bean
     id="authorizationServiceImpl"
     class="com.example.security.authorization.impl.AuthorizationServiceImpl">
        <dwr:remote
         javascript="AuthorizationService">
        </dwr:remote>
    </bean>

Does that work for you?

One could do something like:

if (hasRole(user, role))
{
//Call DWR Proxy


}

Where the hasRole method just checks the users authorities against the provide role arguement, before a method is called. Ideally I think the user interface should disable controls that the user cannot interact with due to missing authorities.

Service layer security on the server side should also be applied, in case someone hacks the user interface.

[nickar]

But with the hasRole implementation you are not checking against the methods' aclManager!
I was talking about something that tests if a principal can invoke one service, just to adjust the ui as we where talking before.
If not, we are just crying over the spoiled milk ,
I'm looking into it.
Regards,

[ole.ersoy]

Sorry - The ACL manager concept is new to me. How is that different from checking the authorities?

So a more flushed out way of doing it would be to gather say all the dojo widgets in a list, and then post authentication, have a process that goes through and enables / disables widgets per the authorizations the principal owns, using a similar type of hasRole call. So the client application would need to have previous knowledge of what methods are allowed to be called by what roles, and which widgets call those methods. So:

- Get a list of all widgets
- For each widget
- Check to see whether widgets makes proxy call
- If widgets makes a proxy call, check to see whether principal is authorized to make call
- If not disable widget

[ole.ersoy]

Hang on...is this what the ACL Manager does?

....So the client application would need to have previous knowledge of what methods are allowed to be called by what roles,...

[nickar]

I am reading the api, i don't know how to do this already.
I don't like the idea of widget authorization.
I would prefer to authorize the methods used by sending a list of names to the server.
What do you think?

[ole.ersoy]

First I would protect all the methods using the AccessDecisionManager. See for example section 2.4.2 here:

http://forum.springsource.org/newrep...ote=1&p=244955

Then I would consider protecting them on the client side as well, mimicking the AccessDecisionManager logic on the client side, so that more informative message can be given. Could just catch the AccessDecisionManager exceptions as well....