Security / Role concept

[chrisw]

Hi,

I have two questions regarding the security mechanism mentioned in the Quick Start Guide.

1) Where do I have to put "setUserRoles()"?
I would assume on the server side. But if I have a xml data source, there is no server call involved, right? With DMI, there is some server logic, but this would mean that the security feature is only working with DMI, which I don't believe yet. ;-)

2) Are other components than data driven ones affected?
Can I also somehow bind a menu item, a layout (canvas) or some other control to some user role? Would be great to let my app be role-dependant, not only the data.

Thank you!

[Isomorphic]

1) generally in a custom version of the IDACall servlet that is just a trivial subclass of it. See the JavaDoc for this servlet to see what to override.

With an .ds.xml file, there are still server calls to get data from a database, and they go through this servlet.

2) yes. What you typically want to do is deliver the list of roles to the client. If they are stored in a database, a simple way to do so is just create a DataSource for the roles and call fetchData() on it. Then you'll have a client-side data structure you can use for role checks so you can conditionally show menu items, components, etc.

[chrisw]

Hi,

thanks for the quick answer!

1) Can you please give me a link? I just found this one: http://www.smartclient.com/smartgwte...etDetails.html
It does not seem to give information on how to create the custom version of IDACall.

EDIT: Found it accidentally in the SDK download. I think I now know how to go on. Thank you!

2) Okay, I understand this approach. I was looking for a little more convenient way, e.g. you could have fields in menupoints like:

menuItem.setRequiredRoleToEnable(ROLES.ADMIN)

Do you plan to have something like that? I understand that I could create subclasses and do it myself, I am just curious if you plan something like that, perhaps integrated with the server functionality to automatically have the callbacks in background. (So I as developer don't have to deal with it)

[Isomorphic]

Deliver the roles to the client once ever, and create a client-side API like MyApplication.hasRole(ROLES.ADMIN). Then your menu code looks like:

menuItem.setEnabled(MyApplication.hasRole(ROLES.ADMIN));

There are still some convenience method we can add here for other, related use cases, and yes we'll be adding them.

[SchlauKunde]

In the SmartClient 8.0 Ref Guide we can find the following for 'OperationBinding.requiresRole':

If you wish to use a role-based security scheme that does not make use of the servlet API's standards, SmartClient Server also implements the setAuthenticated and setUserRoles methods on RPCManager. You can use this API to tell SmartClient that all the requests in the queue currently being processed are associated with a user who has the roles you supply; in this case, SmartClient will not attempt to resolve the user's roles via httpServletRequest.isUserInRole(). When taking this approach, the rpcManager.setUserRoles() method should be called on the server for each transaction received from the client. We recommend doing this by overriding the special IDACall servlet and checking server side state to determine the current user's roles, calling the API, and then calling handleDSRequest() or handleRPCRequest() directly to handle the request(s) passed in.
Here's an example of this approach which assumes the current user's roles has been set directly on the HttpSession object as a comma-separated-string attribute "roles":

  public class SecureIDACall extends IDACall {
  
      public void processRequest(HttpServletRequest request,
              HttpServletResponse response)
       throws ServletException, IOException
      {
          HttpSession session = request.getSession();
          Object roles = session == null ? null : session.getAttribute("roles");
 
          if (roles != null) {
              try {
                  RequestContext context = RequestContext.instance(this, request, response);   
                  RPCManager rpc = new RPCManager(request, response);
                  rpc.setAuthenticated(true);
                  rpc.setUserRoles((String) roles); 
                  
                  // call processRPCTransaction() to iterate through all RPCRequests and
                  // DSRequests and execute them
                  processRPCTransaction(rpc, context);
 
              } catch (Throwable e) {
                  handleError(response, e);
              }
          } else {
              super.processRequest(request, response);
          } 
      }
  }

This code shows how to extend the IDACall class with the SecureIDACall class.

BUT I still don't know how to accomplish the following: That the custom 'SecureIDACall' from above is called instead of the regular 'IDACall' in the regular special IDACall servlet. Please bear with me, but I am not (yet) a Java/Servlet/J2EE Guru ...

[Driftdone]

Did you managed to find a solution?
Can you help me with some tutorials or links wheere I can find a proper way of securing an application?

Thank you in advance,
Angel

[SchlauKunde]

Now my prospects are as follows:
- I am testdriving SmartClient integrated with ColdBox on Railo on Tomcat
- For authentication I use the default ColdBox Security Interceptor
- I have indeed taken the SecureIDACall class as a blueprint to marry SmartClient security with my 3rd party (ColdFusion/ColdBox) approach
- In the file 'web.xml', I have done the following:
<!-- The IDACall servlet handles all Built-in DataSource operations -->
<servlet>
<servlet-name>IDACall</servlet-name>
<servlet-class>com.isomorphic.servlet.SecureIDACall</servlet-class>
</servlet>
so I have just declared the 'SecureIDACall' class instead of the 'IDACall' class; that seems to work !
- I have also found a way to transfer data from CFML (ColdFusion/ColdBox) to Java ! So I can tell the SecureIDACall class if an authenticated user is logged in or not ...


Chances are low an angel will hop on my bandwagon, I guess ...

[bbruyn]

Deliver the roles to the client once ever, and create a client-side API like MyApplication.hasRole(ROLES.ADMIN). Then your menu code looks like:

menuItem.setEnabled(MyApplication.hasRole(ROLES.ADMIN));

There are still some convenience method we can add here for other, related use cases, and yes we'll be adding them.

Is this still the recommended approach? I do remember seeing some new (e.g., DataSourceField) APIs around authorization in 3.x, but I'm not so sure these kinds of use cases are covered yet...

[Isomorphic]

For something like a MenuItem, yes. As you've noted, field-level Declarative Security now covers most cases of editing rules that apply to form and grids, but not menus and not suppressing whole components or screens, for which the above approach is still right.

Note we plan more in this area: a concept of Actions, where a single action may be triggerable from MenuItems and Buttons, Toolstrips, etc, and where the Action can be declared as requiring specific DataSource operations or ability to edit certain fields, so that Declarative Security can auto-disable all UI controls that could trigger that action, based on the user's roles.

[bbruyn]

Note we plan more in this area: a concept of Actions, where a single action may be triggerable from MenuItems and Buttons, Toolstrips, etc, and where the Action can be declared as requiring specific DataSource operations or ability to edit certain fields, so that Declarative Security can auto-disable all UI controls that could trigger that action, based on the user's roles.

That sounds pretty good. I don't suppose you have a timeline for such a thing?

[Isomorphic]

Sorry we don't have a timeline on this - no sponsor yet, and there are no dates attached to the project(s) where it's a dependency.

[evansmith1]

Hello,

Great thread. Does anyone have a sample application using Smart GWT and this authentication? Basically, simple login/logout with some use of datasources.

Thanks,
Evan

[Isomorphic]

The public wiki (wiki.smartclient.com) has a full example for Tomcat Realms, as well as some sample code for Spring Security and JBoss LDAP.

[ffeuerbacher]

Any Updates on this capability?

Does the capability:

"Declarative Security can auto-disable all UI controls that could trigger that action, based on the user's roles."

exist in version 3.1 Pro yet?

Thanks.

[Isomorphic]

The best approach is still to add your own simple convenience method as shown earlier in this thread.

There's little room to improve on this. Currently, Declarative Security requires *only* that a role-based security mechanism is installed in your servlet container that allows calling isUserInRole(). The ability to retrieve *all* current roles for a user would be required to provide a standard client-side API for checking if a user has a role. Defining a mechanism for this wouldn't be much more convenient than letting you do it yourself.

Note that there are additional features in this area slated for 6.0. They are for declaring general enable/disable rules but could be used for security checks as well.