Both standard and LDAP authentication require users to provide credentials in a logon form hosted by BMC Remedy Mid Tier. Federated authentication integration allows users to access and authenticate to the BMC Remedy environment without supplying credentials to BMC Remedy at all. Users bypass the BMC Remedy Mid Tier logon form and are taken directly to the home page (or requested page) for the BMC Remedy application.
The following federated approach is supported with BMC Remedy OnDemand:
AREA single sign-on has been deprecated as of BMC Remedy OnDemand 2012.01.
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 Remedy environment. The user's password is not transmitted to BMC Remedy, and the BMC Remedy components do not perform the actual authentication of the user.
BMC Remedy Single Sign-On (RSSO) is used within the BMC Remedy OnDemand solution 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 Remedy OnDemand applications.
Federated SAML authentication is valid for BMC Remedy Mid Tier, BMC Remedy AR System, BMC Remedy ITSM and BMC Analytics for BSM.
In the SAML approach, BMC Remedy OnDemand is defined as a SAML Service Provider (SP), and your infrastructure that performs the actual user authentication is the SAML Identity Provider (IdP). The BMC Remedy OnDemand SAML integration supports the SAML 2.0 Browser Post and Browser Redirect profiles. With SAML enabled, much like AREA single sign-on, a user arriving at BMC Remedy OnDemand without having previously authenticated is redirected to your IdP. After authentication, the user is redirected back to the originally requested resource or application in BMC Remedy OnDemand. 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 Remedy OnDemand provides SP metadata to allow you to pre-register the OnDemand service provider in your SAML infrastructure as required.
In a typical SAML interaction, 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 Remedy OnDemand 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 Remedy OnDemand user data stores, the accounts can be automatically federated. By default, the BMC Remedy OnDemand SP expects to see an attribute named
uid in the assertion from the IdP; however, the exact attribute used for autofederation is configurable.
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.