[security-dev] [PicketBox 5] - Authentication API
Pedro Igor Silva
psilva at redhat.com
Tue Jul 31 20:48:06 EDT 2012
----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: security-dev at lists.jboss.org
Sent: Tuesday, July 31, 2012 7:26:58 PM
Subject: Re: [security-dev] [PicketBox 5] - Authentication API
> Bare with me for a second please...
> What exactly is a generic Authentication API buying you? What is the
> value in it? What exactly is it doing behind the scenes on the server?
> and on the client?
I prefer to think this API as a framework for building authentication for client and services. Providing some common capabilities like exception handling, event handling, authentication workflow, user stores integration, subject propagation, etc).
I pushed the examples to the PicketBox Quickstarts repo: https://github.com/picketbox/picketbox-quickstarts/tree/master/auth-api-examples.
> In the SASL example you gave it just seems weird to me that you are
> mixing a generic interface with a typed interface. You're tunneling
> information through a generic service, so why not just execute the SASL
> model directly?
I agree you can use SASL directly, but you`ll loose some capabilities provided by the API like: user validation using some specific data store (i think you call this security domain/storage), event handling and
others that we can plug and reuse between implementations.
> I just don't think a generic Authentication API is very useful, because,
> depending on the protocol (HTTP, WebSocket, proprietary socket), that
> particular protocol is going to have to build the response back to the
> client anyways. Also for things like HTTP Digest, authentication is
> very wire protocol specific and really cannot be encapsulated in a
> generic component.
I partially agree. Can you take a look at the HTTP Digest example ? https://github.com/picketbox/picketbox-quickstarts/blob/master/auth-api-examples/src/test/java/org/picketbox/core/test/authentication/HTTPDigestAuthenticationProviderTestCase.java
The service logic is the same used by the PicketBox "default" HTTP Digest implementation.
> So, what do I suggest? Split things into 3 distinct API sets: metadata,
> metadata processing helper classes, and Subject/Roles/Permission
> Metadata would be the SecurityDomain and a storage abstraction for
> security metadata. Helper classes are not part of a generic API, but
> instead are specific to the the metadata you want to process. Finally
> you need an API for defining and propagating Subject, roles, and
> permissions. All these things need to be separate, IMO, to give the
> greatest amount of flexibility for security protocol developers.
We are calling the SecurityDomain as AuthenticationManager. The AuthenticationManager is responsible for validating the user`s credential against a specific store (ldap, properties, database, etc). The other parts are being implemented.
Btw, the SASL example considers a simple scenario. That is why I opened the discussion, I'm sure there are more use cases to stress this design.
On 7/31/12 5:22 PM, Pete Muir wrote:
> * 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
> security-dev mailing list
> security-dev at lists.jboss.org
JBoss, a division of Red Hat
security-dev mailing list
security-dev at lists.jboss.org
More information about the security-dev