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
