Page tree
Skip to end of metadata
Go to start of metadata

Both standard and LDAP authentication require users to provide credentials in a logon form hosted by the BMC Helix application. Federated authentication integration allows users to access and authenticate to the BMC Helix environment without supplying credentials to the application at all. Users bypass the application logon form and are taken directly to the home page (or requested page) for the BMC Helix application.

The Security Assertion Markup Language (SAML) federated approach is supported with BMC Helix services.

Generally, a federated single sign-on implementation requires some process, script, or third-party solution to be present at your site to take responsibility for the actual authentication of an end user. This on premises process provides the authenticated user ID to the BMC Helix environment. The user's password is not transmitted to BMC cloud, and the BMC Helix components do not perform the actual authentication of the user.

BMC Remedy Single Sign-On (RSSO) is used within the BMC Helix solutions to support seamless authentication for users. See BMC Remedy SSO overview for more information.


SAML is a standards-based authentication protocol that allows federated authentication between your environment and the BMC Helix applications. It is valid for all BMC Helix services.

In the SAML approach, the BMC Helix application is defined as a SAML Service Provider (SP), and your infrastructure that performs the actual user authentication is the SAML Identity Provider (IdP). This integration supports the SAML 2.0 Browser Post and Browser Redirect profiles. With SAML enabled, a user arriving at the BMC Helix application without having previously authenticated is redirected to your IdP. After authentication, the user is redirected back to the originally requested resource or application in the BMC cloud. Although the SAML structure supports both IdP-initiated single sign-on and SP-initiated single sign-on, the SP-initiated single sign-on is essential to enable liking to specific pages or resources in the applications (for example, a notification URL that contains a link to a specific BMC Remedy ITSM form or record).

Configuration of the SAML integration is largely the exchange of SAML metadata between you and BMC. You provide IdP metadata (which defines the URLs used by you for SAML and the certificate used to validate assertions). BMC provides SP metadata to allow you to pre-register the BMC Helix service provider in your SAML infrastructure as required.


If you are using multifactor authentication, a user might be required to log on twice when first accessing the federated system — once to authenticate to the customer IdP, and again to authenticate to the BMC Helix SP. After this initial double logon, the accounts are then federated, and subsequent logon attempts require only the original logon to the customer IdP.

A better configuration uses autofederation to eliminate the need for the initial second logon. By matching an attribute provided in the IdP's SAML assertion to a user ID stored in the BMC Helix application user data stores, the accounts can be automatically federated. By default, the BMC Helix SP expects to see an attribute named uid in the assertion from the IdP; however, the exact attribute used for autofederation is configurable.

Customer IdPs

BMC has successfully integrated with a variety of customer IdPs, including Ping Identity, Shibboleth, OpenSSO, Oracle AM, Microsoft Active Directory Federation Services version 2 (ADFS2), and several customer-developed custom SAML solutions. If you do not have a suitable SAML IdP, BMC recommends that you pursue one of the IdP options that are commercially available, for example, Okta, Onelogin, Microsoft's Azure Active Directory, and so on.

Related topics

Standard AR authentication


  1. Can you fix the lifecycle requests link - there is a missing : after https