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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com