jsr339-experts@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Mon, 29 Oct 2012 22:27:09 +0100

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

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