Service Access Policy - how to apply it

thumbnail
Pete Helgren, modified 6 Years ago. Regular Member Posts: 225 Join Date: 4/7/11 Recent Posts
I thought I had things locked down on my portlet using this guide from the Knowledge base: https://portal.liferay.dev/docs/7-0/deploy/-/knowledge_base/d/service-access-policies  I am using the " IP permission layer: " approach.  I added the whitelisted IP to these two entries in portal.properties file:


    #
    # See the properties "main.servlet.hosts.allowed" and
    # "main.servlet.https.required" on how to protect this servlet.
    #
    jsonws.servlet.hosts.allowed=xxx.xxx.xxx.xxx, 127.0.0.1, SERVER_$
    jsonws.servlet.https.required=false

    json.servlet.hosts.allowed=xxx.xxx.xxx.xxx, 127.0.0.1, SERVER_IP
    json.servlet.https.required=false


My IP in this case represented by the xxx.xxx.xxx.xxx

If I call the API remotely like this: https://api.mydomain.org/api/jsonws/mycore.lesson/get-lesson-resources/class-number/98765/locale-cd/en/lang/en  Then I get an error message:

"Access denied to org.mydomain.api.core.service.LessonService#getLessonResources"

The method is listed in the Allowed Service Signatures list.  The ONLY way so far to get access to the API is to use the "Default" on the service access policy.  Then I can get a JSON response with the content from the api.

So, am I doing this wrong?  Are the "Layers" described in the knowledge base ALL needed?  Do I need something in addition to the IP entries in portal-ext.properties?

It seems like it should be simple, but I am not getting it sorted out....

Liferay 7.0 GA5
thumbnail
David H Nebinger, modified 6 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Those properties are not related to the service access policies.

They are overall controls over where connections can be established from. They are extremely blunt instruments that dictate what IPs can connect.

The linked documentation tells how you can define a service access policy of your own from within the control panel, not via portal-ext.properties.
thumbnail
Pete Helgren, modified 6 Years ago. Regular Member Posts: 225 Join Date: 4/7/11 Recent Posts
OK.  I get the fact that portal-ext.propeties entries are blunt.  So what would be the next step?  I did add the IP to the whitelist, yet any IP can still connect, regardless of that entry.  I did restart LR after making that change.

So, IP restrictions do not appear to be enough.   The control panel settings on the Service Access Policy allow me add the methods I want to the "whitelist".  Done!  At the top of that page I see an "Enable" toggle and a "Default" toggle.  When  I enable the policy but do not toggle ON the "Default".  I cannot connect remotely to the API, even though my IP is whitelisted and the method is whitelisted.  When I toggle on "Default" I CAN  access the API remotely, but so can any other IP address on the planet.  So, the "Default" setting seems to override just about everything and let anyone access the API.

So, here are the steps as summaried in this knowledge base article:  https://portal.liferay.dev/docs/7-0/deploy/-/knowledge_base/d/securing-liferays-remote-services

  1. The IP address must be pre-configured in the server’s
    portal-ext.properties
    file.
  2. At least one service access policy which applies to the request must have the API function being invoked in a whitelist.
  3. If a browser is making the web service invocation request, a valid authentication token (
    p_auth
    URL parameter) must be provided.
  4. The user ID being used must have permission to access the resources it attempts to access.
#1 and #2 have been done.  #3 doesn't apply since this is not a call from a browser.  So the only remaining question is with #4.  Do I need to ALSO provide a USERID in order to access the API?

Thanks for your help with this. 
thumbnail
David H Nebinger, modified 6 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
I think if you don't have a p_auth token, you may need to use an alternate authentication mechanism such as the basic auth header.

The problem I have with the IP address filter is that, by turning it on, you affect the ability of the end user's browsers being able to invoke services back on the portal.

While there is probable some use cases for it, I'm not sure it works so well in the general cases...
thumbnail
Pete Helgren, modified 6 Years ago. Regular Member Posts: 225 Join Date: 4/7/11 Recent Posts
Thanks...

Hmmm.  OK  I tried that but perhaps I did it wrong.  I added the p_auth token to the end of the url like this:

https://api.mydomain.org/api/jsonws/mycore.lesson/get-lesson-resources/class-number/98765/locale-cd/en/lang/en /p_auth/MYTOKEN

I still get access denied when I toggle OFF the "Default" even though the method is whitelisted and the IP is whitelisted.

Not sure what the next step would be.  I wish there was a trace option so I could see where the security is failing.....