On 31/10/12 13:18, Bill Burke wrote:
>
>
> On 10/31/2012 6:32 AM, Sergey Beryozkin wrote:
>> On 30/10/12 20:49, Bill Burke wrote:
>>>
>>>
>>> On 10/30/2012 2:23 PM, Sergey Beryozkin wrote:
>>>> On 30/10/12 18:16, Bill Burke wrote:
>>>>>
>>>>>
>>>>> On 10/30/2012 6:28 AM, Sergey Beryozkin wrote:
>>>>>> On 29/10/12 21:27, Marek Potociar wrote:
>>>>>>> Yes, I meant specifically SSLContext and the related APIs
>>>>>>> (KeyManager,
>>>>>>> TrustManager ...)
>>>>>>>
>>>>>>> I did not have any specific APIs in mind when it comes to auth modes
>>>>>>> in general - there may be something more in JAAS, but i'm not
>>>>>>> extremely familiar with it...
>>>>>> JAAS is the server side thing. At the client side, what can be
>>>>>> handy, is
>>>>>> to introduce a property (as Bill suggested), something like
>>>>>>
>>>>>> "client.authenticator" which will map to ClientAuhenticator
>>>>>> interface,
>>>>>> and JAX-RS will offer few well-known imlpementations, I would
>>>>>> limit it
>>>>>> to BasicClientAuhenticator for a start. and the runtime would do:
>>>>>>
>>>>>> String authorizationHeader =
>>>>>> get("client.authenticator").toAuthorizationHeader();
>>>>>>
>>>>>
>>>>> I really do not want to define a security SPI. IMO, we don't need
>>>>> one as
>>>>> filters/interceptors can pretty much implement anything. I just want a
>>>>> simple portable way to connect to and interact with Java EE servlet
>>>>> containers, i.e. support for HTTPS, Basic, Digest, Client-cert, and
>>>>> Form
>>>>> based authentication. I prefer a simple property-based approach, but
>>>>> would support a more type-safe interface as long as it didn't
>>>>> impose an
>>>>> implementation constraints.
>>>> Either approach is fine for me, I do not mind.
>>>>
>>>> Now, as far as Form is concerned, how interoperable is that, and what
>>>> exactly a client can do about if it is cookie based (this is what I
>>>> know
>>>> about it)?
>>>>
>>>
>>> The servlet spec defines the form parameters the login.html form must
>>> have. It also defines the name of the cookie if that is the tracking
>>> mechanism.
>>>
>>>> Actually, the point about SPI, it does not have to be SPI, just simple
>>>> optional registration from the code only. Whatever the client chooses,
>>>> it all ends up in HTTP Authorization, as far as the authentication is
>>>> concerned
>>>>
>>>
>>> I just didn't like your example of defining an authorization header
>>> method. I think many of us delegate to Apache Client 4 for auth.
>>>
>>
>> Sure, let the individual implementations decide how the authentication
>> is managed, I just don't want the fact that some stacks may prefer to
>> delegate to some embedded HTTP one affect the overall approach.
>>
>
> That's my point. With properties, or config objects, you don't care how
> it is implemented.
>
>> I guess the question is, if we were to go the untyped way, how to group
>> the properties correctly, given that every authentication scheme has its
>> own requirements/rules. Should we go half-way and offer a support for
>> Basic/Digest or offer a mechanism to get Spnego supported, etc.
>>
>> AFAIK, Apache HTTP client offers a superior support for NTLM, but most
>> other mechanisms can be managed without it, as I said, ultimately it is
>> about populating Authorization header.
>>
>
> Client-cert does not involve authorization headers.
Agreed, it is at a lower level though, so support for populating
Authorization headers is orthogonal
> Neither does OAuth2.
It does
> But, its more than authorization. Any JAx-RS 2.0 client that wants to
> talk HTTPS will require some kind of trust-manager configuration.
Agreed, but again, it is an orthogonal issue
Cheers, Sergey
>