[security-dev] [PicketBox 5] - Authentication API
Pedro Igor Silva
psilva at redhat.com
Tue Jul 31 20:50:15 EDT 2012
Pushed the examples to the PicketBox Quickstarts repo:
----- 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.
> Pedro Igor
> security-dev mailing list
> security-dev at lists.jboss.org
More information about the security-dev