On 01/05/13 16:46, Darran Lofthouse wrote:

Hello all,

(I am going to send my response to the thread that continued overnight 
in a couple of different e-mails - adding many points to one message I 
think will get confusing.)

If we do have an API that meets our needs I am no against using it at 
all however at this point I am a little concerned we may be dropping 
into similar problems we ended up with around JAAS.  i.e. we start off 
with simple username / password verification so a username and a 
credential and then we start trying to add more complex scenarios which 
need more workarounds and end up having capabilities restricted.

I agree, however what we have already is far more flexible than JAAS ever was. We need to define these complex scenarios as specific use cases to ensure that the SPI provided by PicketLink is sufficient. I suggest you start a Google Doc (or something like that) which details each of the use cases so that we have a formal set of requirements.


Initially my understanding was PicketLink IDM was an identity manager, 
what we are now starting to talk about is it becoming a general purpose 
authentication manager -

PicketLink IDM has always supported credential management and authentication, this isn't a new concept [1].

but we also have requirements now moving beyond 
the account verification step.  As I mentioned before we are now going 
to require code related to HTTP authentication in a CredentialHandler 
and we are going to require code related to SASL authentication in there.

You don't *have* to put HTTP or SASL specific code in the CredentialHandler implementation itself, there are ways to avoid this.


Regards,
Darran Lofthouse.

[1] http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e1102