Configuring Apereo CAS as SAML Single Sign-On

Overview

This article explains how to configure MyWorkDrive as a SAML Service Provider (SP) with Apereo CAS acting as the SAML Identity Provider (IdP). When complete, users will authenticate through CAS before being granted access to MyWorkDrive.

For information about configuring other SAML providers in MyWorkDrive, see the SSO Setup Overview.

Active Directory Requirement
These instructions apply only to MyWorkDrive installations using Active Directory for user identity. MyWorkDrive does not maintain its own user database for SAML logins — it matches the username in the SAML assertion against a User Principal Name (UPN) in Active Directory to validate the user.

Before You Begin

What you will need:

• Administrative access to your CAS server
• Administrative access to the MyWorkDrive server
• A valid SSL certificate on CAS (used to sign SAML assertions)
• Your MyWorkDrive public hostname (e.g., myworkdrive.example.com)

MyWorkDrive version 7.1 and later has been validated with the following CAS environment:

Your CAS deployment must have access to an identity directory (LDAP/AD) or locally defined users, with usernames in email format. MyWorkDrive matches the CAS username against the Active Directory UPN.

Configuration overview — two steps:

1. Register MyWorkDrive as a Service Provider in CAS
2. Configure CAS as the Identity Provider in MyWorkDrive

Step 1 — Configure MyWorkDrive in CAS

You will need to create a SAML service entry for MyWorkDrive in CAS. The location of your service configuration files will vary by CAS implementation — the default when using a Gradle overlay is /etc/cas/services/.

SP Metadata URL

You can point CAS directly to the MyWorkDrive SP metadata URL rather than entering values manually. Use this URL in the metadataLocation field of your CAS SAML service JSON, substituting your actual MyWorkDrive hostname:

https://myworkdrive.example.com/SAML/ServiceProviderMetadata

Example CAS SAML Service JSON

Create a file in your services directory (e.g., MyWorkDrive-10000001.json) with the following content. Replace myworkdrive.example.com with your actual MyWorkDrive hostname:

json { "@class": "org.apereo.cas.support.saml.services.SamlRegisteredService", "serviceId": "MyWorkDrive", "name": "MyWorkDrive", "id": 10000001, "evaluationOrder": 10, "metadataLocation": "https://myworkdrive.example.com/SAML/ServiceProviderMetadata", "requiredNameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified", "attributeReleasePolicy": { "@class": "org.apereo.cas.services.ReturnAllowedAttributeReleasePolicy", "allowedAttributes": ["java.util.ArrayList", ["email", "givenName", "surname"]] }, "usernameAttributeProvider": { "@class": "org.apereo.cas.services.PrincipalAttributeRegisteredServiceUsernameProvider", "usernameAttribute": "uid" } }

Update the metadata URL
Replace myworkdrive.example.com with your MyWorkDrive server's published URL. The serviceId (Entity ID) must be unique for each SP registered in your CAS environment.

Two critical settings explained

1. requiredNameIdFormat

You must include the following line in the service JSON:

json "requiredNameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

MyWorkDrive specifically requests this NameID format. If CAS does not send it, login will fail with a generic error message that will be confusing to users.

2. usernameAttributeProvider — send the username as email

The usernameAttributeProvider block tells CAS to use the authenticated user's UID (e.g., user@example.com) as the SAML NameID sent to MyWorkDrive. MyWorkDrive then matches this email-format username against the user's UPN in Active Directory to validate access and create the appropriate SMB session.

json "usernameAttributeProvider": { "@class": "org.apereo.cas.services.PrincipalAttributeRegisteredServiceUsernameProvider", "usernameAttribute": "uid" }

Username must be in email format
If the username is not sent in email format, users will receive an error that their username was not found or does not match.

Step 2 — Configure CAS in MyWorkDrive

Configure CAS using the Custom SAML option in MyWorkDrive's Enterprise Settings. This requires directly editing the SAML configuration file on the MyWorkDrive server.

Edit saml.config

Open the following file in a text editor on the MyWorkDrive server:

C:\Wanpath\WanPath.Data\saml\saml.config

Replace the contents with the template below, substituting your own values where indicated:

<?xml version="1.0"?> <SAMLConfiguration xmlns="urn:componentspace:SAML:2.0:configuration"> <ServiceProvider Name="MyWorkDrive" Description="MWD Service Provider" AssertionConsumerServiceUrl="https://myworkdrive.example.com/SAML/AssertionConsumerService.aspx" LocalCertificateFile="C:\Wanpath\WanPath.Data\Settings\SAML\Certificates\mwd.pfx" LocalCertificatePassword="pfx_password" /> <PartnerServiceProviders> <PartnerServiceProvider Name="MyWorkDrive" Description="MWD Service Provider" AssertionConsumerServiceUrl="https://myworkdrive.example.com/SAML/AssertionConsumerService.aspx" LocalCertificateFile="C:\Wanpath\WanPath.Data\Settings\SAML\Certificates\mwd.pfx" LocalCertificatePassword="pfx_password" /> </PartnerServiceProviders> <PartnerIdentityProviders> <PartnerIdentityProvider Name="https://cas.example.com/cas/idp" Description="CAS Identity Provider" SignLogoutRequest="true" SignLogoutResponse="true" WantLogoutRequestSigned="false" WantLogoutResponseSigned="false" SingleSignOnServiceUrl="https://cas.example.com/cas/idp/profile/SAML2/Redirect/SSO" SingleLogoutServiceUrl="https://cas.example.com/cas/idp/profile/SAML2/POST/SLO" PartnerCertificateFile="C:\Wanpath\WanPath.Data\Settings\SAML\Certificates\cas-idp-signing.cer" /> </PartnerIdentityProviders> </SAMLConfiguration>

Values to replace

Do not change the ACS URL path
The path /SAML/AssertionConsumerService.aspx must remain exactly as shown. Only change the hostname portion.

Entity ID / SP Name
The SP Entity ID defaults to MyWorkDrive. If you change it, make sure the value matches in both the saml.config file and the CAS SAML service JSON (serviceId).

Download and install the CAS IdP signing certificate

You need to place the CAS IdP signing certificate on the MyWorkDrive server so it can verify CAS assertions. The certificate is typically located at /etc/cas/saml/idp-signing.crt on the CAS server.

On the CAS server (Ubuntu):

bash sudo cp /etc/cas/saml/idp-signing.crt /tmp/cas-idp-signing.cer sudo chmod 644 /tmp/cas-idp-signing.cer

Copy the certificate to your Windows server (from PowerShell):

powershell scp user@cas.example.com:/tmp/cas-idp-signing.cer ` C:\Wanpath\WanPath.Data\Settings\SAML\Certificates\

Verify the certificate downloaded correctly:

powershell Get-Content C:\Wanpath\WanPath.Data\Settings\SAML\Certificates\cas-idp-signing.cer

You should see output in this format:

-----BEGIN CERTIFICATE----- MIIDhTCCAm2gAwIBAgIE... (base64-encoded content) -----END CERTIFICATE-----

Alternatively, the certificate can be extracted from the CAS metadata URL if your CAS instance publishes it.

Troubleshooting

Troubleshooting checklist

If login fails after completing both configuration steps, work through this checklist:

• Check CAS logs — on the CAS server, run:
  sudo tail -f /opt/tomcat/logs/catalina.out | grep -i "saml\|error" or
• sudo tail -f /opt/tomcat/logs/catalina.out | grep -i "saml\|error\|MyWorkDrive"
• Verify the service loaded — confirm CAS picked up your service file:
  sudo cat /etc/cas/services/MyWorkDrive-10000001.json
• Confirm the certificate — make sure cas-idp-signing.cer on the Windows server matches the cert from CAS metadata
• Entity ID mismatch — the most common issue; verify the SAML AuthnRequest issuer is MyWorkDrive
• ACS URL mismatch — confirm the reply URL in the SAML response matches the ACS URL exactly
• Restart IIS — after editing saml.config, restart the MyWorkDrive application pool

Quick error reference

Frequently Asked Questions

My users get a "Welcome back, re-authenticate" loop when logging in through CAS

This message — "We have detected an existing single sign-on session for you. However, you are being asked to re-authenticate..." — most commonly occurs when requiredNameIdFormat is missing from the CAS SAML service JSON.

Add the following line to your service JSON and reload CAS services:

json "requiredNameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

Users receive a "SAML username does not match" error

The error SAML username (value) != Forms username (user@example.com) means the username in the SAML assertion does not match the user's UPN in Active Directory. Check two things:

1. Confirm your CAS service JSON includes the usernameAttributeProvider block with "usernameAttribute": "uid" so CAS sends the username in email format.
2. Confirm the user's UPN in Active Directory matches the UID that CAS sends in the assertion (e.g., user@example.com).

Users log in successfully but see no shares

If the folder list is empty after a successful SAML login, the cause is typically missing or incorrect server delegation settings. Ensure the MyWorkDrive server is trusted for delegation by your SMB file servers. See the Delegation Article for details.

For general SAML troubleshooting, see the Troubleshooting with SAML Tracer article for information about profiling the SAML login flow and diagnosing authentication errors.