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

[Anil Saldhana]

Bill,
   there are some indirections that need to be eliminated as you have 
pointed out.  Thanks for the feedback.

Regards,
Anil

On 08/01/2012 07:26 PM, Bill Burke wrote:
>
> 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
>