Azure SAML SSO on 9.2.3

Singing on to Self-Service, User Management, etc. via SSO can be made easy with Azure AD (recently renamed to Azure Entra for some inane reason). See PCUG Discuss: Single Sign-On for a deep dive on setting this up.

Changes

It appears Ellucian made some minor changes from 9.1.4 to 9.2.3. This is entirely observational.

• Outgoing SAML claim is now a GET request instead of a POST request.
• Outgoing SAML claim now contains a login_hint parameter with the username. It appears to bypass the requirement to re-type the username in some cases.
  
  • According to Microsoft's documentation, this should be the subject's NameID.
  • We have seen instances where Self-Service usernames in sAMAccountName style also match usernames in some other tenant - apparently Microsoft's consumer tenant (Hotmail, Skype, etc.) - and the user is not given the ability to sign in to the correct tenant. Our only solution so far is to change the username format to include your domain name, like user@school.edu.

Configuration

If you're moving from 9.1.x to 9.2.3, you must make a few changes to your AuthorizationSettings.json configuration:

• "Unique User Identifier" is now the required SAML claim.
  
  • Formerly, you could specify the claim.
  • Simply go into your Azure Enterprise App registration, remove any extra SAML claims, and edit the default UPN claim to match your PowerCampusIdentity and Campus6.dbo.PersonUser usernames. For example, you might pick user.onpremisessamaccountname if you want to use the traditional sAMAccountName.
    

    

• Download the metadata and certificate (Base64) from Azure and place in the \Certs directory.
  • Update the file paths to match.
    
  • Ellucian recommends adding the self-signed Azure certificate to the Trusted Root Certificates list. However, a more security-conscious solution is to import it to the machine's Trusted People list and change CertificateValidationMode to PeerOrChainTrust.

Example:

{
    "AuthenticationSettings": {
        "ActiveDirectory": {...},
        "ADFS": {
            "Stores": [
                {
                    "MetadataAddress": "something",
                }
            ]
        },
        "Login": {...},
        "SAML": {
            "Stores": [
                {
                    "Name": "SAML",
                    "IdPMetadata": "App_Data\\PowerCampus Self-Service.xml",
                    "Issuer": "powercampus:selfservice:prod",
                    "SignatureAlgorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256",
                    "SigningCertificateFile": "~\\App_Data\\certs\\saml-sp.pfx",
                    "SigningCertificatePassword": "test1234",
                    "SignatureValidationCertificateFile": "~\\App_Data\\certs\\PowerCampus Self-Service.cer",
                    "CertificateValidationMode": "PeerOrChainTrust",
                    "RevocationMode": "NoCheck"
                }
            ]
        }
    }
}

In this example, SigningCertificatePassword and SigningCertificateFile do nothing.

Our testing found that ADFS MetadataAddress cannot be blank, even if you're not using ADFS.

Our testing found that a RelayState parameter like ReturnUrl=http%3A%2F%2Fselfservice.school.edu%2FHome%2FLogIn%3FReturnUrl%3D%252F can make it appear that the user hasn't logged in.