4:22 p.m.
* 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev