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

Wed Aug 1 18:35:26 EDT 2012

Hi Bill,

    I think one of the main things about this API is that when creating new mechanisms you focus only in its logic. The mechanism only needs to know how to extract the user's credentials (eg.: by using a specific protocol) and call an authentication manager (user metadata store) to validate its credentials. The user store is not hidden it is available during the authentication. Also, other aspects like subject creation/population/propagation are handled by PicketBox. I think you do not need to code that every time. Of course, the API may provide extensions for custom and specific behaviour.

    Another idea is allow multiple user stores during the user validation, that is configurable. We can also have some policy for the stores like stop in the first successful validation or require all stores to validate the user.

    I understand that exception,event handling and workflow are specific, but as the authentication is managed by PicketBox it can also help protocols and components to customize some behaviour by listening for certain events or extending the API.

    I think the indirection is important to reuse mechanisms whithout wiring them with the protocol/component environment. We can use the HTTP Digest mechanism, for example, inside a filter, jsp page, servlet or in a Valve or even share it between projects.

    About the callback stuff, as Pete said, it seems more like a struct. And I agree. We are looking to change this concept.

Regards.
Pedro Igor

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, August 1, 2012 11:47:23 AM
Subject: Re: [security-dev] [PicketBox 5] - Authentication API

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
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev