If you want to implement New Relic's automated user management and import your users from an identity provider, first read Introduction to automated user management to learn about supported identity providers and when you'd want to use our SCIM API, documented below.
Requirements
If you have an identity provider that has a New Relic app (Azure AD, Okta, and OneLogin), see the guides for those. The SCIM API is meant for organizations that either aren't using those identity providers, or that want to use the SCIM API for additional configuration not available with the apps (for example, managing user type).
Note that after you set up an integration with the SCIM API, there are next steps to do, including downgrading some users to basic users, and granting user groups access to New Relic accounts.
Tutorial
See the SCIM API tutorial for more specific instructions on using this API.
SCIM service provider
New Relic’s SCIM service provider follows the SCIM 2.0 API as described in RFCs 7643 and 7644. You do not need to implement all aspects of the SCIM 2.0 specification to integrate your user information with New Relic. In fact, the New Relic service provider itself does not implement all aspects of the specification. This document describes the features from the specification available for an integration with New Relic.
Authentication
Authentication requires a bearer token. This bearer token is specific to your New Relic authentication domain and is displayed when first enabling SCIM for an authentication domain.
Supported resources
The New Relic service provider supports the following SCIM resources: Group , User , Service provider config , Resource type and Schema. Bulk and Search are not supported. For more information on how the RFC describes the resource endpoints, see RFC 7644 SCIM Protocol Specification.
Schemas
New Relic uses a subset of the available fields in the SCIM core schema. Other SCIM fields are ignored if they are included in incoming requests. The fields used by New Relic are:
Group:
SCIM field name
Description
displayName
Required. Name of the group.
members
List of users in the group.
User:
SCIM Field Name
Description
externalId
Unique identifier for the user used by your system.
userName
Required. Unique identifier for the user within New Relic’s system. Use the user’s email address.
name.familyName
Last name of the user.
name.givenName
First name of the user.
emails or emails.value
Required. Email address of the user.
timezone
Time zone of the user in IANA Time Zone database format, also known as the "Olson" time zone database format (for exmaple, "America/Los_Angeles").
active
Required. Boolean indicating whether or not the user should be active or inactive within New Relic.
groups
List of groups to which the user belongs.
New Relic user type (basic, core, or full) schema
This is an optional schema extension for New Relic-specific user attributes. Currently this provides control only over a user's user type. For a tutorial showing how to use this, see the SCIM API tutorial.
The user type: full user, core user, or basic user.
Supported actions
SCIM provides several options for manipulating groups and users. The New Relic service provider supports the following options.
When configuring, be aware that:
Only simple filtering is supported. The eq operator may be used with a basic filter expression. For example, “displayName eq "Example Group 1”. Other operators are not supported.
PUT updates do not require that all fields be included. Fields that are not included will not be changed. When doing a PUT, if a required field already has the appropriate value, it is not necessary to include the field.
Supported actions are:
Example request:
POST /Groups
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"displayName": "Example Group 1",
"members": []
}
Example response:
201 Created
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"id": "d0652232-b14f-434d-9c6f-36de7e1ab010",
"displayName": "Example Group 1",
"meta": {
"resourceType": "Group",
"created": "2019-11-08T21:33:13.055Z",
"lastModified": "2019-11-08T21:33:13.055Z"
},
"members": []
}
Example request:
GET /Groups/YOUR_GROUP_ID
Example response:
200 OK
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"id": "d0652232-b14f-434d-9c6f-36de7e1ab010",
"displayName": "Example Group 1",
"meta": {
"resourceType": "Group",
"created": "2019-11-08T21:33:13.055Z",
"lastModified": "2019-11-08T21:33:13.055Z"
},
"members": []
}
Example request:
GET /Groups?filter=displayName eq "Example Group 1"
In the request, include the fields that you want to change. If you include the members field, the group’s users will be adjusted to match the contents of the members field. Example request:
PUT /Groups/YOUR_GROUP_ID
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"displayName": "Example Group 1a"
}
In the request, include the fields that you want to change. If you include the groups field, the user’s groups will be adjusted to match the contents of the groups field. Example request:
This section describes areas where the New Relic SCIM service provider deviates from the SCIM protocol RFC 7644. Section numbers refer to RFC section numbers.
Items in this section could change as we work to bring our service provider into full compliance with the RFC.
String attributes are compared in a case sensitive manner.
Prefixing the field name with the schema is not supported. For example, filter=urn:ietf:params:scim:schemas:core:2.0:User:userName eq "johnsmith" will not work.
Once your users are in New Relic, you need to grant them access to specific New Relic accounts, specific groups, and specific roles. Without doing this, your users have no access to New Relic accounts. To learn how to do this, see: