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

[Bill Burke]

On 7/31/12 8:48 PM, Pedro Igor Silva wrote:
> ----- 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 dig deeper, but exception handling, event handling is often very 
specific to the wire protocol and component layer you're authenticating. 
  Authentication workflow can be very application specific and custom. 
Can you provide an example?  For user stores integration, instead of 
hiding it, expose the user store.  This is one of the main problems of 
the current picketlink.  Everything is so hidden, it is really really 
hard to do anything beyond what it is narrowly designed for.

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

Again, expose the store and do the validation in your protocol layer.

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

So, IMO, the user store should be exposed and separate from validation. 
  I'll look at your HTTP Digest example, but this is a perfect reason 
why validation in a generic service cannot be done.


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

You'd be better off writing down the requirements of each use case. 
Because right now, what you have just looks like fluent JAAS.  Same sort 
of unflexible model.

I'll try and put some pseudo code together.

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com