Hello Jerome,
what about put the javax.security.Principal in the request attributes
after successfull authentication?
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.
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.
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 :-).
best regards
Stephan
Jerome Louvel wrote:
Stephan Koops wrote
I've implemented this feature for the JAX-RS implementation
by putting an java.security.Principal into the request attribute
map. Should I made this available for the Restlet API?
I would change the Guard, that it set the Principal into the
attribute map for key "java.security.Principal" (in the accept()
method, if it is ok) and add a method Util.getPrincipal()
( or Guard.getPrincipal()? ) that returns the Principal, or
null, if it is not set.
I know that Principal is widely used in Java security APIs, but I'm not
convinced yet that we should explicitly support it in the Guard class.
Personally, I need more feed-back to move further in this area. We have just
landed a patch to add support for HTTP DIGEST, it required a few changes to
Guard. Now all the logic specific to authentication schemes is delegated to
the Engine. It will now be easy to add pluggable authentication modules.
When we add this feature in 1.2, we should definitely consider the support
for JAAS (JDK's authentication APIs).
I've added two related comments:
http://restlet.tigris.org/issues/show_bug.cgi?id=229
We also have two RFE for integration with third-party solutions:
"Support Acegi"
http://restlet.tigris.org/issues/show_bug.cgi?id=264
"Support jGuard"
http://restlet.tigris.org/issues/show_bug.cgi?id=265
Best regards,
Jerome
