Hi,
Now all the logic specific to authentication schemes is delegated to
the Engine. It will now be easy to add pluggable authentication
modules.
That's great to hear.
"Support Acegi"
http://restlet.tigris.org/issues/show_bug.cgi?id=264
The project for which I'm using Restlet uses Acegi for security, so I
may be able to provide some input and/or code for this support. One
thing I would note at the outset is that Acegi is a large library,
with support for many kinds of authentication/authorization and many
protocols, so it's probably worthwhile to examine what scope of
support would be useful.
For example, the application I'm working on supports either username &
password authentication against the application database or CAS-based
single sign on (the authentication mechanism is a deploy-time
option). Both of these can be handled by Acegi using the same
interfaces, but at the HTTP level (i.e., for Restlet integration)
they'd be different, since they'd need different challenge schemes.
(In fact, I haven't found a defined challenge scheme that would work
for CAS, so it might have to be custom).
That's all to point out that "Acegi support" could be very simple
(provide a Guard which uses HTTP Basic or HTTP Digest and then
delegates the credential verification to an Acegi
AuthenticationProvider or AuthenticationManager) or much more complex
(supporting all the authentication mechanisms Acegi supports; using
Acegi decision mechanisms for authorization). I, for one, am not sure
what amount would be generally useful. Did the original feature
requester have any more detailed suggestions about what would be
useful for him?
Rhett
On Feb 6, 2008, at 8:11 AM, Jerome Louvel wrote:
Hi Stephan,
Somehow, I didn't get this email before. It doesn't appear in the
archives
either, so it was probably lost on the way. Anyway, thanks for
forwarding it
again :)
Yes, I think attributes are the perfect place to put such
information, you can add a user "role" or any other application
specific info about your authenticated user.
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
