IdentityWorks is pleased to announce the availability of the “public subset” of our feature-rich IIQCommon library, which you can find at:
https://git.identityworksllc.com/pub/iiqcommon
IIQCommon is a utility library used in virtually all of our SailPoint IdentityID installations and plugins.
Some of the utilities included in this library are documented below.
Utilities
A whole slew of convenience utilities
IIQCommon contains a whole slew of convenience utilities:
- BeanshellUtilities: which allows you to avoid “void” checks by instantiating any missing variables.
- CacheMap: A Map implementation that caches entries for a period of time, then drops them.
- IdentityLinkUtil: Convenience methods for extracting single-valued or multi-valued attributes from a Link attached to an Identity, among other things. Used heavily at customer installations where we’ve had to implement a custom IIQ front-end.
- NamedParameterStatement: A utility allowing SQL queries with named variables, e.g., “select id from spt_identity where name = :name“.
- ObjectMapper: Translates a Map (e.g., from a Custom or Configuration object) into a Java bean. You can do this with Jackson, too, but this utility is often more powerful.
- Outcome: A generalized VO object for returning the result of any sort of API.
- Quietly: Swallow exceptions for various operations where you don’t really care about the results.
- Sameness: Extends the concept of “equals” so that SailPoint’s data weirdness doesn’t affect lifecycle event triggers. For example, the String “true” and boolean true will be the same, as well a String and a List containing only that String.
- SLogger: An extension of the Commons Logging Log class, allowing message templates to be used instead of expanding variables at compile time. Template variables are only rendered if the given log level is enabled.
- Table: For generating a type-checked HTML table, which can be displayed in a SailPoint Form, for example.
- Utilities: Contains a variety of null-safe operators and utilities for working with SailPoint APIs more safely. Some of these utilities are intended for Beanshell and others for Java code.
There are also iterator implementations, including the ResultSetIterator and TransformingIterator.
BaseCommonPluginResource
This superclass for all of IDW’s plugin REST APIs allows you to essentially ignore the “web services” part of the picture. The superclass handles authorization, logging, error handling, and output transformation for you. It also extends SailPoint’s authorization annotations, adding several more options.
Your actual business logic is implemented in a lambda function passed to handle() in the superclass.
Your REST API methods simply look like this:
public Response someMethod(Map<String, Object> jsonBody) {
return handle(() -> {
Map yourResult = new HashMap(); // or whatever
// do stuff
return yourResult;
});
}
You never need to deal with a Response object again!
The package also includes several Mock or Dummy implementations of SailPoint’s web services and security classes for writing tests against your code.
HybridObjectMatcher
This class can match virtually any SailPoint Filter against any object – offline.
It’s an extension of the SailPoint-provided HybridReflectiveMatcher, which does a decent job, but doesn’t mimic matchers that query the database well enough. We use the HybridObjectMatcher at every one of our customer installations.
SailPointWorker
This class is a powerful tool for multi-threading SailPoint IIQ actions. It can be used as a Runnable, a Callable, or via Java’s ForkJoinPool mechanism. It provides hooks to handle various points in the worker lifecycle. Workers can be nested, with variables generated by child workers available in the parent.
It can also be serialized and passed as a Request to the provided SailPointWorkerExecutor request handler.
The provided RuleWorker and TerminatorWorker classes can be used as examples.
ThingAccessUtils
This utility is part of the “secret sauce” behind virtually all of IDW’s plugins. It allows you to specify in simple Map format (e.g., in a Custom) whether access is granted based on both the user doing the requesting – the subject – and the identity being requested – the target. Access checks are fast and fail-closed.
The following types of access checks are supported for both the “subject” and the “target” identity:
- IIQ rights, roles, workgroups, and capabilities
- IIQ queries, selectors, and filters
- QuickLink populations
- Beanshell scripts and rules
The utility also works in situations where no target exists, e.g., “Can this user access this section of the page at all?”