LCS - Best Security Practices for Kuali Build

Before publishing any application to be Live, especially where data is restricted or sensitive, should ensure that a cybersecurity review has been completed for the application, LCS - Data usage and approval in Betty Blocks and Kuali Build has been obtained, the following minimum security requirements have been met and the Low Code Systems Terms of Service have been met. 

• Authentication
• Authorization
• Form Settings
• Data Application Programming Interface (API)
• Miscellaneous: 

Authentication

• All application authentication will be provided via Single Sign On (SSO). 
  • Login validation is confirmed with your WorkDay and PersonAPI profile.
  • Regarding issues with SSO, please contact your SCD's IT Department. 
• Once authenticated, all users should be assigned a Kuali Build (Kuali) policy (aka role). 
• UW Applications should use Manifest for all role-based authorization mapping. 
  • See LCS - Kuali - How and When to Use Blueprints vs. Groups vs. Roles for more details.
• Following the principle of least privilege, the default policy assigned to authenticated users should not provide more than the minimum appropriate level access to the application. 
• The Application Admin policy should be assigned to specific users to provide more expansive access to the application. The Admin policy should not be used as the default role assigned to most users. 
• For documents and sections that should be restricted to specific policy or set of policies, create policies and set permissions follow the LCS - Kuali Permissions Tips and Tricks
• Authentication timeout for Kuali is a week.

Authorization

• The Application Admin policy should be reserved for only those making changes to the application. Other policies and Manifest groups should be used or created for all access, administrative or otherwise within the workflow. 
• Authorization for document and office-use only section access should be done via policies and Manifest groups and not with a specific user’s credentials, even if only one user will be accessing the contents of the page. 
• Limit those who have access to view and see submitted documents.
  • An example where a user would need to view other completed documents is if a team is required to complete a set of documents and the team needs to know each other's progress so as to not duplicate work. However, utilize conditional permissions to limit who can view, and not edit the document, and at what point in the workflow.
  • An example where a user would need limited read access to completed documents would be a workgroup that needs to review submissions. Create a policy that only allows read access to the documents and then assign a Manifest group to that policy with the appropriate people.
• Kuali Build knows any NetID webuser's SSO profile following a successful login for access to the live application. Note that this is different from the profiles used inside the application to grant or deny access to the forms and documents in Kuali Build. 

Form Settings

• For any application that contains restricted or sensitive information, the Application Administrator must:
  • Capture and see the user information from the logged-in webuser in your application by turning on Track Document Edits with History in Form Settings. This will allow you to view all workflow activity and logs of document edits.
  • Perform at least a monthly review of the logs to note any significant, unexpected events (i.e. incident).
• If a possible incident occurred:
  • Incident:  See UW Policy 509 for what can be considered an incident
  • Incident Reporting and Response Procedures: See UW-Madison - IT - Incident Reporting and Response Procedures for what can be considered an incident
  • Notify the LCS team immediately.

Data Application Programming Interface (API)

• Access to an API should be granted via a dedicated authentication profile and dedicated API user account.  
• The API Users should be provisioned and assigned a dedicated role, not a personal account. 
• API user accounts must adhere to UW Password security policies for service accounts.
• API user credentials should be securely stored in the external service calling the API and never committed to a code repository. 
• Integrations being called via API must be secured to the authentication profile and role of the API service account. 
• When transferring files from an external service to Kuali it is advised to use one of the following methods 
  • Base64 the file in the external service and send as a field in the input. 
  • Use a secure storage solution and generate a short-lived secure URL for BB to retrieve the file from. Example: a pre-signed URL from an encrypted AWS S3 bucket. 

Miscellaneous: 

• Carefully remove old or unused profiles, sections and workflow steps from your application. 
• Before adding another application administrator to your application, consider the data they would have access to.  All application documents, settings and connected APIs will be accessible to an application administrator on the app.