Download pdf - Securing JAX-RS RESTful services

Securing JAX-RS RESTful services Miroslav Fuksa (software developer) Michal Gajdoš (software developer)

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 2

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.


Program Agenda

§  Introduction to JAX-RS and Security

§ Declarative Security and Entity Filtering

§ Client Security

§ OAuth 1

§ OAuth 2


Introduction to JAX-RS and security


Introduction

§ Representation State Transfer § Using HTTP methods GET, POST, DELETE ... §  representations (HTML, JSON, XML), URI, caching, stateless … §  JAX-RS: Java API for RESTful Services § JAX-RS 2.0 (JSR 339): Java EE 7, released in May 2013 § Reference implementation: Jersey 2

RESTful Web Services


Introduction @Path("student")

public class StudentResource {

@Produces("application/json")

@GET

@Path("{id}")

public Student get(@PathParam("id") String id) {

return StudentService.getStudentById(id);

}

@POST

public Student post(Student student) {

return StudentService.addStudent(student);

}

}

GET http://my-univeristy.com/api/student/adam

POST http://my-univeristy.com/api/student

http://my-univeristy.com/api/student/


Introduction

§  JAX-RS 2.0 (JSR 339, part of Java EE 7, released in May 2013) –  Client API –  Asynchronous processing –  Filters –  Interceptors

JAX-RS 2.0


Introduction

§ Authentication –  HTTP Basic Authentication (BASE64 encoded username and password →

SSL) –  HTTP Digest Authentication (password is used only for signature, MD5)

§ Authorization

Security


Servlet Container Security

Secure JAX-RS services using Servlet Container <security-constraint>

<web-resource-collection>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<auth-constraint>

<role-name>admin</role-name>

</auth-constraint>

</security-constraint>

<login-config>

<auth-method>BASIC</auth-method>

<realm-name>my-realm</realm-name>

</login-config>



Secure JAX-RS services using Servlet Container <security-constraint>


<url-pattern>/student/*</url-pattern>

<http-method>POST</http-method>


<auth-constraint>


</auth-constraint>


<security-constraint>


<url-pattern>/student/*</url-pattern>

<http-method>GET</http-method>


<auth-constraint>


<role-name>user</role-name>

</auth-constraint>


http://my-univeristy.com/api/students/{id}



§  Advantages –  Independent on JAX-RS implementation –  managed by servlet container

§ Disadvantages –  only for servlet containers –  fragile, verbose, bad maintenance –  Pre-matching filters

Secure JAX-RS services using Servlet Container


Pre-matching filters

Pre-matching filter

PUT http://my-univeristy.com/api/student

POST http://my-univeristy.com/api/student


JAX-RS Security Context

javax.ws.rs.core.SecurityContext

public interface SecurityContext {

public Principal getUserPrincipal();

public boolean isUserInRole(String role);

public boolean isSecure();

public String getAuthenticationScheme();

}


JAX-RS Security Context

Secure method programmatically using SecurityContext @Path("student")

public class StudentResource {

@Context

private SecurityContext securityContext;

@GET

@Path("{id}")

public Student get(@PathParam("id") String id) {

if (!securityContext.isUserInRole("admin")) {

throw new WebApplicationException(”You don’t have privileges to access this resource.", 403);

}

return StudentService.getStudentById(id)

}

}


Authorization in Jersey 2.x: Security annotations


Authorization – Security annotations.

§ Define the access to resources based on the user groups. § Security annotations from javax.annotation.security package.

–  @PermitAll, @DenyAll, @RolesAllowed –  SecurityContext

§ RolesAllowedDynamicFeature.

Means in Jersey 2.x



@ApplicationPath(“api”)

public class MyApplication extends ResourceConfig {

public MyApplication() {

packages(“my.application”);

register(RolesAllowedDynamicFeature.class);

}

}

Example: Register RolesAllowedDynamicFeature.



@Path("/resource")

@PermitAll

public class Resource {

@GET

public String get() { return "GET"; }

@RolesAllowed("admin")

@POST

public String post(String content) { return content; }

}

Example: Define access restrictions on Resource.


Authorization in Jersey 2.x: Entity Filtering Feature


Feature: Entity Filtering

§ Exposing only part of domain model for input/output. § Reduce the amount of data exchanged over the wire. § Define own filtering rules based on current context.

–  Resource method. § Assign security access rules to properties. § Faster prototyping and development.

–  One model and one place for defining the rules.

Idea and Motivation



§ @EntityFiltering meta-annotation. –  Create filtering annotations to define context. –  Create filtering annotations with custom meaning to define context.

§ Security annotations from javax.annotation.security package. –  @PermitAll, @DenyAll, @RolesAllowed –  SecurityContext

Means in Jersey 2.3+ / MOXy 2.5.0



§ Define dependencies on extension and media modules. § Register SecurityEntityFilteringFeature in Jersey Application. § Annotate Resources and Domain Model with security annotations. § Enjoy!

Putting it all together.



§ Have: –  JAX-RS Application with security user roles.

§ Want: –  Define access to resources. –  Restrict access to entities / entity members for different user roles.

Example: Goal.



@ApplicationPath(“api”)

public class MyApplication extends ResourceConfig {

public MyApplication() {

packages(“my.application”);

register(SecurityEntityFilteringFeature.class);

}

}

Example: Register Providers in JAX-RS Application.



public class RestrictedEntity {

private String simpleField;

private String denyAll;

private RestrictedSubEntity mixed;

// getters and setters

}

Example: Model. public class RestrictedSubEntity {

private String managerField;

private String userField;

// getters and setters

}



public class RestrictedEntity {

public String getSimpleField() { ... }

@DenyAll

public String getDenyAll() { ... }

@RolesAllowed({"manager", "user"})

public RestrictedSubEntity getMixed() {}

}

Example: Annotated Domain Model. public class RestrictedSubEntity {

@RolesAllowed("manager")

public String getManagerField() { ... }

@RolesAllowed("user")

public String getUserField() { ... }

}



@Path("unrestricted-resource")


public class UnrestrictedResource {

@GET

public RestrictedEntity getRestrictedEntity() { ... }

}

Example: JAX-RS Un-Restricted Resource.



@Path("restricted-resource")


public class RestrictedResource {

@GET @Path(”denyAll")

@DenyAll

public RestrictedEntity denyAll() { ... }

@GET @Path("rolesAllowed")

@RolesAllowed({"manager"})

public RestrictedEntity rolesAllowed() { ... }

}

Example: JAX-RS Restricted Resource.


JAX-RS Client Security


Client Security

§  JAX-RS 2.0 defines support for SSL configuration §  javax.ws.rs.client.ClientBuilder

–  KeyStore, TrustStore, SSLContext §  Jersey provides SslConfigurator to create SSLContext

SSL with JAX-RS support


Client Security

SslConfigurator sslConfig = SslConfigurator.newInstance()

.trustStoreFile("./truststore_client")

.trustStorePassword("pwds65df4")

.keyStoreFile("./keystore_client")

.keyPassword("sf564fsds");

SSLContext sslContext = sslConfig.createSSLContext();

Client client = ClientBuilder.newBuilder()

.sslContext(sslContext).build();

SslConfigurator


Client Security

§ ClientRequestFilter and ClientResponseFilter §  Jersey HttpAuthenticationFeature

–  Basic, Digest, Universal

Http Authentication

HttpAuthenticationFeature basicAuth = HttpAuthenticationFeature.basic("username”,"12345");

Client client = ClientBuilder.newBuilder().register(basicAuth).newClient();

Student michal = client.target("http://my-university.com/student/michal") .request().get(Student.class);


OAuth 1


OAuth: introduction

username/password

Consumer

Service Provider

Resource owner


OAuth

§  I want to give an access to my account to consumer (3rd party application)

§ Give Consumer my password –  Revoking access –  Password change –  Limit access (different authorization rules) –  Trust

Motivation


OAuth: introduction

username/password

Consumer

Service Provider

Resource owner


OAuth

§ OAuth –  No resource owner’s password sharing –  Resource owner can revoke an access at any time –  Limited access –  User friendly process of issuing tokens (Authorization Process/Flow)

Motivation


OAuth1

§  IETF OAuth 1.0 (RFC 5849) –  Previous community version 1.0 and 1.0a

§ Signatures added to requests (HMAC-SHA1, RSA-SHA1) based on secret keys

§ Authorization process (flow) –  Process of granting access to the consumer

§ Authenticated requests –  Consumer calls REST APIs using OAuth signatures

Details


OAuth1: Authorization flow

1

1 Request Token 2 Authorization Request 3 Resource owner authorization 4 Authorization Response 5 Access Token

2

3

4

5

Consumer

Service Provider

Resource owner


OAuth1: Authenticated requests

Consumer

Service Provider

Resource owner

Access Token


OAuth1

§ Secure –  Signatures –  Secret keys (consumer secret, request and access token secret) –  nonce, timestamp

§ Complex for implementation

Summary


OAuth 2


OAuth 2

§ WRAP (Web Resource Authorization Protocol) § OAuth 2.0 (IETF, RFC 6749), released in October 2012 § Not backward compatible, framework (not protocol) § Does not require signatures (bearer token), SSL § Authorization flows

–  Authorization Code Grant (refresh token) –  Implicit Grant (eg. Javascript client), Resource Owner Password

Credentials Grant (user name + password), Client Credentials Grant (client app authentication)

Introduction


OAuth 2

§ Easier implementation –  OAuth 1.0a is not easy to implement

§ Security questions –  no signature and no secret keys (risk of exposing tokens) –  SSL –  usage of authorization flows with limited security

Compared to OAuth 1


OAuth

§ OAuth 1.0a: client and server § OAuth 2: client (Authorization Code Grant) § Client OAuth support:

–  Authorization Flow: standalone utility –  Authenticated requests (Features => Filters)

Jersey and OAuth


OAuth 2

§  server application that uses JAX-RS client to get and show Google tasks of any user that authorizes the application

Demo


Resources

§  Securing JAX-RS Resources –  https://jersey.java.net/documentation/latest/security.html#d0e8866

§  Entity Filtering in Jersey –  https://jersey.java.net/documentation/latest/entity-filtering.html –  https://github.com/jersey/jersey/tree/master/examples/entity-filtering

§  OAuth specification –  http://tools.ietf.org/html/rfc5849 –  http://tools.ietf.org/html/rfc6749

§  OAuth 2 sample –  https://github.com/jersey/jersey/tree/master/examples/oauth2-client-google-webapp

§  Jersey –  http://jersey.java.net


Questions & Answers