Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
When implementing a REST service in a Mediation route using the cREST component as route consumer, Studio provides three ways to authenticate the service: HTTP Basic, SAML token, and OpenID Connect. Only the SAML token provides an option to enable authorization. Unfortunately, the SAML token is not an adequate solution in many use cases because third-party service clients cannot be expected to acquire a SAML token and integrate it into the request. Often HTTP basic authentication, together with HTTPS, is the only way to integrate third-party clients.
Cause
Studio does not support authorization when selecting HTTP basic authentication as an authentication type.
Resolution
Overview of best practice
In Routes, you can enhance the cRest component to implement role-based authorization with the help of an authorizing filter.
Detailed explanation
Sources for the project are available in the attached Authorization.zip file.
The cREST component is based on the Camel CXFRS component and the JAX-RS implementation of CXF. In JAX-RS, the runtime is extended and customized through providers. CXF JAX-RS provides a SimpleAuthorizingFilter, extending a REST endpoint with role-based authorization.
One way to add providers in CXFRS is to add the providers option to the endpoint URL of the CXFRS component. The providers are registered as beans in the Camel registry and referenced by name in the providers option. For more information on the exact syntax in the providers option and a complete list of all other options, see the Apache Camel, CXF-RS Component page.
Figure 1 shows a Mediation route in Studio that implements a web service with authentication and authorization.
Figure 1. REST service with authentication and authorization
In the cREST component, you can enforce authentication on the Basic settings tab by enabling the Use Authentication check box and selecting HTTP Basic as the authentication protocol.
Figure 2. Basic settings of the REST endpoint
Enforcing authorization in the cREST component is slightly more involved. It requires setting the additional "providers" option, which is implemented by the bean registered under the name of "authFilter" in the Advanced settings tab, as shown in Figure 3.
Figure 3. Advanced settings of the REST endpoint
In this example, the cBeanRegister component initializes the SimpleAuthorizingFilter, and registers it under the name "authFilter", as shown in Figure 4.
Figure 4. Definition and registration of the authorizing filter
The filter is mainly a wrapper around the SimpleAuthorizingInterceptor, which does the actual work. It is also the interceptor where the roles are specified that authorize the service to execute. In this article, the setGlobalRoles method specifies the roles manager and admin in the beans definition code, which allows them to execute the service. In a real-world use case, you would specify them through a context variable.
The Authorization.zip file, attached to this article, contains an executable sample project (v6.5.1). You can experiment with the project by deploying it in a Talend Runtime and trying different outcomes. For example, you could add a few users to the etc/users.properties file with corresponding roles.
Figure 5 shows a users.properties file where the user alice has the manager and employee role, and user bob only has the employee role. Call the deployed service using the URL (http://localhost:8040/services/test). If authenticating with user alice the call is successful. If authenticating with user bob you should get HTTP return code 403. The sample not only works with the JAAS PropertiesLoginModule but also with the other login modules supported by the Talend Runtime, such as LDAPLoginModule or SyncopeLoginModule.
Figure 5. Sample users file
