Modifying Keywords with custom Unity API applications work arounds

[Anthony_Boyd]

Hi,

I just ran across an issue with one of our custom Unity API applications that does keyword modifications.  I found the cause of this issue explained in the blog post "Modifying Keywords through the Unity API in OnBase 16" and saw the change that was being made to address this issue from within workflow with Unity Scripts but I'm trying to see what work around (if any) can be used for external API applications.  The quick fix would be to grant the modify keyword permission but in doing so would also allow users to modify the keywords (any keywords on the doc type) from within any client as well since they also have access and needs to retrieve these documents from within the OnBase client(s).  This custom application allows keyword modification in a controlled setting so they are only able to modify specific keywords.  Just trying to get some other ideas/thoughs if someone else has ran into similiar issues.

Thanks

Anthony

[John_Webber1]

If I'm understanding your issue correctly, within the external API, you could create a second session with an account that has modify permissions on those keywords, perform the modify methods and then close this session. The User/Usergroups still only have read access.

[Alex_French · Accepted solution]

We're not on OnBase 16 yet, but I've been following that thread with interest.  I understand the security implications of the old behavior, but it seems like a significant breaking change.

For the current behavior, I can think of two solutions that I don't like:

1. Have the external API application drop the document into Workflow, or trigger an existing Workflow Ad Hoc Task or similar.  This can be an occasional workaround for something that the API can't do but Workflow can (e.g. trigger an Autofill, which I would love to see the API be able to do)... but this is not a reasonable general approach for a non-trivial external API application
2. Have the external API application escalate to using a different account when needed.  We do this in very specific cases, but in general this would break the History, be very cumbersome to code, be tricky to get just right without introducing other security risks, and violates the way Hyland's licensing expects API interaction on behalf of a specific user.

I think a reasonable solution would be for Hyland to make two changes:

1. Allow any Unity script (not just Workflow) to easily-but-intentionally override these privileges
2. Allow external API usage to easily-but-intentionally override these privileges if specifically configured using the new "Application Identity" feature discussed in the API Blog.

[Tyler_Sorber]

I believe Alex has covered both workarounds that would be suggested in this case. If further explanation of repercussions of these business cases are needed, such as loss of History, or licensing usage, please contact your first line of support.

As for the suggestions that Alex made:
1) This security elevation is outlined in SCR 227487. If you are interested in being attached to this SCR, please contact your first line of support with a detailed business case.

2) I believe there is a misinterpretation of the Application Identity setting. As outlined within the Unity API Blog under the article "New 16 Feature - Using Application Identities", the Application Identity is used to control a Unity API application’s ability to connect based on an identity setting allowed within OnBase Studio, under the Unity Integrations Tab. This feature does not pertain to Security or Permissions.

[Anthony_Boyd]

I believe what is meant by the Application Identities here is you can verify that it's an intended application and not a rogue api application connecting in unexpectedly doing unexpected things. According to the blob post the SCR appears to only apply to unity scripts from workflow, not external API usage (unless I missed something there).

I had though about using a separate user but loosing the document history is a concern, not to mention the coding and licensing issues as well.