The following document will assist in documenting the authentication scenario(s) used in the Kinetic Request implementation.
Kinetic Request allows authors to specify whether a request submitter should be authenticated before being able to submit a request. By requiring authentication, a user will need to input credentials to authenticate against your AR System server. This authentication configuration is done on a form-by-form basis to allow maximum flexibility.
In addition, each form can set different levels of permissions for access:
- Who can make changes to the form definition
- Who can submit the form
- Who can view the submitted data
This access is controlled through the typical Remedy AR System Users/Groups configuration, and is defined when the form is created.
Data elements derived from the authenticated user’s information may be used to filter service items displayed. Location, department, title are some data examples used in past projects. If using another data element for entitlement, those entitlements must be stored for the service item. The attributes of the service item is an effective place to do this, though customer have implemented it in other ways.
If needed, Kinetic Request can be included in many Single Sign On/External Authentication schemes for users submitting requests via the web interface. Accomplishing this involves:
- Determining the specifications for the authentication source
- Writing Java to implement Kinetic Request’s Authentication interface
· Configuring the AR System server to recognize the authentication source (not applicable in every situation)
An external authentication integration can typically be written in approximately two weeks depending on the complexity of the integration and how it impacts other AR System configurations. Some existing examples are IIS/WAFFLE, x509 cert, and Remedy.
Form Authentication Notes
|None||None||No login is necessary to access these forms|
Default (AR System)
|None||Login is required and authenticated off AR System using a default login screen|
|Template (AR System)||Template Name||Login is required and authenticated off AR System using a service item template to control the theme|
External (Authentication via Vendor Portal)
|Authentication URL||Login is required and authenticated off an external system with the URL provided|
Remedy Authentication Notes
It’s a good idea to document how users are currently authenticated in Remedy for later reference during form design.
Items to consider:
- Is “Guest Access” configured on the Remedy server? This allows users to authenticate in without a Remedy user account, by providing only a login name.
- Do all of your users exist in the Remedy User form for authentication?
- Do all of your users exist in some type of employee lookup form (such as SHR:People) to retrieve contact and other information?
- Should new users be identified and created in Remedy as needed? This has an impact on AR System licensing depending on whether users will have a write license.
Stored in LDAP. Remedy uses blank password/AREA integration
User table in Remedy only has IT Remedy Users. Employees are stored in SHR:People, but not all have user accounts.