[security-dev] Undertow / IdentityManager and Digest Authentication

[Shane Bryzak]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130501/ef37886a/attachment.html