users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: security is a big hole in client API

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 30 Oct 2012 10:28:09 +0000

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();

Cheers, Sergey

>
> Marek
>
> On Oct 29, 2012, at 5:25 PM, Bill Burke<bburke_at_redhat.com> wrote:
>
>> You have specific Java SE APIs in mind? You mean KeyStore? TrustManager? Or other?
>>
>> On 10/29/2012 6:53 AM, Marek Potociar wrote:
>>> I think we should still try to do something in this space. It would be good if we could reuse as much of Java SE APIs as possible. Specifying user name and password as well as setting a SSL context should be the minimum we do.
>>>
>>> Marek
>>>
>>> On Oct 29, 2012, at 12:59 AM, Bill Burke<bburke_at_redhat.com> wrote:
>>>
>>>> Security configuration on the client side is really the only non-portable, undefined part of JAX-RS 2.0. Should we define something? Is it too late?
>>>>
>>>> * standard property names for username and password
>>>> * standard property name for authentication mode, maybe match servlet? BASIC, DIGEST, CLIENT_CERT, and FORM. FORM is a little weird, but the semantics are well defined and understood. No reasons we couldn't support it out of box.
>>>> * login URL for FORM authentication?
>>>> * Standard property for setting client certificate for CLIENT-CERT
>>>> * Ability to specify a trust-store through a property for HTTPS.
>>>>
>>>> Would just defining this set of common standard properties work? Seems simple enough, or am I missing something?
>>>>
>>>> Thoughts?
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>