I still would prefer a mechanism to directly get these request properties
(especially X509 client certs) on the JAX-RS level without new high level
identity APIs.
Cheers,
Reto
On Thu, May 2, 2013 at 11:31 AM, Werner Keil <werner.keil_at_gmail.com> wrote:
> Not sure, if we can reply to this mailing list, but I'll try.
>
> For JAX-RS 2.x and JavaEE 8 stay tuned, there should certainly be a new
> JSR for Identity Management touching authentication and SSO also with other
> JSRs like this one.
>
> So there will be more generic Auth-Header support in JavaEE very soon.
>
>
> --
>
> Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
> Language Champion | Java Godfather
>
> Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
> * Eclipse Stammtisch: May 15 2013, Zurich, Switzerland. Werner Keil, UOMo
> Lead, JSR 360 EG Member will present "M4M 2 the Rescue of M2M"
>
> * GeeCON: May 16-17 2013, Krakow, Poland. Werner Keil, JCP Executive
> Committee Member, JSR 360 EG Member will present "Standards for the
> Future of Java Embedded"
>
> * GR8Conf Hackergarten: May 22 2013, Copenhagen, Denmark. Werner Keil, JCP
> EC Member, JSR 354 EG Member will present "Groovy/Grails - Best way
> for Money using JSR 354"
>
> On Thu, May 2, 2013 at 11:15 AM, <users-request_at_jax-rs-spec.java.net>wrote:
>
>> Table of contents:
>>
>> 1. [jax-rs-spec users] [jsr339-experts] Re: The origin of
>> MessageBodyWriter - when to check - Sergey Beryozkin <
>> sberyozkin_at_talend.com>
>> 2. [jax-rs-spec users] [jsr339-experts] Why is there no generic
>> Auth-Header support in JAX-RS? - Jan Algermissen <
>> jan.algermissen_at_nordsc.com>
>> 3. [jax-rs-spec users] Re: [jsr339-experts] Why is there no generic
>> Auth-Header support in JAX-RS? - Reto Bachmann-Gmür <reto_at_gmuer.ch>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Sergey Beryozkin <sberyozkin_at_talend.com>
>> To: <jsr339-experts_at_jax-rs-spec.java.net>
>> Cc:
>> Date: Wed, 1 May 2013 10:47:12 +0100
>> Subject: [jax-rs-spec users] [jsr339-experts] Re: The origin of
>> MessageBodyWriter - when to check
>> Hi Santiago
>> On 26/04/13 13:55, Santiago Pericas-Geertsen wrote:
>>
>>> Hi Sergey,
>>>
>>> It's a bit difficult to comment on this without looking at the test.
>>> Is this a TCK test that you're referring to? If so, which one?
>>>
>>> Sorry for a delay. It's indeed a TCK test but I did not want to use the
>> list to discuss the specific TCK tests (I'd follow a proper procedure for
>> challenging the individual tests) but rather keep the question more in
>> 'scope' for this list, and besides I guess I can not even do that as I've
>> signed NDA :-)
>>
>> However we've talked about this issue before, so here is my question in
>> some other words:
>>
>> - custom Application registers a custom provider, typed like this:
>>
>> public class MyProvider implements MessageBodyReader<Object>,
>> MessageBodyWriter<Object> {
>> public boolean isReadable(Class c, ...) {
>> return InputStream.class.**isAssignableFrom(c);
>> }
>> public boolean isWriteable(Class c, ...) {
>> return InputStream.class.**isAssignableFrom(c);
>> }
>> }
>>
>>
>>
>> I honestly do not see how the 2.0 spec text can make a
>> standard/pre-packaged InputStream provider preferred to MyProvider above
>> when a resource method expects InputStream.
>>
>> The spec needs to specific about the order of the 'origin' key (custom vs
>> pre-packaged) and furthermore, IMHO, it has to do an explicit text about
>> the pre-packaged provider taking a precedence in some cases, because the
>>
>> "primary key of generic type where providers
>> whose generic type is the nearest superclass of the object class are
>> sorted first and a secondary key of
>> media type" condition does not work because there's no spec requirement
>> that pre-packaged providers have to be typed on InputStream, etc, as
>> opposed to just 'Object'
>>
>> What do you think ?
>> Sergey
>>
>> -- Santiago
>>>
>>> On Apr 25, 2013, at 11:01 AM, Sergey Beryozkin<sberyozkin_at_talend.**com<sberyozkin_at_talend.com>>
>>> wrote:
>>>
>>> Hi Santiago, All,
>>>>
>>>> The specification says:
>>>>
>>>> "An implementation MUST support application-provided entity providers
>>>> and MUST use those in prefer-
>>>> ence to its own pre-packaged providers when either could handle the
>>>> same request.
>>>> "
>>>>
>>>> We have a failing test. An application provider, typed on Object, is
>>>> written to support some specific types like Boolean, InputStream, etc, and
>>>> its isWritebale& isReadable checks that a given Object is of the supported
>>>> type and returns true if yes, false if not.
>>>>
>>>> The test still expects that the shipped/pre-packaged provider
>>>> (presumably typed for example on Boolean or InputStream) is chosen.
>>>>
>>>> The question boils down to what is the order of the 'origin' key. Does
>>>> the specification mean that it is a tertiary key ? If yes then I'm
>>>> accepting the test is valid, if not - concluding it is not.
>>>>
>>>> Thanks, Sergey
>>>>
>>>
>>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Jan Algermissen <jan.algermissen_at_nordsc.com>
>> To: "jsr339-experts_at_jax-rs-spec.java.net" <
>> jsr339-experts_at_jax-rs-spec.java.net>
>> Cc:
>> Date: Wed, 1 May 2013 13:55:18 +0200
>> Subject: [jax-rs-spec users] [jsr339-experts] Why is there no generic
>> Auth-Header support in JAX-RS?
>> Hi experts,
>>
>> given that HTTP Authorization and WWW-Authenticate header syntaxes are
>> defined in a generic way, independent of any specific Auth-Scheme, I wonder
>> what the reason is that there is no support in the API for these headers.
>> (E.g. there is for Cookie and Cache-Control and Link for example)
>>
>> Can anyone remember the reason?
>>
>> It's quite painful to implement and everybody seems to roll their own.
>> Most of what I see out there is wrong and/or relies on a zillion of regexes
>> - quite a bad situation.
>>
>> In addition, it would really help code clarity if Auth 'objects' would be
>> integrated into the API, e.g. via injection of an AuthInfo or similar.
>>
>> Is this something for 2.1, maybe?
>>
>>
>> Jan
>>
>> ---------- Forwarded message ----------
>> From: "Reto Bachmann-Gmür" <reto_at_gmuer.ch>
>> To: jsr339-experts_at_jax-rs-spec.java.net, users_at_jax-rs-spec.java.net
>> Cc:
>> Date: Thu, 2 May 2013 07:43:23 +0200
>> Subject: [jax-rs-spec users] Re: [jsr339-experts] Why is there no generic
>> Auth-Header support in JAX-RS?
>> Hi Jan
>>
>> From the comment on issue 43 it seems that the experts want to keep
>> everything out of the spec for now that is somehow related to
>> authentication.
>>
>> While for the header you're mentioning this is a nuisance this is a
>> blocker for the X509 certificates (issue 43) as support for these cannot be
>> implemented at all in a JAX-RS application unless using some implementation
>> specific method (such as by relying on the fact that the implementation is
>> servlet based).
>>
>> My plea would be to add all the needed low-level authentication support
>> before and independently on whatever high level security API future version
>> might bring. (Which I'm not sure if it's needed anyway as the standard
>> Java-AccessController mechanism can well be used in Jax-RS implementations).
>>
>> Cheers,
>> Reto
>>
>>
>> On Wed, May 1, 2013 at 1:55 PM, Jan Algermissen <
>> jan.algermissen_at_nordsc.com> wrote:
>>
>>> Hi experts,
>>>
>>> given that HTTP Authorization and WWW-Authenticate header syntaxes are
>>> defined in a generic way, independent of any specific Auth-Scheme, I wonder
>>> what the reason is that there is no support in the API for these headers.
>>> (E.g. there is for Cookie and Cache-Control and Link for example)
>>>
>>> Can anyone remember the reason?
>>>
>>> It's quite painful to implement and everybody seems to roll their own.
>>> Most of what I see out there is wrong and/or relies on a zillion of regexes
>>> - quite a bad situation.
>>>
>>> In addition, it would really help code clarity if Auth 'objects' would
>>> be integrated into the API, e.g. via injection of an AuthInfo or similar.
>>>
>>> Is this something for 2.1, maybe?
>>>
>>>
>>> Jan
>>
>>
>>
>> End of digest for list users_at_jax-rs-spec.java.net - Thu, 02 May 2013
>>
>>
>