Using TopClass SAML based SSO

TopClass currently supports multiple authentication methods including IDP based SAML. This SSO method will allow seamless access to TopClass via a link on the customer's web site or intranet. The authentication approach within TopClass allows authentication methods to be chained so that SAML SSO can be validated first and in the event of a failure it can be configured to do the following:

• Redirect to the customer site for authentication
• Use the TopClass form based authentication.

Description of Service

TopClass currently supports IDP based SAML 2.0 which allows the customer to manage authentication to their own SSO software.  TopClass is configured as a Service provider which will validate SAML based requests upon receipt.

WBT Systems Responsibilities

WBT is responsible for the following:

• Working with the customer's IT personnel to exchange metadata necessary to establish a trust relationship between the LMS Service Provider (SP) and the customer's Identity Provider (IdP).
• Configuring the LMS SP to receive authentication requests from customer's IdP.
• Operation of the LMS Service Provider.
• Providing the relaying party information

Customer Responsibilities

.The Customer is responsible for the following:

• Working with TopClass Support to exchange metadata necessary to establish a trust relationship between the LMS Service Provider (SP) and the customer's Identity Provider (IdP).
• Providing their metadata to TopClass Support along with a URL to be redirected to upon logout.
• Configuring the customer's IdP to initiate authentication requests to the LMS SP.
• Installing, operating, configuring, and troubleshooting customer's IdP.
• Providing certificate (Base64 encoded) if required.
• (Technical Eligibility Requirement) A working Identity Provider (IdP) solution installed.
• (Technical Eligibility Requirement) Customer’s IdP supports SAML 2.0.
• (Technical Eligibility Requirement) Customer’s IdP supports Identity Provider‑initiated requests.

Implementation Process

To establish a Single Sign-On (SSO) relationship, TopClass Support follows a structured implementation process:

1. The customer confirms that all technical eligibility requirements are met.
2. The TopClass Support project manager schedules an SSO call with the customer to review next steps, timeline, roles and responsibilities, and required data.
3. Metadata is exchanged between the customer and TopClass Support to set up a test implementation.
4. TopClass Support collaborates with the customer to establish a trust relationship between TopClass and the Identity Provider (IdP).

In addition to authentication setup, user records must be created to enable provisioning and sign-in. These records can be created manually, through an integration, or by using the batch creation tool within TopClass.

Technical Implementation

Each SAML Assertion request or response includes certificate details and may or may not be signed. If signed, the signature must be validated using the public key from the certificate, which must be stored on the TopClass application server.

The application checks all available certificates to validate the signature in the SAML Assertion. If partitioning is enabled, multiple certificates can be used. In this case, the application uses the Partition attribute to determine which sub-folder to scan for the appropriate certificate.

The certificate required to validate the request should be obtained from the Customer and saved in a sub-folder under SAMLcertificates.

Relaying-party.xml - Relaying party provider info

Each customer needs to add a relaying party for the WBT Systems TopClass instance.

    <rp:AnonymousRelyingParty provider="http://xxx/topclass/login.do?" defaultSigningCredentialRef="<credential name>"/>  
             
    <rp:DefaultRelyingParty provider="http://xxx/topclass/login.do?" defaultSigningCredentialRef="<credential name>" defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">

📘

Note

The provider name URL must be provided to the customer by WBT Systems and match the correct SAML SSO login URL for the specific instance. This must also match the entityId in the provided metadata.

📘

Note

The credential name should match the Security configuration info section name below. This means WBT Systems will provide the relaying party URL for the specific instance the customer is going to be hosted on. If the customer wishes to test on a UAT server then they will need relaying party information for the WBT TopClass staging server and will need to configure their SAML UAT environment separately for that environment.

Relaying-party.xml - Metadata provider info

The customer will need to add metadata provider section for the new relaying provider metadata. This is matched by the relaying party provider which is the metadata provider ID in the definition XML file wbt-metadata.xml.

 <metadata:MetadataProvider id="IdPMD2" xsi:type="metadata:FilesystemMetadataProvider"  
                                   metadataFile="C:\Program Files (x86)\ShibbolethIdp\metadata\wbt-metadata.xml"  
                                   maxRefreshDelay="P1D" />

📘

Note

The metadata EntityID must be configured for the specific instance the customer is to log on to and must match the provider name for the relaying party.

Relaying-party.xml – Security configuration info

The relaying party information section will reference a security credential and this section need to define the certificate and key used.

📘

Note

This is mapped to the defaultSigningCredentialRef attribute defined for the relaying party information (defaultSigningCredentialRef="IdPCredential2").

Copy

<security:Credential id="<credential name>" xsi:type="security:X509Filesystem">  
        <security:PrivateKey>C:\Program Files (x86)\ShibbolethIdp/credentials/{key name}</security:PrivateKey>  
        <security:Certificate>C:\Program Files (x86)\ShibbolethIdp/credentials/{cert name}</security:Certificate>  
    </security:Credential>

Attribute-resolver.xml – partition and username info

The metadata requires two attributes to be populated:

• Partition (Group) – Used to identify the company. This is only required if partitions are enabled. The Partition attribute is a constant value, so a static data connector is defined to include it in every response.
• Username – The user’s username, which must match the login name in TopClass. The Username attribute is taken from LDAP (commonly the principalName or another identifier) and must exactly match the username stored in TopClass.The username must be passed in the SAML Subject as the NameId attribute.