SiteImprove offers a service that will have a spider check your links on your sites for validity and report if they are down. By default users are manually created and local to SiteImprove. If you want to use a different account to login, you need to setup Single Sign On (SSO), which Site Improve supports via SAML2. Thankfully, setting this up isn’t too difficult, though the available instructions on their site, currently, are for Okta, but we are going to be using CAS.
To do this you will need to do the following:
- Enable SAML Support in CAS
- Configure Your cas.properties File
- Generate and Configure Your IDP-Metadata
- Create Your Service
- Configure SiteImprove and Test
- Restrict Access
Enable SAML Support in CAS
If you have not already enabled support for SAML and for CAS to act as an IDP, add the following to your pom.xml file
<dependency>
<groupId>org.apereo.cas</groupId>
<artifactId>cas-server-support-saml-idp</artifactId>
<version>${cas.version}</version>
</dependency>
You may also need to add the following under the repository section of your pom.xml file
<repositories>
...
<repository>
<id>shibboleth-releases</id>
<url>https://build.shibboleth.net/nexus/content/repositories/releases</url>
</repository>
...
</repositories>
Once you’ve done that, move on to configuring your cas.properties file before you rebuild your war overlay package and restart tomcat.
Configure Your cas.properties File
With SAML Support turned on, we can now set the settings needed to generate our idp-metadata.xml file. Open your cas.properties file and set the following;
#==========================
# SAML Authentication
#==========================
cas.authn.samlIdp.entityId=${cas.server.prefix}/idp
cas.authn.samlIdp.scope=example.com #replace this with yours
cas.authn.samlIdp.metadata.privateKeyAlgName=RSA
cas.authn.samlIdp.metadata.location=file:/etc/cas/saml
cas.authn.samlIdp.attributeQueryProfileEnabled=true
Save the file and now rebuild your mav overlay using the command “mvn clean package”. After which you should restart Tomcat.
Generate and Configure Your IDP-Metadata
If you restarted Tomcat in the previous step and didn’t already have IDP metadata generated, CAS will generate that and its accompanying signing and encryption keys now. The generated file will be fairly complete and only needing some minor modification. The only thing you should need to do is uncomment the <AttributeAuthorityDescriptor> section in your idp-metadata.xml file. Other than that, it wouldn’t hurt to flesh out your <ContactPersons> in the file, but that isn’t required.
The <AttributeAuthorityDescriptor> section should look like this
<AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<shibmd:Scope regexp="false">your_scope.com</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
<!-- Your generated signing cert info here -->
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://your_cas_server.com/cas/idp/profile/SAML1/SOAP/AttributeQuery"/>
<AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://your_cas_server.com/cas/idp/profile/SAML2/SOAP/AttributeQuery"/>
</AttributeAuthorityDescriptor>
Create Your Service
Next we need to make a service in CAS for SiteImprove. At this point you’re going to need grab a few details from SiteImprove which can be found under Settings -> Single Sign On -> SAML Authentication -> Configure. Under the SiteImprove Service Provider Details section, make not of the Metadata URL and Entity ID properties as we will need them in our service definition. These are important because they are specific to your account.
If you are using something other than the JSON Service Registry for CAS, you’ll need to adapt the below configuration to your own.
File Name: SiteImprove-10000010.json
{
"@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService",
"serviceId" : "^https://sso.siteimprove.com/auth/Saml2/<your siteimprove account id>",
"name" : "SiteImprove SAML",
"id" : 10000010,
"evaluationOrder" : 1,
"usernameAttributeProvider" : {
"@class" : "org.apereo.cas.services.PrincipalAttributeRegisteredServiceUsernameProvider",
"usernameAttribute" : "sAMAccountName"
},
"attributeReleasePolicy" : {
"@class" : "org.apereo.cas.services.ReturnMappedAttributeReleasePolicy" ,
"allowedAttributes" : {
"@class" : "java.util.TreeMap",
"sAMAccountName" : "Username",
"mail" : "Email",
"givenName" : "FirstName",
"sn" : "LastName"
}
},
"requiredNameIdFormat" : "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
"metadataLocation" : "https://sso.siteimprove.com/auth/Saml2/<your account number here>/Metadata",
"signAssertions": true,
"signResponses": false
}
A quick break down of the file above:
- serviceId is your SiteImprove Metadata URL
- usernameAttributeProvider is set to use the sAMAccountName as the username
- attributeReleasePolicy is being configure to map sAMAccountName to Username, mail to Email, givenName to FirstName, and sn to LastName as these attributes are expected by SiteImprove
- requireNameIdFormat is overriding the format of the username and setting it to persistent
- signAssertions is set to turn because SiteImprove requires that assertions from our IDP be signed
- signResponses is set to false, because if both signAssertions and signResponses are true, then assertions must be encrypted and to my knowledge, SiteImprove doesn’t support that.
Once you are done editing the service file, save and give Tomcat one more reboot.
Configure SiteImprove and Test
Now that we have our IDP setup and our service configured, we can now tell SiteImprove what it needs to know. For this part you only need to configure two parameters.
Under the section “Your Identity Provider Details” set the Login URL to your HTTP-Redirect SSO endpoint.
https://your_cas_server.com/cas/idp/profile/SAML2/Redirect/SSO
Next, enter the contents of the file etc/cas/saml/idp-signing.crt into the Certificate input.
Once you have done the above steps, click the “Save and Test” button at the bottom of the page. Note that you may need to do this twice before SiteImprove will pull up your login site as the configuration page has a somewhat short timeout and will throw a page not found error on the first attempt after timeout. All you need to do is click the button again and it should work. If every thing is good, you should be greeted by a screen saying the login was successful and the attributes it pulled back.
Restrict Access
With your SSO now working for SiteImprove, you’ll want to secure your CAS service because SiteImprove does not restrict access for sign-ins. The reason for this is that when you use SSO for SiteImprove, users are created by signing in via SSO. So, if you want to restrict who can authenticate, you need to setup your CAS service to handle authorization. Thankfully, this is pretty easy.
All you need to do is open your service definition and add the following section to your service definition:
"accessStrategy" : {
"@class" : "org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy",
"enabled" : true,
"ssoEnabled" : true,
"requiredAttributes" : {
"@class" : "java.util.HashMap",
"memberOf" : [ "java.util.HashSet", [ "<group DN here>" ] ]
}
}
The above snippet tells CAS that for someone to sign in to the service, they must have the specified group DN present in their memberOf attribute (make sure you are pulling memberOf as part of your principle attributes or it is being released for this service).
If you hate the idea of have that huge group DN in your service definition and instead want something smaller and easier to use, you can setup a groovy script for attribute release that processes the memberOf attribute and only keeps the names of the groups and puts them in a new variable called, groups.
Say by adding something like this:
"attributeReleasePolicy" : {
"@class" : "org.apereo.cas.services.GroovyScriptAttributeReleasePolicy",
"groovyScript" : "classpath:your_groove_script.groovy"
}
note: classpath points to src/main/resources in your maven overlay directory
Example snippet of looping over the attributes by key in groovy
def formattedAttribues = [:] //loop through the principles attributes args[0].each { key, value -> switch(key) { case 'memberOf': def roles = [] //iterate over groups and pullout only the content of CN for (group in value) { def m = group =~ /CN=(.*?)(?:,[A-Z]+=|$)/ //add the matched CN if ((m)) { roles.add(m.group(1)) } } //add parsed groups to groups in formattedAttributes map formattedAttribues['groups'] = roles break default: formattedAttribues[key] = value break } }; return formattedAttributes;
And that’s it, now you can use the line below in your service definiton, instead of checking for the whole group DN
"groups" : [ "java.util.HashSet", [ "<group name here>" ] ]
