Single sign on and access control

New Relic supports Single Sign On (SSO) as a convenience for partner customers. Partners implementing SSO also have the option to restrict access by requiring customers to access New Relic via the partner's management site or product login.

Single Sign On is a convenience for your customers, eliminating the requirement of entering sign on credentials multiple times, and it creates a more unified experience for the user. In situations where this distinction is desired, SSO is recommended. Where it is desirable to maintain a distinction between the services or where technical considerations preclude implementing SSO, a fully functioning integration is still achievable.

Implement Single Sign On

Two methods for SSO are supported by New Relic. New Relic upgraded its single sign on system during 2011. If you implemented single sign on with New Relic prior to September 2011, you will have used the old system. That method of implementing SSO has been deprecated.

All new integrations must use the new system. Existing implementations using the old system will continue to work indefinitely. However, we encourage all partners using the old system to upgrade to the new model.

Use shared secret method

The upgraded shared secret version of New Relic's SSO implementation offers several improvements over the old handshake version. Most important, the system is more secure. Security is enhanced by the use of passing a SHA1 digest of a shared secret, a timestamp, and request specific data in the authentication SSO request. The shared secret can be any string. Whatever shared secret is chosen, enter it in the appropriate field in the New Relic Partner console.

To edit the SSO settings:

  1. Log in to the partnership owner account.
  2. From the account dropdown in the New Relic UI, select Account settings > Partnerships > Edit settings.
  3. For SSO type, select signature.
  4. For SSO data, type the shared secret.
  5. Select Save.

In addition to enhanced security, the new SSO method supports a session cookie. Nav data may be stored in the session cookie to support enhanced functionality of headers and footers. The name of the cookie is specified through the Partner console. If unspecified the cookie name defaults to nav_data.

To successfully use this SSO method, the SSO URI must be invoked from the user's browser. On success the browser will be automatically logged into New Relic and the redirect URL to that account returned.

The SSO URI however should not be generated on the browser, as this would expose the shared secret and allow the login to be spoofed. The URI should be generated on a host and passed to the user's browser.

SSO API

Description

SSO authentication request

Method

POST or GET

URI

https://rpm.newrelic.com/accounts/sso_access

Parameters

Name Required Description
id Yes ID of the New Relic account.
email No

Email address of user logging in (optional). If given, the user must already have been added to the account. By default, the account Owner role is used.

Account Owners have full privileges on accounts. If some lesser degree of account privileges or a different user is desired, the email must be provided.

timestamp Yes Timestamp used to generate token, in seconds since the epoch. Only timestamps within five minutes (300 seconds) of the New Relic system clock are accepted.

nav-data

OR

nav_data

No Partner navigation data. This data will be set in the session cookie using the name as specified in the partnership configuration, or nav_data by default.
token Yes

Signed token. The signature token is generated by applying a SHA1 hex digest on a seed string, which is composed as Account_id:secret:timestamp or Account_id:secret:timestamp:email. Each component is separated by a colon (:).

Example without email: "12345:MySecret:0987654321"

Using Ruby syntax: "#{account_id}:#{secret}:#{timestamp}"

Example with email: "12345:MySecret:0987654321:user@host.com"

Using Ruby syntax: "#{account_id}:#{secret}:#{timestamp}:#{email}"

remote_url No Relative path of a New Relic page to which the users will be directed.

cURL examples


curl -X POST -d "id=63790" -d "timestamp=1319659982" -d
"token=a4d30d6f1f1a5b6c2872ab"
https://rpm.newrelic.com/accounts/sso_access
curl -X POST -d "id=63790" -d "timestamp=1319659982" -d
"token=a4d30d6f1f1a5b6c2872ab" -d "remote_url=/account/63790/servers"
https://rpm.newrelic.com/accounts/sso_access

On success returns:

<html><body>You are being <a href="https://rpm.newrelic.com/accounts/63790/applications">redirected</a>.</body></html>

For more help

Additional documentation resources include:

If you need more help, check out these support and learning resources: