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

[Pete Muir]

* 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