Hi Stephan, > what about put the javax.security.Principal in the request attributes > after successfull authentication?
This is a possibility, maybe a good compromise that would also you to get rid of your subclass? > And, BTW: > You wrote that you put all authentication logic in the engine (in an > issue comment, I don't know which issue). That's not fully right: The > Guard is called to check the secrets, but only if Basic Auth is used. The Guard also works with HTTP DIGEST authentication (in SVN trunk) and can potentially work with other HTTP authentication schemes (SNEPGO, OpenID, NTLM, OAuth, . See related issues: "Support pluggable authentication" http://restlet.tigris.org/issues/show_bug.cgi?id=229 "Add support for OAuth authorization" http://restlet.tigris.org/issues/show_bug.cgi?id=443 "Support WSSE authentication" http://restlet.tigris.org/issues/show_bug.cgi?id=231 > If I want to implement MyGuard to check against a database > (or whatever) > than I would override this method. But than MyGuard only > works for Basic > Auth. If MyGuard should work for all authentication schemes, > than I have > to override findSecrets(String identifier). This requires to save the > clear password in the database (or whereever). This is not good for > security reasons. I think it should be possible to use the > authentication schemes without requiring the uncrypted > password to bes > stored. Your implementation of "findSecret(id)" can perfectly retrieve an encrypted password in a database, decode it and return the password in clear, just for the time of the verification. > The first point have a higher priority for me (it would work without, > but the result implementation would be more Restlet like, > because I can > remove the JaxRsGuard and every Guard could be used). > The second is not important for me, but I can reflect on this. A > possible solution could be that ChallengeScheme subclasses (one for > every supported ChallengeScheme) contains also the logic for the > authentification. > BTW: I understand RFC 2616 / RFC 2617, that it is also > allowed to return > more than one ChallengeScheme. But this is one more point :-). The ChallengeScheme only descriptor the scheme used. In order to have pluggable schemes, we need to keep the logic in the engine. Most of the refactoring was done by supporting DIGEST, now we mainly need to support pluggability on the engine side, something for version 1.2 Best regards, Jerome
