7:26 p.m.
On 8/1/12 6:35 PM, Pedro Igor Silva wrote:
Hi Bill,
I think one of the main things about this API is that when creating new mechanisms
you focus only in its logic. The mechanism only needs to know how to extract the
user's credentials (eg.: by using a specific protocol) and call an authentication
manager (user metadata store) to validate its credentials. The user store is not hidden it
is available during the authentication. Also, other aspects like subject
creation/population/propagation are handled by PicketBox. I think you do not need to code
that every time. Of course, the API may provide extensions for custom and specific
behaviour.
Creating reusable helper classes is useful. But I don't see the value
of the multiple level of indirections you are requiring. Its too much
like what we already have.
Another idea is allow multiple user stores during the user
validation, that is configurable. We can also have some policy for the stores like stop in
the first successful validation or require all stores to validate the user.
Multiple user stores needs to be captured in a requirements document!
This idea of generic validation works great for username/password.
Fails miserably for everything else because the algorithm is different.
Just think of the number validators you're going to have to write:
user/password
http digest
client cert
totp
I think a better interface might be:
interface Authenticator {
void authenticate(Metadata metadata);
}
interface AuthenticationManager {
Subject authenticate(Authenticator);
}
class HttpDigest extends Authenticator {
void authenticate(Metadata metadata) {
String password = metdata.getAttribute("password");
.. build hashes..
}
}
void filter(HttpServletRequest request, HttpServletResponse response)
{
String authHeader = request.getHeader("Authorization");
HttpDigest digest =
request.getSession().getAttribute(HttpDigest.class.getName());
if (digest == null)
{
digest = new HttpDigest();
request.getSession().setAttribute(HttpDigest.class.getName());
}
digest.addAuthHeader(authHeader);
AuthenticationManager manager = ...; // injected, looked up,
whatever...
try {
subject = manager.authenticate(digest);
Picketbox.propagate(subject);
} catch (SecurityException exc) {
String authenticateHeader = digest.getAuthenticateHeader();
... add this to servlet response ...
}
}
The above filter() method would be different if reused with Netty, Sun
Http JDK, or Catalina. With the above code you don't need all those
callback abstractions. You also have a completely typed interface.
Also, the HttpDigest class could hold state between requests so nonces
could be compared between requests. How the state is stored is really
up to the component layer. HttpDigest could even be a app-server level
service so that true comparison of nonces could be done per user.
Really all we care about here from Picketlink is the user metadata
store. The rest should be controlled by the component/protocol layer.
I understand that exception,event handling and workflow are
specific, but as the authentication is managed by PicketBox it can also help protocols and
components to customize some behaviour by listening for certain events or extending the
API.
Is this theoretical, or a reality? Write these down in requirements
document. Specify which events that should be able to listen to and why.
I think the indirection is important to reuse mechanisms
whithout wiring them with the protocol/component environment. We can use the HTTP Digest
mechanism, for example, inside a filter, jsp page, servlet or in a Valve or even share it
between projects.
Not possible. Because a filter would use HttpServletRequest/Response,
Valve would use something Catalina specific, Netty and Sun JDK HTTP
would have their own HTTP abstractions. Sure, write reusable helper
classes that accept the information you need to process, but what does a
generic callback system buy you?
About the callback stuff, as Pete said, it seems more like a
struct. And I agree. We are looking to change this concept.
I really think you guys need to focus on the requirements document. It
will flush out your design better and help you avoid the ditches you dug
yourself into with the old APIs.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com