This documentation applies to the 8.1 version of Remedy Action Request System, which is in "End of Version Support."

To view the latest version, select the version from the Product version menu.

Single sign-on authentication systems integration

SSO is a method of system and resource access control, used to authenticate users one time for access to any resource residing within the bounds of the system. In simpler terms, SSO allows system users to authenticate once and gain access to multiple resources. SSO advantages include:

  • Improved user productivity
  • Improved system security
  • Improved administration process

BMC Remedy AR System can be integrated into an single sign-on (SSO) environment with a plug-in that verifies user credential authentication. The plug-in acts as a layer between the SSO service and the server. Because each SSO environment varies greatly, there are few applicable standards for SSO integration. To ease the process of integrating into an SSO solution, AR System provides vendor agnostic hooks for SSO integration.

A full SSO solution, includes BMC Atrium and uses what AR System provides. BMC Support also has a simple proof-of-concept example, which is fully functioning. The example is not a supported product and there is no implied support if you use it. For more information, see the Knowledgebase article, KA286851.

Starting with BMC Remedy AR System version 7.6.04, the AR System server is integrated with the BMC Atrium Single Sign-On (SSO) solution by introducing a Atrium SSO plug-in. To configure this plug-in, you must provide values for certain configuration parameters on the new Atrium SSO Integration tab, located on the AR System Administration: Server Information form.

Alternatively, you can also configure the Atrium SSO server while installing the AR System server. To do this, you must provide the values for the configuration parameters on the new Atrium SSO Configuration screen after selecting the Configure Atrium SSO check box.

The following table describes the components of an SSO solution.


Some solutions will not include all of the listed components.

SSO Components




The system verifies user identity, and provides access based on permissions awarded. Most SSO approaches centralize authentication.


Authorization can be centralized or managed by the target. Some solutions centralize user privilege administration while the authorization remains with the target.

Login automation

Sign on process automation is manifest via entry of a user name and password. Scripts are stored on a special authentication server. The user signs on to that server using the client. The server tells the client software which resources the user may access. When a resource is requested, the client software uses login credentials and scripts supplied by the authentication server to establish the connection to the relevant target resource (server, host, domain or application) on the user's behalf. From the perspective of the target resources, little or nothing changes. Each is still authenticating as before and maintains its own set of user privilege information.

Centralized Security Administration

Many vendors sell complementary centralized security administration tools that use agents on the target systems to enable central setup and termination of accounts. These tools allow role-based administration of user accounts, often storing account and privilege information in a centralized directory. In some cases these administration tools are completely separate, in others they are more tightly integrated.

Token-based authentication

When the user is identified, the service creates a non-forgeable, non-reusable token to identify the user to authorized resources.

Certificate-based authentication

Certificate-based authentication is centralized, role-based administration of user privileges across several resources.The SSO system identifies the user and brokers trusted credentials to the application, masking the authentication process from the application.

Client Agent

The client agent is a web server plug-ins or agents that communicate with the authentication server.

The following table describes the components of an SSO solution.


Some solutions will not include all of the listed components.

To integrate successfully with AR System, the SSO solution you choose must provide the following components:

SSO components needed for AR System Integration




The service is a web application to authenticate the user. Generally this web application is connected to an LDAP directory service because LDAP is the popular choice for authenticating users in web applications.


The interceptor intercepts all unauthenticated requests and routes them to the service for authentication.

Client library

The client library is used by the service to authenticate the user and to make the exchange of the SSO token for the user credentials. In some solutions, the credentials are embedded in the request as HTTP headers, eliminating the need for a client library. However, the HTTP header keys must be known for credentials extraction.)

When working with SSO, remember these tips:

  • Any SSO application can work with the AR System if a plug-in (that you or another third-party writes) supports it. You can hook the SSO application into a generic public Authenticator Java Interface and code the AR System external authentication (AREA) plug-in API to verify credentials passed to it from the web client through the mid tier.
  • Make sure the mid-tier timeout is less than or equal to the SSO timeout.
  • Sometimes SSO and proxy caches can conflict.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.