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

[Pedro Igor Silva]

Hi Pete,

   Thanks for the feedback and tips. The documentation was also updated.

   About the examples, I'm moving all of them to the PicketBox Quickstarts project. There you can find more details about the implementations.

   You're right about the callback/struct behaviour. I agree it seems more like a struct than a callback. Actually, I started to work as callback but during the implementation things changed. I'll change this concept to make it more clear.

   About the fluent configuration, the idea is to provide something like ISPN (which you know very well). The actual impl is just an attempt to have some things working.

Regards.
Pedro Igor

----- Original Message -----
From: "Pete Muir" <pmuir at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: security-dev at lists.jboss.org
Sent: Tuesday, July 31, 2012 6:22:54 PM
Subject: Re: [security-dev] [PicketBox 5] - Authentication API

* In the first example, what is "authenticate" that you assert is not null? Without this, the example doesn't make much sense :-)
* You should show some usage of the handler in this example as well.
* In fact, looking at those examples I'm not sure how it is a callb, and not just a struct
* You gone for a pattern half-way towards fluent configuration with the configuration, which I've found is normally a really bad place to be. I would go the whole way:
** Have a mutable builder class, ConfigurationBuilder, which has the fluent methods to configure all of PicketBox, which has a build() method
** Have a Configuration class, which is immutable, and emitted by the build method
** Have a constructor or static factory method on PicketBoxManager which takes a Configuration object
  This means that we can now easily create immutable (thread safe) configuration objects which can be passed around. This scheme will also work very well with CDI producers.
* If mechanism, managers can be configured, then make sure you offer these as first class options on the Configuration e.g.
    configuration.authentication().userNamePasswordMechanism().allowBeavers() <-- works really nicely in IDEs
* What you've called an observer, I think is actually a callback
* You have an error in the SASL example, authenticate is not a local variable, and it's not complete (add javadoc to discuss missing methods?)

On 31 Jul 2012, at 21:01, Pedro Igor Silva wrote:

> Hi All,
> 
>    I would like to know your opinion about the authentication API that is being used by PicketBox 5.You can check an initial documentation here: https://docs.jboss.org/author/display/SECURITY/PicketBox+Authentication+API.
> 
>    We are considering some requirements during the construction of this API. They are as follows:
> 
>            - Easy-to-use and fast to get started;
>            - Flexible architecture providing ways to use different mechanisms like Username/Password, Digest, Certificates, SASL, etc;
>            - Unified authentication API.  Although you can use different mechanisms, the API usage is the same;
>            - Allow authentication using multiple stores: properties, databases, ldap, etc;
>            - Hide mechanism`s complexity from users. Users do not need to be aware of the complexities behind a specific mechanism;
>            - Environment agnostic. You can use it in a pure Java SE application and in a JEE/CDI environment as well;
>            - Challenge/Response design;
>            - Authentication Events. Users should be able to observe specific authentication events like pre/pos authentication, failures, etc.
>            - Auditing.    
> 
> Regards,
> Pedro Igor
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev