JSON WS Security

General Blogs February 19, 2014 By Tomas Polesovsky Staff

Hello Friends! 
 
I see some confusion around remote services' endpoints security. Here are some tips ...
 
--== Starting with 6.1.20 (EE) and 6.1.1 (CE) authentication is mandatory ==--
When you do need to make a service/method public look at:
6.1 ... json.service.public.methodsjsonws.web.service.public.methods in portal.properties
6.2 ... @AccessControlled advice ... example use from UserService
 
--== NEVER EVER DISABLE auth.token.check.enabled + json.service.auth.token.enabled ==--
p_auth token is CSRF token, it does NOT represent any credentials. It's jsessionid cookie that associates a browser with the user (authenticated) session.
 
To access JSON WS from your JavaScript application follow Cross-origin resource sharing (CORS) spec. It's safer than disabling whole CSRF protection and can be configured on a web server level. A dummy example how to safely offer p_auth to your remote JS app.
 
To whitelist a method or service in 6.2 use auth.token.ignore.origins, example:
auth.token.ignore.origins=\
    com.liferay.portal.jsonwebservice.JSONWebServiceServiceAction:/user/get-user-by-email-address
 
--== Portal cookies belong to the portal context ==--
To access custom services from JavaScript call services through portal web application context (/api/jsonws/my-portlet.service/method), don't use the plugin context (/my-portlet/api/jsonws/service/method). 
 
Every web application deployed on the server has different session with different jsessionid value. Authenticated portal session will not be accessible from the plugin context.
 
For more details see JSON WS plugins mapping.
 
--== Use preemptive authentication with HTTP Basic in 6.2 ==--
In 6.2 portal authentication layer has been rewritten to support wider range of authentication options. This means you can access one service using more auth. schemes => portal will not send you HTTP Basic/Digest challenge.
 
 
--== Don't use HTTP Basic auth from JavaScript ==--
Do not write login + password into HTML page or require user to type it.
 
--== Use HTTPS. Everywhere ==--
HTTPS mitigates many risks related to transfering data and is very effective in terms of cost/gain.
 
Don't run unsecured HTTP together with HTTPS. There's more pain than gain with mixed content warnings and proper configuration. Rather use only HTTPS and declare HTTP Strict Transport Security (HSTS) in your web server configuration (or use HSTS plugin from marketplace). The hard-code fans may close port 80 :) #joke
 
And talking about all the BEASTs, CRIMEs, BREACHes, compressions, perfect forward secrecies, agencies and others: tune your server configuration. I use https://www.ssllabs.com/ssltest/
Showing 1 result.