Articles in this section

Single Sign On (SSO) for Duco

  • Updated
  • ~ minute read
Follow

Introduction

Single Sign On (SSO) allows customers to set up authentication using their internal Identity Provider (IdP). This allows users to have a single password for all web applications which support SSO function.

Implementation Steps

Information for the Client:

For testing the following should be set:

SAML ACS URL = https://SSO testing environment url provided by Duco/saml/acs

Issuer name = https://SSO testing environment url provided by Duco/saml/metadata

 

For production the following should be set:

SAML ACS URL = https://your Duco url/saml/acs

Issuer name = https://your Duco url/saml/metadata

 

Client-Side Configuration:

 

This should be set up as an SP initiated application.

Set name identifier format to: `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`

2 additional assertions should be passed (case sensitive):

  1. The user's first name should be mapped to first_name
  2. The user's last name should be mapped to last_name

 A private key is also needed to sign SAMLRequests with.

 

Client Information required by Duco’s Client Services team

  • IDP SSO (Single Sign On) and SLO (Single Log Off) target URLs
  • Target audience
  • The public key of the keypair used to sign SAMLRequests. SHA-2 fingerprint of the public key, where available.

 

SSO FAQs

  • What SSO providers is Duco compatible with?

Duco’s SSO implementation should work with any SAML2.0 compatible identity provider - eg Okta, Azure, Auth0”. For a comprehensive list see here. 

  • What does Duco provide to ensure minimal downtime when setting up SAML SSO?

To ensure minimal impact to production, Duco configures a temporary testing environment to ensure the configurations can be tested. Once the testing is completed for SAML, Duco will enable SAML on a date agreed with the customer to coordinate this effort. This ensures enabling SAML on production does not impact end users and minimises the outage window to approximately 30 minutes. 

  • Do we still need to manually add new accounts, or does Duco create them automatically based on AD group?

When the user logs in for the first time Duco automatically creates the User account and authenticates with the IdP server. By default, the user will have no permissions assigned to the account. 

  • Can we control permissions with AD groups?

No, the permissions need to be managed inside of the Duco UI, which has a very mature RBAC that can be used to assign permissions. 

  • My company uses a sandbox environment. Does SSO work with with multiple environments? 

When you initially get set up with SSO, this is for one environment. If you are using multiple environments, you will need to get set up individually in each. You will need to make a request with your internal Duco admin to give you access to each environment.   

  • Does Duco also support Single Sign Off?

No. Currently Duco only supports Single Sign On.

  •  Will the user automatically get deleted from Duco if they are deleted from the AD?

No, the user will still exist on Duco but will not be able to authenticate.

  • What Hashing Algorithm is used for the authentication request signing?

 SHA-1 and Following of SHA-2 (SHA-256, SHA-384, SHA-512 but not SHA-224).

  • Does Duco sign SAML responses?

No, this function is currently not supported.

  • If a customer decides to switch off SAML, is this supported?

There are plans to test this function to ensure backward compatibility to go to local users.

  • Can you limit users from a specific AD Group’s ability to login to Duco?

No, current functionality does not limit restrictions based on AD groups. This is being reviewed as a feature request by our Product Management team. 

  • Can you prevent a user from seeing the login page if they are not part of a specific AD Group when using SSO?

Until users try to authenticate, the SaaS service does not know anything about their group privileges so limiting access to the landing page is not possible technically. An alternative is to put users in that AD Group behind a separate IP, then Duco can limit access to the login page for this IP address. 

  • Which SAML assertions or claims can Duco accept when using ADFS?

The following config is needed on ADFS side and these are the only claims and assertions supported by our current implementation:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "First Name", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"), query = ";mail,givenName,sn;{0}", param = c.Value);

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");

*New user accounts are automatically created when an individual first logs in with SSO. As such, you will find that the ability to manually create user accounts within Duco will be disabled. The new account will not have any permissions, these will need to be added by a Duco Administrator within your organization. To learn how to add users, please follow the instructions here.



Related articles