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

Anil Saldhana Anil.Saldhana at redhat.com
Wed Aug 1 10:33:27 EDT 2012

   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.


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

More information about the security-dev mailing list