Category Archives: Uncategorized

The Future of Shibboleth SP

The Future of Shibboleth SP

The Future of Shibboleth SP

Two days ago the Shibboleth Consortium quietly released the latest version of Shibboleth Service Provider for all platforms.

The Shibboleth Project has released a small update to the SP software, V3.3.0, and it is now available from the download site and packages for supported platforms on the mirrors.

This release, while acknowledged by the Consortium as a “small update” containing mostly small fixes and library updates, as well as a “sweep of the code to add deprecation warnings to more at risk features.”

was notable primarily for the fact that there’s a remarkable amount of commentary regarding the future of Shibboleth SP.

This includes commentary on the build process changing to move away from the OpenSUSE Build Service to a local, Docker-based process, which (according to the Consortium):

is a much faster process for us but it expands and constrains what we can support at the same time. As a result, a number of older platforms for which we have been unofficially producing packages but not supporting for some years will not see further package updates starting with this release.

The older platforms that appear to no longer be officially supported include macOS and SuSE. Meanwhile new support has been added for Amazon Linux and Rocky Linux. They go on to state that CentOS will no longer be officially supported later this year. This is due to the fact that CentOS is fundamentally changing it’s nature:

Some of this is also in response to the CentOS changes coming next year, and due to CentOS 8 no longer representing a fixed OS target, we will be dropping official support for it as of the end of this year, though it’s possible packages may still be produced for it in the future as part of our process.

Importantly, there’s also this comment regarding the future of Shibboleth SP:

Lastly, we want to note that this is probably the final minor version of the software in its current form and new features are unlikely. Attention will be shifting in 2022 and 2023 to redesigning the SP into a much smaller native footprint alongside a Java-based appliance that performs the work of shibd today. This will represent a large and likely breaking change to much of the way the SP is configured and works, so if you find that non-appealing for your needs, this is a good time to be evaluating alternatives.

A Java-based SAML SP

While it appears that there is no concrete plan at this time for the exact nature of a future “Service Provider ver. 4”, according to the design notes any such software is likely to be Java-based, so that all or most of the components that dictate the SAML- and XML-handling can be done with existing code leveraged by the Shibboleth Identity Provider.

This likely means a standalone Java appliance application that can be deployed alongside Apache, IIS, etc. in order to host the “SAML core” while minimizing the C code that’s necessary for the consortium to maintain.

According to the draft Design Notes:

there are some key requirements we probably have some consensus on that a new design would have to maintain:
1. Support for Apache 2.4 and ISS 7+, ideally in a form that leads more easily to other options in the future.
2. Support for the current very general integration strategy for applications that relies on server variables or headers.
3. Some relatively straightforward options for clustering.

which means that the new SP is likely to be largely functional for most deployers in the future as it is today.

This represents such a massive shift that those designing and building new SAML deployments may wish to avoid new deployments of Shibboleth due to the uncertain future.

Choosing a SAML Stack

That said, there’s effectively a large amount of calculus to perform when choosing the proper SAML stack, and the long-term future of a given platform is an element that’s always entered into that problem. The recent changes that’ll be occurring in the Shibboleth sphere should not be taken as the sole factor in determining whether to use or not use a given SAML stack.

Shibboleth continues to be a stable platform, in both the SP and IdP components, and we expect the new SP (when it is ultimately released) will be a good, solid choice for a service provider. It is just worth consideration of the fact that it’s likely to change in the (relatively) near future, perhaps in a major way.

As always, IDM Engineering stands ready to guide our clients toward the most stable, most cost-effective, and most easily-supported SAML solution for any given SAML stack. If you’re looking to deploy Shibboleth or another SAML implementation, and don’t want the headache of researching the nuances of choosing which stack or library to use, reach out to us today.

This entry was posted in Blog, Shibboleth, Uncategorized on by .

Configuring the CAS Management Webapp

Configuring the CAS Management Webapp

Configuring the CAS Management Webapp

This guide documents how to spin-up the CAS Management Webapp as an Apache Maven overlay. (You can do it with Gradle as well, but I prefer Maven.)

1. Pull down the repo.

mkdir /opt/cas/
git clone https://github.com/apereo/cas-management-overlay.git

You can browser the repository here: apareo/cas.

2. Edit etc/cas/config/management.properties:

— Add server names for CAS Management Webapp to authenticate, and details of the Management app itself:

cas.server.name: https://cas.example.edu
cas.server.prefix: https://cas.example.edu/cas
mgmt.serverName=https://idmutil04.kumc.edu
server.context-path=/cas-management
server.port=9443

— Add service registry. NOTE: Must be exactly what the CAS server uses, i.e. if you use the following configuration for an LDAP service registry in cas.properties on the CAS server, make sure to include this same config blob here. The following example demonstrates the LDAP Service Registry

# LDAP Service Registry
cas.serviceRegistry.ldap.ldapUrl=[REDACTED]
cas.serviceRegistry.ldap.baseDn=ou=CasTestServiceRegistry,ou=Services,o=IDVAULT
cas.serviceRegistry.ldap.bindDn=cn=casserviceregistry,ou=AuthAccounts,o=IDVAULT
cas.serviceRegistry.ldap.bindCredential=[REDACTED]
cas.serviceRegistry.ldap.serviceDefinitionAttribute=description
cas.serviceRegistry.ldap.idAttribute=uid
cas.serviceRegistry.ldap.objectClass=casRegisteredService
cas.serviceRegistry.ldap.searchFilter=(%s={0})
cas.serviceRegistry.ldap.loadFilter=(objectClass=%s)

3. Edit the pom.xml.

Include any additional dependencies you may have. For example, to include the LDAP Service Registry dependency:

<!-- LDAP Service Registry -->
<dependency>
  <groupId>org.apereo.cas</groupId>
  <artifactId>cas-server-support-ldap-service-registry</artifactId>
  <version>${cas.version}</version>
  <exclusions>
    <exclusion>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Note that I needed to exclude the dependency’s dependency on spring-web so that it wasn’t included twice, otherwise you may get an error on startup such as this:

More than one fragment with the name [spring_web] was found. This is not legal with relative ordering. See section 8.2.2 2c of the Servlet specification for details. Consider using absolute ordering.

See: https://stackoverflow.com/questions/55177367/more-than-one-fragment-with-the-name-spring-web-was-found-in-non-maven-projec

4. Edit etc/cas/config/users.properties to add your users, i.e.

user=foo,ROLE_ADMIN

Note: The ‘foo’ is for a legacy password field, can be anything there. This is obviated if you use a JSON or YAML authorization list.

5. Build and deploy the WAR file to Tomcat:

./build.sh package
sudo install -C -m 775 -o tomcat -g root etc/cas/config/* /etc/cas/config
sudo install -C -m 775 -o tomcat -g root target/cas-management.war /opt/tomcat/webapps
sudo systemctl start tomcat

Resources:

https://apereo.github.io/cas-management/5.3.x/installation/Installing-ServicesMgmt-Webapp.html

Looking for support for CAS? Look no further! Contact us for all of you SSO support needs!

This entry was posted in Blog, CAS, Uncategorized on by .