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

[Bill Burke]

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?

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

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.



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