Setting up a compatible or custom Single Sign-On (SSO) app

If you cannot find the app you like to configure in our predefined SSO configurations (tailored SSO setup) or compatible SSO configurations (generic SSO compatible apps), you may use this custom SSO app configuration.

To be able to follow this guide you need an app that supports SSO with SAML and to possess  the technology understanding needed to explore and test a custom SSO setup yourself.

 

Tools that can be used for your testing:

SAML-tracer Chrome extension, a debugger for viewing SAML messages. This can help determine whether the URL's are correct.



This custom SSO setup follows a service provider initiated authentication flow, beginning with the user navigating to the service provider application and getting redirected to the identity provider (IdP) for login.

 

We give you the option to supply the following from your custom app to make it work with Desktop.com as the identity provider (IdP):

ACS URL
Assertion Consumer Service URL. The URL that will consume the login attempt. 

 

One required piece of information that you must provide to the identity provider is the Assertion Consumer Service (ACS) URL address, which Desktop.com will use to verify that the SAML messages from that service provider can be serviced. Otherwise, the identity provider will ignore it as a DDoS attack. The ACS URL is a combination of the Secure Token Server subsystem address, its port number for handling SAML messages, the SAML binding, and any necessary information that is specific for CIC or ICWS.

ACS URL address use the following syntax: https://SecureTokenServer:Port/AuthenticationType

Entity ID
This will be the URL that will be the unique identifier for your application. The Entity ID is automatically generated and corresponds by default to the metadata URL.

 

Start URL
Application Start URL. You use an application start URL to start the federation process with your application. Use this field if you want to override the application url.

 

Map unknown claims
Enable this if you want to send unknown claims as is

 

Signed response

Enable to sign responses with a private key

 

Name ID Format
If needed, specify the Name ID format by selecting from the list, or leave unspecified.

Name ID Format defines the name identifier formats supported by the Desktop.com as identity provider. Name identifiers are a way for providers to communicate with each other regarding a user. Single sign-on interactions support the following types of identifiers:

 

SAML:2.0:nameid-format:persistent

 

SAML:2.0:nameid-format:transient

 

SAML:1.1:nameid-format:emailAddress

 

SAML:1.1:nameid-format:unspecified

 

SAML:1.1:nameid-format:X509SubjectName

 

SAML:1.1:nameid-format:WindowsDomainQualifiedName

 

SAML:2.0:nameid-format:kerberos

 

SAML:2.0:nameid-format:entity

 

The Name ID format list is an ordered list and the first Name ID has the highest priority in determining the Name ID format to use. If the user does not specify a Name ID to use when initiating single sign-on, the first one in this list is chosen and supported by Desktop.com.

 

A persistent identifier is saved to a particular user's data store entry as the value of two attributes. A transient identifier is temporary and no data will be written to the user's persistent data store

 

Name ID Value Map

This attribute specifies mapping between the NameID Format attribute and a user profile attribute. If the defined Name ID format is used in protocol, the profile attribute value will be used as NameID value for the format in the Subject. The syntax of each entry is:

 

NameID Format=User profile attribute

 

Add Claim

It is needed to create appropriate claim rules that specify Desktop.com as a relying party. When the Desktop.com sends a SAML response to the custom app, it includes a SAML assertion that contains one or more claims. A claim is information about the user and its groups. A claim rule maps that information into SAML attributes. This lets you make sure that SAML authentication responses from your Desktop.com contain the necessary attributes to check permissions for federated users.

 

Name ID (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”) 

This attribute(claim) specifies mapping between the NameID attribute and a user profile attribute. If the defined Name ID format is used in protocol, the profile attribute value will be used as NameID value for the format in the Subject.


Other claim types:

Email         “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Given Name    “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname”
Family Name       “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname”
UPN “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”
Custom (For this claim attribute name you want to map has to be provided along with user attribute it maps to)

 

Configuration Instructions

Here are the SAML settings you need to input into your application, but you can also download the Metadata XML (using the link provided in the configuration instruction) and upload it if they allow it.

 

SSO URL

Desktop.com identity provider (IdP) SSO URL.

 

SSO Logout URL

Users are directed to this specific URL after they logout.

 

Issuer / Entity ID

A unique string that identifies the Desktop.com as a provider issuing a SAML request. According to the SAML specification, the string is a URL identifying Desktop.com as an authenticator.

 

Certificate

X.509 certificate that contains the public key. SAML signing certificates ensure that messages are coming from the expected identity and service providers. The SAML certificate is used to sign SAML requests, responses, and assertions from the service to relying applications. 

 

Copy the certificate and use it inside the app you are configuring. You can also download the certificate and upload it using the link provided in this section..

 

Certificate fingerprint

The fingerprint is exchanged out-of-band between the sender and the receiver and is configured on the receiving end. It uniquely identifies a certificate with the public key that the sender uses to sign the SAML messages that it sends.