Documentation request for source features

Feedback Idea Discussions
, ,
1

Hi Team!

Please provide documentation regarding the json attribute features of a source object. What are the possibilities for the values, what do they mean and what happens when we add them or remove them?

This request is a response to the discussion at: Documentation for source features

Please note that @derek_putnam has already reached out to the documentation team regarding this.

4 Likes
2

Has this documentation been created yet?

3

Hi @derek_putnam, have you received any response on this one from the documentation team?

4

Hi @derek_putnam are there any updates on this? I would like to know if I can remove provisioning from a source to make it be ‘read-only’ similar to how we can edit connector XML in IIQ.

6

I just opened a ticket (SAASDOCS-6550). I’ll keep this topic updated on it’s progress.

1 Like
7

In our internal discussion, it has been brought up that source features for SailPoint OOTB connectors should not be modified as they can break source configurations. Modifying these values may result in an unsupportable failure. They are really meant to be static and not modified by end users. That being said, we’re debating on how best to communicate this information and I am still pushing to document what the features do for educational purposes, even if they aren’t meant to be changed.

8

Hi Colin,

But breaking this configuration is exactly what we want. If an OOTB source can do access provisioning and enabling/disabling an account, and we do not want to use the enable/disable part and only (de-)provision the account, then we can remove the feature ‘ENABLE’ and we can then see that the enable/disable account button is removed from the UI for accounts from this source and that using the API to enable/disable an account from this source will result in a 4** error.

And after placing the feature back, the source will be able to perform these tasks again.

Same for web service connectors (do you consider that a OOTB connector?), if we do not have a disable/enable account API, we can remove the buttons from the UI by telling the source that it can not support the feature ‘ENABLE’

Kind regards,
Angelo

1 Like
9

I’m not knowledgeable enough to know what the ramifications of disabling features on an OOTB connector will do in the grand scheme of the system. Maybe it will be benign and just remove the UI component, and maybe it might do more than that.

Web service, JDBC, and custom SaaS connectors should be fine, as those are configured for your source as opposed to using as-is with say an AD connector.

FYI, we just pushed an API spec update that describes most of the features. This will be live within the hour.

2 Likes
10

Hey @angelo_mekenkamp,
Good day!

I am late to the party apologies for that, one interesting thing that I have observed while going through the API doc here:
update-source | SailPoint Developer Community

An interesting feature string caught my eye:
ADDITIONAL_ACCOUNT_REQUEST and ACCOUNT_ONLY_REQUEST

And I cannot find any other reference to these feature strings other than your post here and off-course the API spec.

Any luck trying them out?(pretty please :slight_smile: ) I am really curious as what do they do. I know officially SailPoint mentions that we should not tweak with these feature string but if I know the possible issues before hand it will be easy for me to convince the clients into avoiding such changes.

Regards,
Aman

11

Could these be remnants from IIQ, or from a very specific connector? I haven’t added these myself to a source before. I think that in general if an out of the box connector doesn’t have these feature strings, they have not been programmed in such a way that it could handle that functionality (except perhaps the negative feature strings like NO_RANDOM_ACCESS). In general I make use of them by removing the features I don’t want the connector to perform rather than adding other features (again, except for the negative features).

12

Older Compass post on these: https://community.sailpoint.com/t5/IdentityIQ-Forum/What-are-the-Feature-Strings-for-Applications-and-what-do-they/m-p/81458/thread-id/121754

Additionally, this is from the Application.Feature enum type from the IIQ JavaDoc:

Enum Constants Enum Constant and Description
ACCOUNT_ONLY_REQUEST

The application supports requesting accounts without entitlements.
ADDITIONAL_ACCOUNT_REQUEST

The application supports requesting additional accounts.
AUTHENTICATE

The application supports pass through authentication.
COMPOSITE

The application supports composite application creation.
CURRENT_PASSWORD

Some application types support verification of the current password
DIRECT_PERMISSIONS

The application supports returning DirectPermissions.
DISCOVER_SCHEMA

The application supports discovering schemas for users and groups.
ENABLE

The application supports reading if an account is enabled or disabled.
GROUP_PROVISIONING

Deprecated.

We should use Application.Feature.PROVISIONING on group schema type.

The application can both read and write groups. Having this feature implies that the provision() method is implemented.
GROUPS_HAVE_MEMBERS

The application models group memberships with a member attribute on the group object rather than a groups attribute on the account object.
MANAGER_LOOKUP

The application supports looking up managers as they are encountered in a feed.
NO_AGGREGATION

An application that does not support aggregation.
NO_DIRECT_PERMISSIONS_PROVISIONING

Deprecated.

Application.Feature.NO_GROUP_PERMISSIONS_PROVISIONING
NO_GROUP_PERMISSIONS_PROVISIONING

Deprecated.

Application.Feature.NO_PERMISSIONS_PROVISIONING Deprecated as of 6.4 in favor of NO_PERMISSIONS_PROVISIONING. This now lives on the Schema Feature Strings

Indicates that the connector cannot provision direct or target permissions for groups. When DIRECT_PERMISSIONS and PROVISIONING features are present, it is assumed that the connector can also provision direct permissions. This feature disables that assumption and causes permission request to be converted to work items for groups.
NO_PERMISSIONS_PROVISIONING

Indicates that the connector cannot provision direct or target permissions for accounts.
NO_RANDOM_ACCESS

The application does not support random access and the getObject() methods should not be called and expected to perform.
NO_UNSTRUCTURED_TARGETS_PROVISIONING

Deprecated.
PASSWORD

The application can provision password changes.
PROVISIONING

The application can both read and write accounts.
PROXY

The application can serve as a proxy for another application.
SEARCH
SHAREPOINT_TARGET

Deprecated.

Now AD support Sharepoint Target Collector by default. No need to add feature string.

The application supports returning unstructured Target data for SharePoint. It will be typically used by AD, LDAP applications.
SYNC_PROVISIONING

The application can provision accounts synchronously.
TEMPLATE
UNLOCK

The application supports reading if an account is locked or unlocked.
UNSTRUCTURED_TARGETS

The application supports returning unstructured Targets.

1 Like