Hi all, Thanks Bruno for the nice synthesis, that definitely helps moving forward. I have entered a new RFE to consolidate your comments and other ones from Stephan:
"Refactor authentication and authorization" http://restlet.tigris.org/issues/show_bug.cgi?id=505 Stephan, I agree that this will take some time to properly refactor and take all aspects into account. I've listed 13 (!) related issues that I added in the "blocks" field. I don't think it would be wise to rush changes into 1.1 so I have set the milestone to 1.2 M1. Let's continue the discussion here and/or via comments to the RFE. Best regards, Jerome -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 29 mai 2008 10:22 À : discuss@restlet.tigris.org Objet : Re: Guards and authentication mechanisms Hi Bruno, The idea is *very* good. I've also thoughts in this direction, but your proposal is more complete than my ideas was. I've also proposed some month ago to switch the Guard to an abstract class which do the HTTP things, and ubclasses for the check of the secrets. Jerome said, if we changed this, there are other classes that could be splitted, and the class number will grow and grow. If I have time when this should be implemented, I can also work on the refactoring. On the one hand it is useful to have this available in Restlet 1.1, because the authentication already changed since Restlet 1.0 (the authentication logic moved to the Engine). On the other hand this change needs time, and it should not be implemented too fast. Jerome, perhaps we could deprecate the authentication methods in org.restlet.util.Engine. AFIAK it is possible, to allow different auth schemes in onw response. If we do a great change here, lets look, if we could integrate it. @Jerome: Independent of this I like to include the issue 503 (http://restlet.tigris.org/issues/show_bug.cgi?id=503), for the first the access to the username of the connector authentication. The access to the rolecheck could be done later. Jerome, could you assign this issue to me? When can I realise it? Changes for issue 504 could be done without much more work. best regards Stephan Bruno Harbulot schrieb: > Hi all, > > Following the discussion on the authentication scheme a few days ago, > I've been looking at > - "Access to connector authentication" > http://restlet.tigris.org/issues/show_bug.cgi?id=503 > - "Add notion of realm" > http://restlet.tigris.org/issues/show_bug.cgi?id=504 > - "Add support for Guards based password files encrypted by htpasswd" > http://restlet.tigris.org/issues/show_bug.cgi?id=485 > > I've also been looking a bit more generally at Guards, and this raised > a few questions/observations/suggestions, which I suppose could be > part of this discussion. > > I get the impression that a few things in the Guard API are there for > historical reasons (I suppose the first implementation of Guard only > supported HTTP BASIC). > > I'm trying to think of a Guard class that would be sufficiently > abstract to model various types of authentication, not only HTTP > BASIC/DIGEST, but also SSL client-certificates, SPNEGO Kerberos, > Shibboleth and perhaps forms. > I'm just not sure that the notions of Realm (i.e. BASIC/DIGEST > realms), Secrets (known Map), SecretResolver, DomainURI and Nonce all > belong there. What I mean is that perhaps there should be subclasses > of Guard per authentication mechanism. > > In contrast, the solution suggested to issue 485 (htpasswd) is a > subclass, and perhaps there should be the notion of a > authentication-provider instead. Similarly, I'm not familiar with the > OAuth Guard, but I get the impression it doesn't make much use of > Realm, Secrets, etc. > > For example, in Apache Httpd, it's possible to configure > mod_auth_basic [1][2] with several authentication providers used in to > authenticate the user, for example file (htpasswd) or ldap. There's > also a mechanism that In one of the machines I've set up, I've used > something where it's possible to fake the SSL client certificate as a > username in the file. (It's thus possible to have cert-based > authentication and LDAP username/password as a fallback mechanism.) > There would need to be at least two categories of password-based > providers: the ones from which the secret can be extracted (required > for DIGEST) and the others. > > It's just a vague suggestion, but there could be something like this: > > * AuthProvider (abstract?) > * SslAuthProvider extends AuthProvider > (checking the subject DN or perhaps other things) > * PasswordAuthProvider extends AuthProvider > (of which the secret itself can't be obtained) > - checkPassword(String username, char[] password): boolean > * ExtractablePasswordAuthProvider extends PasswordAuthProvider > (one that can reveal the secret as well) > - getPassword(String username): char[] > > There could be more concrete implementations: > * PasswordMapAuthProvider extends ExtractablePasswordAuthProvider > (more or less the same as the current secret map). > * LdapAuthProvider extends PasswordAuthProvider > (which checks the password against an existing LDAP server) > * HtpasswdAuthProvider extends PasswordAuthProvider > (which checks the password from a file as described in issue 485) > * JdbcAuthProvider extends ExtractablePasswordAuthProvider > (which would get the password from a database) > > Then, perhaps a (more) abstract Guard and then classes like these: > * HttpBasicGuard extends Guard > (constructed or somehow provided with a PasswordAuthProvider, it > doesn't actually need to check against a known secret) > * HttpDigestGuard extends Guard > (constructed or somehow provider with an > ExtractablePasswordAuthProvider, since it would need to know the > password) > > These Guards could also take a list of providers rather than a single > one, perhaps to have a fallback solution. > All this being said, this wouldn't cover the case I was mentioning > earlier of SSL-cert falling back to HTTP BASIC/LDAP, so I'd need to > think a bit more about this. > > In addition, perhaps the AuthProviders could be used in relation to > the Realms, etc. They could provide a suitable instance of Principal > (e.g. LdapPrincipal, KerberosPrincipal, ... when JAAS is used). > There's clearly some overlap between this notion of > authentication-providers (similar to Apache Httpd) and the notion of > realms (as in Tomcat or Jetty). > > This would clearly require a bit more thoughts, but does the general > idea seem sensible? > > Best wishes, > > Bruno. > > [1] http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html > [2] http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html
