Hi Nirav,
The JAAS extension integrates with Restlet for the authentication aspects thanks to the JaasVerifier class. For the authorization aspect, you can use the static JaasUtils#createSubject(ClientInfo) method to retrieve a JAAS Subject from your authenticated request. The org.restlet.security.User and org.restlet.security.Role implement the java.security.Principal interface in SVN trunk. Before (including 2.0 RC1), we used RolePrincipal and UserPrincipal classes in the JAAS extension. Regarding JAAS authorization, here is some background info: http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/tutorials/GeneralAcn AndAzn.html You then need to define your JAAS policy file as usual, pointing to the org.restlet.security.User/Role classes as the principal classes to grant/deny permissions. You can then use Subject.doAs() mechanism normally. This is really standard JAAS code at this point. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ <http://www.noelios.com/> http://www.noelios.com De : Nirav [mailto:[email protected]] Envoyé : mercredi 3 mars 2010 15:36 À : Jerome Louvel Cc : discuss Objet : Re: Restlet Security - Securing URLs Thanks Jerome! That's a lot of helpful information. Though am currently wondering how do I incorporate JAAS authorization in. Have figured out the JAAS authentication bit quite well, but a little lost around the authorization aspect. Is there any analogus to the Subject.doAs mechanism. Also what would the policy file look like? Is there anywhere I can read on these questions. Cheers! Nirav On Fri, Feb 26, 2010 at 1:55 PM, Jerome Louvel <[email protected]> wrote: Hi Nirav, Thanks for your feed-back. The new security API is still fresh, so we also look forward to hearing how it is applied in the field and what are its limitations. Regarding authorization, there are generally two approaches: 1) Coarse-grained authorization You configure some Authorizer instances (or subclasses like RoleAuthorizer, MethodAuthorizer, etc.) and attach them at key points in the call routing graph (before a Router, for a single route, etc.). This works nicely if you can assign roles to your authenticated users and if your authorization rules don't vary too much between resources. Otherwise, you might end-up with an Authorizer instance in front of each resource class... 2) Fine-grained authorization If your authorization rules tend to be very specific to each resource class, or more complexly specific to resource instances, then it is better to handle them at the resource level manually. As an help, you can leverage the ServerResource#isInRole() method. 3) Mix approaches 1) and 2) This can provide a good balance. --- Now, back to your use case, I would recommend clearly separating the "user -> role(s)" mapping rules (stored in LDAP) from the "role -> permission" rules. For the latter case, you can code those rules statically in the routing code using RoleAuthorizer as in approach 1). If those rules are very dynamic and must be stored in LDAP, I would recommend a fourth approach 4) Middle-grained authorization The idea would be to define several URI subspaces in your overall application URI space. Each subspace would have a unique name, like a role name. Then in LDAP you could assign permissions to roles for each subspace, not duplicating URI information in LDAP. Then, in your Restlet application, you could have a SubspaceAuthorizer class that would retrieve the rules from LDAP based on a given subspace name. An instance of SubspaceAuthorizer for each identified subspace should be created and attached to the proper place in the routing graph. Therefore you wouldn't need to duplicate URI matching code or have to maintain URI templates in several places. Hope this helps! BTW, I've copied this explanation in the wiki: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/113-restle <http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/113-restl e%0d%0at.html> t.html Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -----Message d'origine----- De : [email protected] [mailto:[email protected]] Envoyé : jeudi 18 février 2010 19:52 À : [email protected] Objet : Re: Restlet Security - Securing URLs Hi Nirav, you mean, you have one Authenticator and one Authorizator for a lot of resources? Why do you not protect every resource or some routers with own instances of the Authenticator and/or Authorizator? best regards Stephan Nirav Shah schrieb: > Hello All ! > > I have been working on the Security module of our product since about past two months now and have a nice mechanism integrated into Restlet that lets us implement our security needs. > > We have overwritten the Authenticator and Authorizer to hav our custom requirements met like interfacing with LDAP and fine grained roles. > > The bit that am currently not very happy about is the "Authorization". We are using regex based URI mappings to determine user permissions and roles. > > But this is not very robust, nor is completely foolproof. Also adding a new URL means the Authorizer has to be updated. > > I was wondering if anyone out there has a more interesting approach on how this can be. > > It will also be nice to know some different Authorization mechanisms. > > Thanks and Regards! > Nirav Shah > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 <http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2448 7> &dsMessageId=24487 03 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 <http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2448 8> &dsMessageId=24488 76 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2464892
