On 5/1/2013 5:08 AM, Shane Bryzak wrote:

> On 01/05/13 18:56, Darran Lofthouse wrote:

>> On 01/05/13 09:45, Shane Bryzak wrote:

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

>>>> 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.

>> That is what I am interested in hearing about - the example I am being
>> shown as the correct way to do this contains HTTP specific code.

>
> As I mentioned in my very last e-mail (which you wouldn't have read yet
> because I only hit the send button 30 seconds ago ;) the Credentials
> parameter can be used to pass state back from the CredentialHandler to
> the calling code.
>

>>
>> I should also mention, when it comes to the authentication / validation
>> there is actually no such thing as a digest credential - what there
>> actually is is a response to a challenge, this response will then
>> potentially be different for every message received from the remote client.

>
> You'll need to forgive me because my digest-fu is rusty after not having
> used it for a few years, however I don't think this should be a
> problem.  If you can describe:
>
> a) the parameters that go in,
> b) the stored "secret" information that we need for the user,
> c) the processing that has to occur with a) and b), and
> d) the state that goes out,
>
> then I'm certain we can implement this as a CredentialHandler.
>

Sure you can implement it.  I think we've proved with JAAS that you can 
basically hack whatever you need.  But What you're describing Shane is a 
hack to get around the inadequacies of the IDM API.  If it is possible 
to pass state via the credentials object, then this credential 
protection you speak of is a total and utter farse that just complicates 
the API.

So, basically, we're going to have to write protocol-specific Credential 
and CredentialHandlers, correct?  How will this look at deployment time? 
  At runtime?  Who registers the Handlers and the Credential->Handler 
mapping?  The IDM Subsystem config?  The domain config?  The web-app 
config?  All the above have an effect on class loader boundaries and the 
set up and configuration of class Modules and class loader visibility.