1 Reply Latest reply on Oct 14, 2010 11:10 AM by Shane Bryzak

    Design strategy for Authorization and Seam Remoting

    Bart Matthaei Newbie

      Hi,


      We're currently implementing a Proof of Concept using Seam 2 and Ext-JS. We use Seam Remoting to glue Seam to Ext-JS, and this works fairly well. We are running into an architectural problem, which is security.


      We combine @WebRemote with @Restrict, but this is purely server side. Restricted methods are still published through Remoting, and will generate an authorization exception when invoked. We want to be able to check authorization for these functions client-side, so we can enable/disable certain actions in the UI (basically rendering limitations without using JSF).


      I could wrap hasRole and hasPermission in a seperate WebRemote call that I can use in javascript to check for authorization, but this is pretty ugly IMHO, since every authorization check would generate an xmlHttpRequest. Another possibility could be the use of reflection to check all webremote methods on all of my components for restriction, and return the results in some sort of structure I can use in javascript to check for method permissions.


      Are there any known strategies I could use for this problem?


      Regards,


      Bart

        • 1. Re: Design strategy for Authorization and Seam Remoting
          Shane Bryzak Master

          Hmm that's quite an interesting problem, and unfortunately I don't have an easy answer for you.  The issue I see is that authorization is not a static thing... who's to say that a failed authorization check for a particular operation won't work the second time?  User privileges might have been modified in the meantime, not to mention that some permissions might be temporal based (i.e. grant the user X permission if the current time is between 1pm and 2pm).  There is simply no way for a client to determine whether a user has authorization to invoke a particular operation without checking with the server.


          That all said though, it should be possible to at least read the user's role memberships and use that information to disable certain UI elements.  It won't be the full authorization spectrum but at least it gives you some control.  We actually do this a fair bit in JSF for some of the Seam examples - you'll see expressions like s:hasRole('admin') inside the rendered attribute for certain tags.  I don't see why you couldn't do something similar to this, all you need is to return a list of the user's role memberships to the page and store them somewhere.  Then you simply use the contents of this list to decide whether to render certain elements.