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

[Anil Saldhana]

Bill,
   the auth api was mainly done as a prototype for the AS guys. Your use 
cases may require direct access to the Identity Store. We support the 
direct usage as shown in the  http digest quickstart.

Regards,
Anil

On 08/01/2012 08:03 AM, Bill Burke wrote:
>
> 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
>