Plugin Authorization

To prevent unauthorized access to your new endpoints, each should be guarded with an authorization mechanism. You can constrain which users can see and access the user interface components, and you can secure the REST endpoints you build into your plugin.

When you define snippets, including widget plugin components, in the manifest file for a plugin, you can specify a rightRequired attribute to constrain access. This attribute names a SailPoint SPRight which users must be assigned for the component to appear in their IdentityIQ instance.

You can also specify a rightRequired at the Plugin object level, in the manifest file, which will specify the required SPRight for a user to be able to access the full-page component of the plugin.

If you leave these rightRequired attributes off, all IdentityIQ users will be able to access those plugin components.

SPRights are the most granular permission object in IdentityIQ. In most cases, users are assigned SPRights in IdentityIQ by attaching those rights to one or more Capability objects and then granting the Capability to the appropriate users.

If the plugin contains a full-page component that users can access through a quicklink, the Quicklink access will be governed by Quicklink Populations, like any other IdentityIQ Quicklink.

User must also be authorized to the full page itself, with the rightRequired specified in the plugin manifest, to be able to view the page.

Other authorization points of note. First, whether or not you explicitly authorize system administrators to these components, they will have full visibility and access to them. Second, when you include a widget in your plugin, the widget will appear in the list of available widgets for all users when they are editing their home page and deciding which content to include there. However, if they are not authorized to the widget's snippet, and they add that widget to their Home page, IdentityIQ will add an empty widget and they will neither be able to see nor interact with any of its functional elements.

To secure the endpoints the plugin framework use Annotations. In Java, an annotation is a syntactic metadata that is added, often before a method signature, that describes the parameters used in that method.

An annotation should have at least three parts

  • The HTTP method (GET, POST, PUT, DELETE, etc)

  • The path or endpoint – this can be parametrized which is useful for pulling back a single record. The above example uses parameterization by adding the variable within {} tags to the end of the URL, and also declaring the @PathParam appName in the input arguments of the method signature

  • The authorization of the method – the allowed values are:

    • @AllowAll – this allows anyone to interrogate the endpoint

    • @RequiredRight("<SPRight>") – allows users who possess the named SPRight to access the endpoint

    • @SystemAdmin – system administrator access only

    • @Deferred – Authorization is deferred to the method. When this option is selected, you must also create an Authorizer class that implements the sailpoint.authorization.Authorizer interface. The Authorizer class should overwrite the authorize(UserContext) method of the base Authorizer interface. Inside of the REST resource method, the author would then call authorize().