[security-dev] [PicketBox 5] - Authentication API

[Bill Burke]

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