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

[Bill Burke]

My use cases are low priority...but...still...This all smells like JAAS 
next-gen.  I don't think the whole callback mechanism and the whole 
AuthenticationClient and AuthenticationService interfaces add much.  I 
don't think an uber generic abstraction will work and we'll end up 
having the same exact frustrations that current exist.

Again, I ask the question, what value-add does this API give you other 
than forcing multiple levels of indirection?  Focus on apis that we 
actually need: user metadata store and permission/subject/roles propagation.

On 8/1/12 10:33 AM, Anil Saldhana wrote:
> 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
>>
>
> _______________________________________________
> 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