Hi,
On Sun, Dec 14, 2014 at 5:03 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
>
> I think there is a misunderstanding. What we try to get is a Security _API_, i. e. annotations that an application author is using to _declare_ what he expects the JAX-RS conainer to do. JASPIC is a Security SPI, i. e. it provides technology a JAX-RS container will make use of to _implement_ security.
I get what you mean, but would like to mention that an SPI is not an
implementation either, but rather a contract via which (in this case)
authentication decisions can be delegated to portable modules.
> It makes no sense to ask application authors to directly invoke the SPI, neither JASPIC nor JAAS.
Well, JASPIC also has an API via which application programmers can
install/register auth modules, not entirely unlike Servlet has an API
via which Servlets and Filters can be registered programmatically.
Granted, this API in its raw form is not suitable for general users,
but with some utility code one is able to do the following:
@WebListener
public class SamRegistrationListener extends BaseServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
Jaspic.registerServerAuthModule(new TokenAuthModule(),
sce.getServletContext());
}
}
See
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
As for the annotations you talk about, this is in fact if I understand
you correctly under discussion for the context of the entire Java EE
platform (see
https://java.net/jira/browse/JAVAEE_SPEC-9,
https://java.net/jira/browse/JAVAEE_SPEC-25 and
https://java.net/jira/browse/JAVAEE_SPEC-28) and I expect this to be
one of the primary focus points for the Security API (see e.g. the
authentication section here:
https://jcp.org/en/jsr/detail?id=375 and
the last few comments of JAVAEE_SPEC-9).
So where it concerns the declaration of which security services to use
I would recommend you to join the Security API discussion. Likely
there are many aspects that will be applicable to the entire platform.
Input from JAX-RS EG members will be great so that any specific
concerns that spec has can be taken into account (I for sure will at
least represent JSF in that discussion wherever needed).
Kind regards,
Arjan
>
>
>
> From: arjan tijms [mailto:arjan.tijms_at_gmail.com]
> Sent: Sonntag, 14. Dezember 2014 14:49
> To: users_at_jax-rs-spec.java.net
> Cc: markus_at_headcrashing.eu; Bill Burke
> Subject: Re: [jax-rs-spec users] Re: JAX-RS Security
>
>
>
> I agree with Bill here.
>
>
>
> It's maybe not that productive if JAX-RS duplicates many things that are already available in Java EE. The discussion is about security here, but doesn't it also hold for things like say validation and persistence? JAX-RS "standalone" applications that currently bundle Bean Validation and JPA already have to be re-packaged for Java EE. It's probably not the most efficient use of resources if JAX-RS defines its own annotations and API that are "unambiguous to the application vendor" for those.
>
>
>
> Taking this thinking to the extreme, wouldn't JAX-RS not become it's own Java EE eventually then?
>
>
>
> As for JASPIC, there are discussions going on about Servlet maybe adopting the Servlet Container Profile of JASPIC as its own native SPI (which incidentally is already a recommendation in the current Servlet spec).
>
>
>
> Kind regards,
>
> Arjan Tijms
>
>
>
>
>
> On Sun, Dec 14, 2014 at 2:15 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
> 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
>
>