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

[Pedro Igor Silva]

----- 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 
> propagation.

> 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.

Regards.
Pedro Igor

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.
>>
>> Regards,
>> Pedro Igor
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev