Articles in this section

Single Sign On (SSO) for Duco

  • Updated
  • ~ minute read
Follow

What is SSO?

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.

If you want to enable SSO for your organisation, Duco's team will help. You can also find the required implementation steps below, alongside with the most common questions we get asked.

  • Which types of SSO does Duco support?

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

 

Implementation Steps:

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 required:

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): -> "assertions" -> "attributes"
    • The user's first name should be mapped to first_name
    • The user's last name should be mapped to last_name
  • A private key is also needed to sign SAML Requests with.
  • You also need to whitelist the following IP addresses in your firewall. To get the IPs you will need to run the host command on your environment. Here is an example:
$ host ENVIRONMENT.duco-app.com
ENVIRONMENT.duco-app.com has address ###.###.###.###
ENVIRONMENT.duco-app.com has address ###.###.###.###
ENVIRONMENT.duco-app.com has address ###.###.###.###

 

What information will you need to provide to Duco's Team?

  • IDP SSO (Single Sign On) and SLO (Single Log Off) target URLs
  • Target audience
  • The public key of the keypair used to sign SAML Requests. SHA-2 fingerprint of the public key, where available.
  • IP addresses used to connect to Duco's temporary testing environment (in case those IP addresses may differ from the IPs of the users)

 

SSO FAQs

  • 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 after authenticating with the IdP server. By default, the user will have no permissions assigned to the account. Note that once SSO is enabled, manual user creation will be disabled.

  • After SSO is enabled, can users log in using usernames?

Duco's team will ask you for an initial list of seed users during Onboarding. The very same login details (emails provided during that phase), need to be used for SSO login. Duco does not support the use of any additional email addresses and/or usernames.

  • When a new user account is auto-generated at first login, can Duco recognise first and last names?

If the email added is non-delimited (e.g. johnsmith@abc.com), Duco won't be able to identify the first and last name, and as such any user accounts that are auto-generated on first login will then require a manual edit to parse out the first from the last name (Duco by default will register "johnsmith" as being both the first and last name). However, if the email is delimited (e.g. john.smith@abc.com), Duco will be able to identify John as being the first name, and Smith, the last name when auto-generating the account. 

  • Can we control permissions with AD (active directory) 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?

Switching off SAML after enabling it will cause users to be unable to log in. If you need to have that switched off, please submit a Support Ticket.

  • 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. 

  • 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