Authentication and authorization in REST Services with Liferay

后端 未结 4 1556
日久生厌
日久生厌 2020-12-18 09:29

We are building some services that will be exposed through a RESTful API. Primary customers of this API are Liferay portlets using Angular JS, meaning there are direct calls

4条回答
  •  暗喜
    暗喜 (楼主)
    2020-12-18 10:11

    I'm late to the party but here are my two cents.

    Disclaimer: The previous answers are a possible way to tackle this. The next insight is what I've learned while implementing RESTful APIs in Liferay.

    If I understand correctly the question then you have two scenarios here. The first one is you need to create a RESTful api that will be called by already Logged in users. This means that the AJAX calls will, probably, get execute within the client's renderization of the portal. The main issue here is the security, how to secure yous REST calls. First of all I think one should try to leverage on whatever framework one is using before implementing something else. Liferay DOES uses Spring in the backend but they've already implemented security. I would recommend to use the Delegate Servlet. This servlet will execute any custom class and put it inside Liferay's Authentication path, meaning that you could just use PortalUtil.getUser(request) and if it's 0 or null then the user is not authenticated. In order to use the delegate servlet you just need to configure it in your web.xml file

    
        My Servlet
        com.liferay.portal.kernel.servlet.PortalDelegateServlet
        
            servlet-class
            com.samples.MyClass
        
        
            sub-context
            api
        
        3
    
    

    As you can see we are instantiating another servlet. This servlet is going to be defined by the PortalDelegateServlet. The Delegate Servlet will use whatever class is on the value of the sevlet-class param. Within that class you can just check if there's a valid username in the HttpServletRequest object with Liferay's Utils and if there is then the user is OK to go. Now, the way you access this is that the Delegate Servlet uses the value of the sub-context to know which class are you refering to from the URL. So, in this example you'll be access com.samples.MyClass by going to https://my.portal/delegate/api The 'delegate' part will always be there, the second part of the URL is what we define in the init-param. Notice that you can only define one level of the URI for sub-context, i.e. you can't set /api/v2.0/ as sub-context. From then on you can do whatever you want on your servlet class and handle the parsing of the REST URI as you want.

    You can also use spring's Dispatcher class as the class that the Delegate Servlet will call and just setup a spring servlet, hence having url annotation mappins.

    It is important to know that this is only good for RESTful or Resource serving, since the Delegate Servlet will not know how to handle renderization of views.

    The second scenario you have is to be able to call this RESTful API from any external application (doesn't matter what implementation they have). This is an entire different beast and I would have to reference the answer by iamiddy and using Spring's Authentication Token could be a nice way to do this.

    Another way to do this, would be to handle unauthorized users in your servlet class by sending them to the login page or something of the sort. Once they succesfully login Liferay's Utils should recognize the authenticated user with the request. If you want to do this within an external application then you would need to mock a form-based login and just use the same cookie jar for the entire time. Although I haven't tried this, in theory it should work. Then again, in theory, communism works.

    Hope this help some other poor soul out there.

提交回复
热议问题