Skip to main content
Kinetic Community

Authentication

Document Overview

The following document will assist in documenting the authentication scenario(s) used in the Kinetic Request implementation.

Authentication  Overview

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.

External Authentication

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

 

Catalog/Form Set

Authentication Type

Additional Variable Description
Example: 
HR Forms
None None No login is necessary to access these forms

Example:
Network Forms

Default (AR System)

None Login is required and authenticated off AR System using a default login screen

Example: 
Desktop Forms

Template (AR System) Template Name Login is required and authenticated off AR System using a service item template to control the theme

Example:
Vendor Forms

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.

 

Item

Notes

Example: Passwords

Stored in LDAP.  Remedy uses blank password/AREA integration

Example:

Users

User table in Remedy only has IT Remedy Users.  Employees are stored in SHR:People, but not all have user accounts.

 

 

Sample Login Page

This page was created with Kinetic Request.  Any requests to a service item that requires authentication are redirected to this login page.  The user is then authenticated against the AR System by default. 

 loginScreen.png

 Previous (Reporting)                                                                                                 Next (Installation Prerequisite Planning)