Implementing .NET thread security with WebORB, Cairngorm and Flex 3

Posted: May 2008, Matt | In: Development | Leave a comment

One of the first challenges I've faced so far has been making the web service calls from Flex more robust and more secure, in this article I discuss how I've implemented .NET thread security using WebORB.NET and Cairngorm. But I'm looking for feedback, do you know a better way?

Much of the security features I’m going to be discussing herein are provided by WebORB.NET or the .NET framework. My issue so far has been that the sample/example code on the WebORB web site demonstrates the technology beautifully, but rarely extends into what I’d term a real world context. By this I mean a command button that attempts to call a secured method does demonstrate the integration with the .NET thread security really well, but it doesn’t then show me how to implement this into a real work flow scenario.

Having followed the tutorials and samples, I couldn’t wait to implement this into my fledgling cairngorm application, but I quickly got lost and confused. My problem wasn’t that I couldn’t get a cairngorm command/delegate to call my .NET services, or that I couldn’t implement a custom authenticator, my problem was how should I use these within a cairngorm context?

At the moment, I’m invoking the SetCredentials() method during a web service call that happens to bring back user details, but is this the correct or recommended procedure? Should I be making the initial SetCredentials() call independently of any web service call, or should it piggy back a login attempt like my current solution?

Sooner or later, I’ll find the answers, but for now, I shall leave my SetCredentials() call piggy backing my GetLoginUser() web service call.

public class GetLoginVO {
		
   private var responder:IResponder;
   private var service:Object;
		
   public function SetCredentialsDelegate( responder:IResponder ) {
      this.responder = responder;
      this.service = ServiceLocator.getInstance().getRemoteObject( "RetreiveUserWithSecurity" );
   }
		
   public function getLoginVO(principal:LoginVO):void {
      ServiceLocator.getInstance().setCredentials(principal.username, principal.password);
			
      var token:AsyncToken = service.GetLoginVO(principal);
      var responder:mx.rpc.Responder = new mx.rpc.Responder(onResult, onFault);
      token.addResponder(responder);
   }
		
   private function onResult( e:ResultEvent ):void {
      var user:LoginVO = e.result as LoginVO;
      responder.result( new ResultEvent( ResultEvent.RESULT, false, true, user ) );
   }
		
   private function onFault( e:FaultEvent ):void {
      trace("com.generic.admin.business.SetCredentialsDelegate#onFault");
      trace(" - " + e.fault.faultCode + " " + e.fault.faultDetail);
			
      responder.fault( new FaultEvent (FaultEvent.FAULT, false, true, e.fault));
   }
}

If you have any thoughts or better still, solutions to this conundrum, please get in touch.