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 > 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&dsMessageId=24487 > 03 > > > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24488 > 76 > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2454473
