/
NS1

NS1

Owned by Former user (Deleted)
Last updated: Dec 23, 2019

This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.

NS1 is a managed DNS provider. Their documentation for enabling SAML SSO just tells you to contact support, and that Okta and Azure AD are the only supported Identity Providers.

Identity Provider Metadata

NS1 does not support metadata feeds or self-service provisioning. You must email them your Identity Provider metadata when requesting that they enable SAML SSO for you.

Service Provider Metadata

NS1 does not provide metadata, but will give you the information necessary to construct it yourself.

Their entity ID is the same for all customers (https://api.nsone.net/saml/metadata) but they use a different AssertionConsumerService URL for each customer.

You can get the certificate to encrypt to from their support, or from Okta documentation for NS1. However the only attribute they use is the username, so you may not care about encrypting at all.

The unique-per-customer portion of the AssertionConsumerService example is the "SSO ID" that you get from their support when enabling SAML SSO.

Example SP metadata 
<?xml version="1.0"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://api.nsone.net/saml/metadata">
  <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://api.nsone.net/saml/sso/unique-per-customer" index="1" />
  </SPSSODescriptor>
</EntityDescriptor>

Profile Requirements

Assertions must be signed. Since you will have to maintain the SP metadata yourself, you shouldn't need to make any changes in relying-party.xml.

Encryption is supported, but not required. You do not need to involve them in changing this.

Account Provisioning

Users must be pre-provisioned in NS1's portal, or via their API. They appear to use a flat namespace for all user accounts, and recommended a format that looks like ePPN with "." and "@" replaced with "_", but this does not appear to be a hard requirement.

NameID Requirements

Their support initially stated that this was required to be the username you're sending, and that the format must be "unspecified". Upon further testing, that appears to not be the case. NameID seems to be completely ignored.

Attribute Requirements

NS1 requires an attribute named "ns1_username". The FriendlyName of this attribute appears to be ignored. If following their recommended format, this can be created from a simple username with something like the example below.

Example attribute definition 
    <AttributeDefinition id="nsoneUsername" xsi:type="ScriptedAttribute">
        <InputAttributeDefinition ref="uid" />
        <Script><![CDATA[nsoneUsername.addValue(uid.getValues().get(0).concat("@%{idp.scope}").replace(/[\.@]/g, "_"))]]></Script>
        <AttributeEncoder xsi:type="SAML2String" name="ns1_username" friendlyName="ns1_username" encodeType="false" />
    </AttributeDefinition>

No other attributes are supported.

Other Considerations

All logins starting at their portal set ForceAuthn to true. They don't seem to be able to disable this, so if your authentication doesn't support forced reauthentication, or it is otherwise undesirable, you may have to make your Identity Provider lie, or start at your Identity Provider with an Unsolicited login. Unsolicited logins are supported.


Related content