<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/01/2013 08:01 AM, Bill Burke
wrote:<br>
</div>
<blockquote cite="mid:51811240.1010905@redhat.com" type="cite">
<pre wrap="">
On 5/1/2013 5:08 AM, Shane Bryzak wrote:
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">> </span>On 01/05/13 18:56, Darran Lofthouse wrote:
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>> </span>On 01/05/13 09:45, Shane Bryzak wrote:
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>>> </span>On 01/05/13 16:46, Darran Lofthouse wrote:
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>>>> </span>but we also have requirements now moving beyond
<span class="moz-txt-citetags">>>>> </span>the account verification step. As I mentioned before we are now going
<span class="moz-txt-citetags">>>>> </span>to require code related to HTTP authentication in a CredentialHandler
<span class="moz-txt-citetags">>>>> </span>and we are going to require code related to SASL authentication in there.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">>>> </span>You don't <b class="moz-txt-star"><span class="moz-txt-tag">*</span>have<span class="moz-txt-tag">*</span></b> to put HTTP or SASL specific code in the
<span class="moz-txt-citetags">>>> </span>CredentialHandler implementation itself, there are ways to avoid this.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">>> </span>That is what I am interested in hearing about - the example I am being
<span class="moz-txt-citetags">>> </span>shown as the correct way to do this contains HTTP specific code.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>As I mentioned in my very last e-mail (which you wouldn't have read yet
<span class="moz-txt-citetags">> </span>because I only hit the send button 30 seconds ago <span class="moz-smiley-s3" title=";)"><span>;)</span></span> the Credentials
<span class="moz-txt-citetags">> </span>parameter can be used to pass state back from the CredentialHandler to
<span class="moz-txt-citetags">> </span>the calling code.
<span class="moz-txt-citetags">></span>
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>></span>
<span class="moz-txt-citetags">>> </span>I should also mention, when it comes to the authentication / validation
<span class="moz-txt-citetags">>> </span>there is actually no such thing as a digest credential - what there
<span class="moz-txt-citetags">>> </span>actually is is a response to a challenge, this response will then
<span class="moz-txt-citetags">>> </span>potentially be different for every message received from the remote client.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>You'll need to forgive me because my digest-fu is rusty after not having
<span class="moz-txt-citetags">> </span>used it for a few years, however I don't think this should be a
<span class="moz-txt-citetags">> </span>problem. If you can describe:
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>a) the parameters that go in,
<span class="moz-txt-citetags">> </span>b) the stored "secret" information that we need for the user,
<span class="moz-txt-citetags">> </span>c) the processing that has to occur with a) and b), and
<span class="moz-txt-citetags">> </span>d) the state that goes out,
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>then I'm certain we can implement this as a CredentialHandler.
<span class="moz-txt-citetags">></span>
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
Digest Authentication semantics makes it complex. It is the odd man
out.<br>
<blockquote cite="mid:51811240.1010905@redhat.com" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
Bill- the IDM subsystem is far down in the chain. It cannot start
thinking<br>
about the config happening in the web container and integrating
layers. You<br>
should definitely provide some examples via some pictures for the
people on<br>
the list. That way we get on the same page.<br>
<br>
If not, we will spend the next 30 years designing the perfect API.<br>
</body>
</html>