Letzte Blogger

Christine Reyes

Staff
1 Nachrichten
25. September 2016

Geert van der Ploeg

1 Nachrichten
20. September 2016

Olaf Kock

Staff
117 Nachrichten
20. September 2016

Antonio Pol

Staff
1 Nachrichten
19. September 2016

David H Nebinger

31 Nachrichten
15. September 2016

Javeed Chida

11 Nachrichten
15. September 2016

Jan Eerdekens

13 Nachrichten
14. September 2016

Nate Cavanaugh

Staff
39 Nachrichten
12. September 2016

Maarten van Heiningen

2 Nachrichten
5. September 2016

Melanie Chung

Staff
5 Nachrichten
2. September 2016

JSON WS Security

General Blogs 19. Februar 2014 Von 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/
Zeige 1 Ergebnisse.