Hi Bill
On 15/12/14 12:14, Bill Burke wrote:
> Just like JAX-RS, Servlet spec is a standalone specification. There are
> many embeddable servlet implementations that can run in a "Java SE
> environment". We would be much better off working with JASPIC to create
> a JAX-RS binding.
>
> But I told you this earlier in the thread: pure JAX-RS does not need a
> security SPI. Filters work just fine both on the client and server.
>
You recommended adding a client side support for 2.0, it was not done
but you had some good ideas, right ?
IMHO a higher-level binding, possibly around the latest Security JSR
would be better, as opposed to working with JASPIC - binding to it can
be in itself an internal detail if needed...
Sergey
> On 12/14/2014 10:57 AM, Markus KARG wrote:
>> I would say this is a valid argument only if we restrict JAX-RS to
>> Java EE only (hence remove anything about Java SE as a platform from
>> the spec), which is not planned AFAIK. As this is not the case, it is
>> comparing apples with oranges as Servlet spec does _not_ say that a
>> Servlet can run on Java SE.
>>
>>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke_at_redhat.com]
>> Sent: Sonntag, 14. Dezember 2014 14:16
>> To: jsr370-experts_at_jax-rs-spec.java.net
>> Subject: Re: JAX-RS Security
>>
>> The servlet spec doesn't have its own security SPI either. Having
>> multiple ways to do the same thing is not conducive to the platform as
>> a whole IMO. The vast majority of JAX-RS developers run inside an EE
>> container. Any security SPI you would propose to JAX-RS would have to
>> take into the fact it needs to integrate with a Java EE environment
>> and you would just be redoing work already done by specs like JASPIC.
>>
>>
>> On 12/14/2014 3:11 AM, Markus KARG wrote:
>>> You still didn't get the point. When you want to use JASPIC with Java
>>> EE but JAX-RS filters without, then your are forcing the deployer to
>>> repackage the application, which voids the WORA principle. To prevent
>>> that, annotations and / or an API is needed, which is unambiguous to
>>> the application vendor, but that automatically uses either JASPIC or
>>> JAX-RS filters at runtime _without_ enforcing a repackaging. Instead,
>>> the JAX-RS container decides which technology to use under the hood.
>>>
>>> -----Original Message-----
>>> From: Bill Burke [mailto:bburke_at_redhat.com]
>>> Sent: Sonntag, 14. Dezember 2014 01:54
>>> To: jsr370-experts_at_jax-rs-spec.java.net
>>> Subject: Re: JAX-RS Security
>>>
>>> Since this is an EE 8 spec, then use an EE 8 API: JASPIC. If you are
>>> not running in Java EE, JAx-RS filter works just fine. If you want
>>> everything to run in JAX-RS and create Servlet.next, that's probably
>>> just not going to fly, IMO.
>>>
>>> On 12/13/2014 1:06 PM, Markus KARG wrote:
>>>> The problem is the WORA principle: Application vendors (like me) do
>>>> not know what platform is underlying the JAX-RS container at
>>>> runtime. Our application for example might be run on Java SE, pure
>>>> Servlet containers, or full Java EE server -- without knowing it. So
>>>> how should it find out which filter to apply just to get the needed
>>>> security?
>>>>
>>>> -----Original Message-----
>>>> From: Bill Burke [mailto:bburke_at_redhat.com]
>>>> Sent: Samstag, 13. Dezember 2014 15:14
>>>> To: jsr370-experts_at_jax-rs-spec.java.net
>>>> Subject: Re: JAX-RS Security
>>>>
>>>> You don't really need a specific API for security on the client as
>>>> Filters can implement it fine. On the server there are a few issues
>>>> though:
>>>>
>>>> * Getting client IP address is needed in some security solutions
>>>> * Getting client certificate is needed in some security solutions
>>>> * There is no way to override and propagate principal/role mappings
>>>> (SecurityContext) to other nested component calls.
>>>>
>>>> All this is really for pure JAX-RS. With Java EE there is JASPIC
>>>> that allows you to plug in your own providers. It might be
>>>> interesting to offer a JAX-RS binding for this, but it already has
>>>> one for servlets.
>>>>
>>>> On 12/13/2014 8:54 AM, Markus KARG wrote:
>>>>> Thank you for that explanation. In fact I always assumed that due
>>>>> to JAAS' modular concept it would be possible to provide some JAAS
>>>>> module to the client which under the hood does OAuth. Maybe I was
>>>>> wrong with that, but as you seem to be an expert with that, I'd
>>>>> like you to check this before we invent something completely new.
>>>>>
>>>>> Regards
>>>>> -Markus
>>>>>
>>>>> -----Original Message-----
>>>>> From: Casey Lee [mailto:cplee_at_nektos.com]
>>>>> Sent: Samstag, 13. Dezember 2014 01:19
>>>>> To: jsr370-experts_at_jax-rs-spec.java.net
>>>>> Subject: Re: JAX-RS Security
>>>>>
>>>>> Fair question. Let's consider client side first. For
>>>>> authentication, JAAS provides a pluggable way of collecting the
>>>>> credentials from the user. However with OAuth 2.0, we don't want
>>>>> the client app to collect the credentials...we want the client app
>>>>> to redirect the resource owner to an authorization server to
>>>>> authenticate and grant access to the client app. I don't think
>>>>> this type of authorization on the client side lines up with JAAS.
>>>>>
>>>>> On the server side, I think there is more opportunity for
>>>>> integration, ideally with the annotations that are already
>>>>> available. Another challenge though is that OAuth brings another
>>>>> party to the transaction. Rather than just AuthN/AuthZ of the
>>>>> client by the resource, we also have to AuthZ the resource owner
>>>>> who is using the client. Specifically, we need to authorize that
>>>>> the resource owner has access to the resource AND that the client
>>>>> has been granted access to the resource on behalf of the resource
>>>>> owner.
>>>>>
>>>>> I don't want to reinvent the wheel if it's already there...I'll
>>>>> give JAAS another look and see if any other folks are having better
>>>>> luck with using it with OAuth 2.0.
>>>>>
>>>>> -Casey
>>>>>
>>>>> On Fri, Dec 12, 2014 at 2:45 PM, Markus KARG
>>>>> <markus_at_headcrashing.eu> wrote:
>>>>>> Casey,
>>>>>>
>>>>>> I am not a security guy at all, so please don't mind if the
>>>>>> question is dumb, but doesn't JAAS already define interfaces for
>>>>>> authentication providers? If so, we could use those instead of
>>>>>> reinventing the wheel.
>>>>>>
>>>>>> Regards
>>>>>> -Markus
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Casey Lee [mailto:cplee_at_nektos.com]
>>>>>> Sent: Freitag, 12. Dezember 2014 17:53
>>>>>> To: jsr370-experts_at_jax-rs-spec.java.net
>>>>>> Subject: JAX-RS Security
>>>>>>
>>>>>> I have some opinions on opportunities for adding security to JAX-RS.
>>>>>> First, on the client side I'd love to see a method added to
>>>>>> Invocation.builder to add an implementation of a new interface
>>>>>> named AuthorizationProvider. This would allow implementations of
>>>>>> AuthorizationProvider to be created for specific types of
>>>>>> authz...like OAuth2AuthorizationProvider or
>>>>>> BasicAuthorizationProvider. These providers would be responsible
>>>>>> for applying necessary Authorization header (or query params?) to
>>>>>> the invocation. What are the thoughts on adding some standard
>>>>>> providers to the API? OAuth 2.0 for example is something that has
>>>>>> become ubiquitous, but has a steep learning curve for developers
>>>>>> to use properly.
>>>>>>
>>>>>> On the server side aren't the JSR-250 security annotations
>>>>>> supported by JAX-RS? Or is that only implemented by some specific
>>>>>> vendors?
>>>>>> Seems that those solve course grained security (by role). We have
>>>>>> chosen to leverage those annotations and treat OAuth 2.0 scopes as
>>>>>> roles. Would it make sense to have a more OAuth 2.0 specific
>>>>>> solution (@ScopesAllowed)?
>>>>>>
>>>>>> -Casey
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>