8:03 a.m.
On 7/31/12 8:48 PM, Pedro Igor Silva wrote:
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: security-dev(a)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-e....
> 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-e...
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