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.
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.
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:
- Log in to the partnership owner account.
- From the account dropdown in the New Relic UI, select Account settings > Partnerships > Edit settings.
- For SSO type, select
- For SSO data, type the shared secret.
- 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
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 authentication request
POST or GET
ID of the New Relic account.
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 used to generate token, in seconds since the epoch. Only timestamps within five minutes (300 seconds) of the New Relic system clock are accepted.
Partner navigation data. This data will be set in the session cookie using the name as specified in the partnership configuration, or
Signed token. The signature token is generated by applying a SHA1 hex digest on a seed string, which is composed as
Example without email: "12345:MySecret:0987654321"
Using Ruby syntax:
Example with email: "12345:MySecret:0987654321:email@example.com"
Using Ruby syntax:
Relative path of a New Relic page to which the users will be directed.
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:
Additional documentation resources include: