Join the eXo Tribe

Get product updates and latest versions, community support, add-ons and more.

Sign up now!

How to Add Access Controls to Your REST Services and Gadgets

The web-based IDE in eXo Platform allows developers to easily create new features and push them to end users in a few minutes. As you start developing gadgets for your portal, you might be interested in putting some restrictions on services based on different user profiles. In this tutorial, you will learn how to:

  • Access the security context in a REST service
  • Check if a user is a members of a group, and manage permissions from this information
  • Consume this service in a gadget, and leverage the built-in security to protect resources

If you are more interested in the code than in the step-by-step tutorial, you can jump directly to the REST Service code or download the full IDE project from GitHub.

Accessing User Profiles from Your REST Service

eXo Platform uses the JAX-RS API to develop and deploy REST services. eXo developers can create REST services using any Java IDE, but in this case we will use the IDE packaged with eXo Platform.

To access the security and user information in your service method, you can use the SecurityContext class of the JAX-RS API. Your method signature will look like:

In lines 7 and 8, we import the classes needed to inject the security context in the method getSystemInfo()  in line 16. Let’s forget about the rest of the code for now.

The Security Context object gives us access to a lot of information. Since the objective in this example is to check if a user is allowed to execute a part of the business logic, two methods are particularly interesting: getUserPrincipal()  and isUserInRole() .

It is important to remember that we cannot directly use the isUserInRole()  method since it uses the logical Java EE roles defined at the Java application level. In our case, we want to know if a user is present in an “eXo User Identity” Group. For example, if the user is a member of the /platform/administrators  group. This information is populated during the login process and comes from the user provider; this could be LDAP, the eXo database or JCR, or any other source since developers can extend this API to connect their own provider.

Let’s create a helper method using the eXo Identity Service, which checks if the user executing the method is present in a group.

The method is quite simple. It uses the following parameters:

  • The name of the user, which you can get from the UserPrincipal.getName() method
  • The specific eXo group you want to check; for example /platform/administrator

You can now call this method from your resource to check the user, and code the “permission business logic”.

The method could look like:

To make it easier in this example, we have hard-coded the name group that we want to check. You can obviously use smarter code that uses an external configuration, and, for example, inject a list of groups to check. We manage the security logic of the method with a simple “if” statement that returns a string.

Depending on your needs, you could also manage the status of your response and use HTTP code (returning an HTTP 403 for example). You would just need to return a different response using the following code:

To keep it simple, we will keep a single Response status (OK) and manage the permission in the client code.

Completing the REST Service

Now let’s take a look at the full service. This service allows administrators to get the list of the System Properties while other users get a “NOT-ALLOWED” status string:

To summarize:

  • Line 24: the SecurityContext is injected in the method
  • Line 26: initialization of a simple ResponseWrapper defined in line 51, which contains a status and data. This will be serialized in JSON by the eXo REST engine.
  • Line 28: the method checks if a user is connected and a member of /platform/administrator. If not, it sends a response with the status NOT-ALLOWED.
  • Line 31/32: The response object is sent. This response contains an OK status as well as the data (system properties list).
  • Line 42: Using the eXo Identity Service, the method checks if the connected user is a member of a specific group.

Consuming the Service in a Gadget

We can now take this service and consume it in a Google Gadget, which we will build using the IDE.

The following code shows the JavaScript part of the gadget that calls the service, checks the security rights and pushes the response content in the gadget’s body. We used the JQuery library to simplify development.

Here’s a quick explanation about the code:

  • Line 23: to call the REST service, we use the $.getJSON()  method. This method is really easy to use when you are executing the gadget in the same container as the portal consuming it. The gadget.io.MakeRequest is useful to proxy a request if you need to re-authenticate, for example using oAuth.
  • Line 3: this is the callback method. As you can see, we use the  ResponseWrapper  to check the code in the status attribute. Depending on whether the status is OK or not, you can print the value.

Conclusion

In this tutorial we have shown how to:

  • Get the security context in a REST Service
  • Check the membership of a user using the eXo Identity Service
  • Create a gadget that consumes this service and exposes data only to users with a specific profile or group membership.

Again, note you can download the full project from GitHub.

WordPress Image Lightbox