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 Webtop.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 Webtop.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 Webtop.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 Webtop.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 Webtop.com as a relying party. When the Webtop.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 Webtop.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
Webtop.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 Webtop.com as a provider issuing a SAML request. According to the SAML specification, the string is a URL identifying Webtop.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.
Find more useful information in our list of the most related articles:
