Hi all,
Based on Thierrys reply, Ive updated the main security page in the user guide: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet.html That should help people getting started with Restlet 2.0 security API. 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 : Thierry Boileau [mailto:[email protected]] Envoyé : lundi 1 février 2010 17:31 À : [email protected] Objet : Re: Comprehensive example of authentication in RESTLet 2.0? Hello, Thanks Garry for your mail. Just a few words about the security model in the Restlet framework. The Restlet framework has set up its own model (see here [0], [1]) based on some properties of the ClientInfo class: user and roles. This model gets along with ones that are based on principals that are closer or are based on JAAS. These models are distinct, and some bridges are required in some situations in case you want to use JAAS. The security model tries to distinguish the authentication and authorization aspects. The authentication steps relies on a dedicated filter which is a subclass of Authenticator (e.g. ChallengeAuthenticator, or your own) which verifies the credentials stored in the request (challengeResponse attribute) thanks to a Verifier (e.g. a SecretVerifier), Then, the Enroler (if any) is called in order to set the list of roles of the user. Once the credentials have been authenticated and the User and Roles have been set by the Authenticator/Verifier/Enroler, then the request is ready to be routed to the right resource. If the request is not authenticated, a "Unauthorized (401)" response is sent back, by default. According to your policy, some parts of the hierarchy of resource are only authorized to some kinds of people. This is the role of the Authorizer filter. In the sample code attached to this mail, I've implemented a RoleAuthorizer filter, that checks according to a set of autorized roles. You will see that the URIs hierarchy is splitted in two parts, each of them is protected by itw own instance of RoleAuthorizer. If a request is not authorized, a "Forbidden (403)" response is sent back, by default. Of course, you can customize each part: Authenticator, Verifier, Enroler, Authorizer. Regarding the Authenticator helper, this piece of code is used to handle the conversion of header values (of the protocol, e.g. HTTP) with the Restlet API model (Request/Response) in one direction, or both for a certain type of Authentication challenge scheme. At this time, the following schemes are supported: - HTTP_BASIC (client and server) with the core module - HTTP_DIGEST (client and server) with the crypto extension - Amazon S3, shared_key and shared_key_lite (client) with the crypto extension - SMTP (client) with the core module Best regards, Thierry Boileau [0] http://wiki.restlet.org/developers/172-restlet/212-restlet.html#dsy212-restl et_authenticationModel [1] http://wiki.restlet.org/developers/172-restlet/212-restlet.html#dsy212-restl et_authorizationModel Hi Drew, I can't give a comprehensive example but I just built something along these lines recently and actually found the main building blocks to be quite straightforward. I have a number of routes configured in my application, the first object in each is a custom class that extends org.restlet.security.Authenticator. That class has an authenticate method that receives the request and response objects and returns a boolean result -- though you also need set the status code on the response if it's a non 200-code situation. Within that method I check the custom values of the ChallengeResponse object that my AuthenticationHelper populates (see below) to make coarse authentication decisions. The next objects in my routes are then different subclasses of org.restlet.security.Authorizer that have an authorize method analogous to the authenticate method in the Authenticator. By this mechanism I have logic that has parsed the header into the user credentials, made a decision if this is a valid user and decided if they can use the resource before the resource is ever touched. Re the AuthenticationHelper, I was initially confused by this but for me it was easier than I expected. I wrote a subclass of org.restlet.engine.security.AuthenticatorHelper and overrode the parseResponse method. This method receives the raw bytes from the Authorization header in the request and its in this method that I take this and use it to populate the ChallengeResponse object used by the authenticator. So this is where you could do your database lookups to convert the raw auth data into fields on the ChallengeResponse object that the Authenticator will then use for its authentication decisions. AuthenticationHelper has a bunch of other methods depending on whether or not you've got more elaborate auth schemes but for me all I needed do was implement the one method. You do need register the helper and this is where I can't help you. I was receiving requests using the Amazon S3 authentication scheme and that's specified as a type in org.restlet.ChallengeScheme. I'm not sure how you register with a custom scheme. The one thing I did find was that once I had my custom Authenticator, Authorizer and AuthenticationHelper classes it all just worked; the Restlet machinery calls the right methods at the right times and you get the outcomes you want. It's pretty cool. Hope that helps a little, Garry On Tue, 26 Jan 2010, Drew wrote: Hello, I'm trying to integrate authentication into my RESTLets however I'm having trouble understanding the authentication scheme that Restlet implements. It seems that most of the examples use the "Guard" class... however this is now deprecated... It seems that ChallengeAuthenticator should be used instead. Also, most of the examples only show simple password validation. How would we extend this to using a database? I understand there are AuthenticationHelpers... how do these fit in? It seems there are many powerful features we can use but I'm having trouble understanding how to use them all together. I guess I'm having trouble understanding how these big pieces fit together... as most of the examples seem to be overly simplistic. If you could point me in the right direction on how to use the 2.0 authentication features I'd much appreciate it. Thanks ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447 <http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2442 326> &dsMessageId=2442326 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2451098
