New Jetty Releases Available — July 6, 2018

New versions of the Jetty java servlet engine have been released for the 9.2.x, 9.3.x, and 9.4.x branches. These versions address five security vulnerabilities.

As a result, all deployers of the Shibboleth Identity Provider software utilizing Jetty (the default in IdP 3.0+) must deploy these updates.

Please note that these security vulnerabilities do NOT impact Shibboleth Service Providers.

For Linux

If you have deployed Shibboleth IdP on Linux using the recommended instructions, you will need to manually redeploy Jetty to ensure that you are running the latest version of either Jetty 9.2 or 9.3:

9.2.x – 9.2.25.v20180606 or later
9.3.x – 9.3.24.v20180605 or later

 

Please note that these security vulnerabilities do NOT impact Shibboleth Identity Providers deployed using the Tomcat Servlet Engine.

For Windows

The Shibboleth Consortium has announced a Windows -only service release for Shibboleth Identity Provider (IdP) taking the latest version of the IdP for Windows to v. 3.3.3.1.

This service update deploys a new version of Jetty which corrects the vulnerabilities outlined in the security advisory.

The update can be downloaded here.

Nature of the Vulnerabilities

The vulnerabilities are with various components of the Jetty Servlet Engine. For more information on the scope of the vulnerabilities, see the official announcement posting on the Jetty forums.

Need help?

IDM Integration is always available to assist with your emergency patch or with planning updates for your Shibboleth or SAML-based Single Sign On (SSO) Infrastructure. Contact us to schedule a consultation with one of our Shibboleth Exports regarding your environment or planning your Identity Provider upgrade today!

Security Advisory for Shibboleth IdP – May 16, 2018

The Shibboleth Consortium announced today a security advisoryShibboleth Security Advisory October 4, 2017 for  Shibboleth Identity Provider (IdP). Also announced was a new release of the Shibboleth Identity Provider (v. 3.3.3), which corrects the vulnerabilities outlined in the security advisory. This update can be downloaded here.

You can view the full text of the advisory here.

Please note that this security advisory does NOT impact Shibboleth Service Providers.

Nature of the Vulnerability

The vulnerability is related to how Shibboleth Identity Provider — when configured to act as a Central Authentication Service (CAS) server — issues CAS tickets. In particular, the default method for generating these tickets “creates a risk of issuing duplicate ticket identifiers in some cases” due to a weak random number generator.

A duplicate ticket identifier could result in a user usurping another users active, valid session.

Are you vulnerable?

Your Identity Provider is vulnerable if and only if:

  1. Your Identity Provider is configured to act as a CAS server using the built-in CAS functionality of Shibboleth IdP v3+, AND
  2. You have configured ticket generation using the (default) SimpleTicketService method.

Please note that the Shibboleth Identity Provider does use the SimpleTicketService ticket generation by default, so it’s imperative to verify your configuration if you use the CAS functionality within Shibboleth.

We encourage your to check your Shibboleth configuration. The file conf/cas-protocol.xml contains all configuration for the CAS protocol support within Shibboleth.

If you are using the SimpleTicketService it is critical that you apply this patch immediately.

We recommend that all deployers — regardless of known, specific vulnerability — update to Identity Provider v. 3.3.3 during the soonest available maintenance window.

Need help?

IDM Integration is always available to assist with your emergency patch or with planning updates for your Shibboleth or SAML-based Single Sign On (SSO) Infrastructure. Contact us to schedule a consultation with one of our Shibboleth Exports regarding your environment or planning your Identity Provider upgrade today!

Security Advisory for Shibboleth SP — January 12, 2017

The Shibboleth Consortium announced today a security advisoryShibboleth Security Advisory October 4, 2017 for all versions of Shibboleth Service Provider (SP).

Please note that this security advisory does NOT impact Shibboleth Identity Providers (IdP). 

According to the security advisory the problem exists due to the version of the XMLTooling-C library used by Shibboleth. This library is used by Shibboleth to parse the XML content of the SAML Assertions that are posted to the service provider. The issues:

“make it impossible to fully disable Document Type Definition (DTD) processing.”

“Through addition/manipulation of a DTD, it’s possible to make changes to an XML document that do not break a digital signature but are mishandled by the SP and its libraries. These manipulations can alter the user data passed through to applications behind the SP and result in impersonation attacks and exposure of protected information.”

Therefore this vulnerability can result in a malicious user modifying a SAML assertion.

Are you vulnerable?

Some platforms are more vulnerable than others; for example Windows systems have a version of the XMLTooling which has DTD-specification disabled. Linux (and Mac) systems running Shibboleth SP, however, currently appear to be vulnerable.

If you are not using the Shibboleth SP v2.6.1 we recommend immediately updating.

Furthermore, if you are using the 2.6.1 release of Shibboleth, please ensure that your XMLTooling libraries are up-to-date.

For Red Hat/CentOS, we recommend using the official Shibboleth Repositories.  To see a list of all packages which need updating within this repo:

$ sudo yum --disablerepo='*' --enablerepo='security_shibboleth' list available

 

Non-RPM-based installations will need to manually update to v.1.6.3 of the XMLTooling-C library.

Need help?

IDM Integration is always available to assist with emergency patching, or with planning for updates for your Shibboleth or SAML-based Single Sign On (SSO) Infrastructure. Contact us to schedule a consultation with one of our Shibboleth Engineers regarding your SSO environment today!

Security Advisory for Shibboleth IdP – October 4, 2017

The Shibboleth Consortium announced today a security advisoryShibboleth Security Advisory October 4, 2017 for all versions of Shibboleth Identity Provider (IdP). Also announced was a new release of the Shibboleth Identity Provider (v. 3.3.2), which corrects the vulnerabilities outlined in the security advisory. This update can be downloaded here. View the full text of the advisory here.

Please note that this security advisory does NOT impact Shibboleth Service Providers.

According to the security advisory the vulnerability exists due to a flaw with the library used by Shibboleth to provide authentication against and attribute resolution from LDAP servers. According to the advisory, Shibboleth Identity Providers prior to v. 3.3.2 are vulnerable if and only if:

1. The connection is via LDAPS (NOT StartTLS).
2. The connection’s trust configuration is left to the default Java cacerts file, so-called default JVM trust.

Are you vulnerable?

You can relatively quickly gauge whether your IdP is vulnerable; simply examine the “ldap.properties” file located in your Shibboleth Identity Provider configuration directory. Look for the lines:

idp.authn.LDAP.useStartTLS = false
idp.authn.LDAP.sslConfig = jvmTrust

If your configuration matches this, then we strongly encourage updating your Identity Provider to the latest release as soon as possible.

Please note that the Shibboleth Identity Provider does not use the settings described by the security advisory by default. Therefore, unless your specific configuration calls for use of the default JVM Trust, it is unlikely that your particular Identity Provider is vulnerable.

However, we recommend that all deployers — regardless of known, specific vulnerability — update to Identity Provider v. 3.3.2 during the soonest available maintenance window.

Need help?

IDM Integration is always available to assist with your emergency patch or with planning updates for your Shibboleth or SAML-based Single Sign On (SSO) Infrastructure. Contact us to schedule a consultation with one of our Shibboleth Exports regarding your environment or planning your Identity Provider upgrade today!

Shibboleth SP Install on Amazon AMI Linux

Here is a recipe for installing the Shibboleth Service Provider on Amazon AMI Linux and integrating with the built-in Apache.

Install Prerequisites

Use the following command to install all of the prerequisite tools:

  • yum install automake boost-devel chrpath doxygen gcc-c++ groff httpd-devel libidn-devel openldap-devel openssl-devel redhat-rpm-config stunnel unixODBC-devel
  • yum install rpmdevtools rpm-build

*Note: the above steps install Apache 2.2

Manually Install Shibboleth Dependencies via SRPM

You will want to grab the latest SRPM files that match your version of Amazon Linux.  This recipe is based on Amazon Linux AMI release 2015.09, which is compatible with RHEL 6 SRPMs.  The instructions below are based on the Shibboleth SRPM install instructions.  If you grab newer libraries, you will need to adjust the file names in the recipe.

Use following sequence to build and install all prerequisites.  There are a lot of dependencies, so the order of the steps below matters.

  1. log4shib
  2. xerces-c
  3. xml-security-c
  4. curl-openssl (on RHEL/CentOS 6.x and later)
  5. xmltooling
  6. opensaml
    • wget http://download.opensuse.org/repositories/security://shibboleth/RHEL_6/src/opensaml-2.5.3-1.1.el6.src.rpm
    • rpmbuild –rebuild opensaml-2.5.3-1.1.el6.src.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/libsaml8-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/libsaml-devel-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/opensaml-schemas-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/opensaml-debuginfo-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/opensaml-bin-2.5.3-1.1.amzn1.x86_64.rpm
  7. shibboleth
    • wget http://download.opensuse.org/repositories/security://shibboleth/RHEL_6/src/shibboleth-2.5.3-1.1.el6.src.rpm
    • rpmbuild –rebuild –without builtinapache -D ‘shib_options –with-apxs24=/usr/sbin/apxs –with-apr1=/usr/bin/apr-1-config –enable-apache24’ shibboleth-2.5.5-3.1.el6.src.rpm
      • **Note: this is an important step to make sure you build the Shib Apache module to work with Apache on AMI Linux.  You may need to adjust the path for apxs and apr-1-config
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/shibboleth-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/shibboleth-devel-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/shibboleth-debuginfo-2.5.3-1.1.amzn1.x86_64.rpm
  8. Copy the Apache config for Shibboleth
    • cp /etc/shibboleth/apache22.config /etc/httpd/conf.d/shib.conf
  9. Configure Shibboleth
    • Edit /etc/shibboleth/shibboleth2.xml to configure your SP and add your IdP metadata
  10. Start the shibd process
    • /usr/sbin/shibd

InCommon Federation Metadata Config for Shibboleth IdP V3

We have been helping customers upgrade from Shibboleth IdP 2.x to V3, and we wanted to highlight some common configuration questions we have received.

If you want to configure your Shibboleth IdP V3 to participate in the InCommon Federation, you need to add some configuration to your metadata-providers.xml file that may not directly translate from your Shibboleth 2.x configuration.

First, make sure that you have downloaded and verified InCommon’s metadata signing cert and copied the signing cert to your ${idp.home}/credentials/ directory.

Next, edit your metadata-providers.xml file and add the following code before the closing </MetadataProvider> tag.

<MetadataProvider id="ICMetadata"xsi:type="FileBackedHTTPMetadataProvider" refreshDelayFactor="0.125" maxRefreshDelay="PT2H" httpCaching="memory"
backingFile="%{idp.home}/metadata/incommon-metadata.xml" metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml">

  <MetadataFilter xsi:type="SignatureValidation" certificateFile="${idp.home}/credentials/inc-md-cert.pem" requireSignedMetadata="false">
</MetadataFilter>
<MetadataFilter xsi:type="EntityRoleWhiteList">
<RetainedRole>md:SPSSODescriptor</RetainedRole>
</MetadataFilter>
</MetadataProvider>

Contact us if you need help planning your Shibboleth IdP 2.x to V3 upgrade.

Shibboleth IdP V3

Shibboleth IdP version 3.0 was released on December 22, 2014.  Detailed documentation on Shibboleth IdP v3 can be found on the Shibboleth wiki.

With the Shibboleth Consortium expected to announce the end date for the V2 Identity Provider soon, it is worth moving to Shibboleth IdP V3 for new deployments.  If you are running Shibboleth IdP V2, you may want to start planning your upgrade to V3.

System Requirements

You can find the most up-to-date list of system requirements here.  While there are no specific operating system requirements, Linux, OS X and Windows are recommended.  Oracle Java or OpenJDK versions 7 and 8 are the supported Java environments, and only Tomcat 8.x and Jetty 9.2.x are officially supported servlet containers.

What’s New in IdP V3?

Internet2’s recent press release does a good job of summarizing the key features of Shibboleth IdP V3:

  • uApprove integration, which provides individuals with information about the attributes requested by service providers and gives individuals the ability to control attribute release
  • Built-in support for CAS, which means IdP V3 can handle both on-campus SSO and federated authentication to access external SAML-protected services
  • Ability to support multiple algorithms for signing and encryption simultaneously, allowing organizations to increase the security of their transactions without compromising compatibility with older systems
  • Built-in next generation federation features such as the emerging Metadata Query Protocol, allowing on-demand metadata lookup that is replacing the need to compile ever-larger metadata aggregates
  • Support for internationalizing user interface and error messages

The Shibboleth wiki has more detail on all of the changes you can expect from IdP V3.

We are excited about Shibboleth IdP V3, and we are ready to help you plan your upgrade or new installation.  We have flexible support options to help you get past configuration issues as well as comprehensive support options for your IdP environment.

Keep an eye on our blog for more articles to help you make the transition from Shibboleth IdP V2 to V3.

Configuring Microsoft IIS with multiple Shibbolized websites, using lazy sessions

We recently solved a Shibboleth problem for a customer who had Microsoft IIS, with multiple Shibbolized web sites using lazy sessions, and we wanted to share the solution.

Setup:

The system worked correctly when Shibboleth was activated by browsing to the protected path in the RequestMap.  The application needed to support multiple login methods, so the lazy session initiation was used when Shibboleth requested at the beginning of the user session (see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreationParameters)

This session initiator for the SP that was configured as the override would form the SAML request as if it was the default application.

The original configuration in the RequestMapper:

 <Host name="pc2.idmintegration.com">
 <Path name="Default/sso" authType="shibboleth"
 requireSession="true" applicationId="access"/>
 </Host>

The updated configuration in the RequestMapper:

<Host name="pc2.idmintegration.com"
 applicationId="access">
 <Path name="Default/sso" authType="shibboleth"
 requireSession="true" applicationId="access"/>
 </Host>

We found through the Native.log file that the ISAPI module was not using the correct applicationID for the requests outside the path in the Path statement.  Adding the applicaitonID at the host level with no other requirements for a Shib session let the application override work.  This allowed the site to work without forcing Shibboleth auth, but allowed the ISAPI module to relate the Session call to the correct application ID.

We suspect that the combination of Microsoft IIS with multiple Shibbolized websites, using lazy session initiation is rare, but since we couldn’t find any documentation on this specific setup, we thought we’d share our solution.

IDM Integration Joins InCommon Affiliate Program

IDM Integration has joined Internet2’s InCommon Affiliate Program. IDM Integration (IDMI) helps customers build identity management solutions. From helping a commercial service provider overcome a single Shibboleth or SAML issue to helping an organization develop a comprehensive SSO environment, IDMI specializes in open source software integration and support. The company provides support for a wide variety of SSO layering technologies and custom integrations with ERPs, portals, learning management systems and other software systems.

“We are pleased to have IDM Integration join our Affiliate Program,” said Klara Jelinkova, senior associate vice president and chief information technology officer at the University of Chicago and chair of the InCommon Steering Committee. “We value their experience in higher education and with some of the key technology used by InCommon participants.”

The InCommon Affiliate Program provides the research and education community with a way to safely and efficiently connect with partners that can help build the necessary underlying infrastructure that supports federated identity and access management.

“We started IdM Integration because we saw a need for commercial Shibboleth support,” says Dave Alexander, one of the partners in IDMI. “We’ve been working behind the scenes with service providers to help them federate with InCommon, so we’re excited to finally join InCommon as an affiliate. We specialize in providing support and professional services for Shibboleth, and we are looking forward to helping higher ed and K-12 institutions realize the value of implementing federated authentication.”

As a way of celebrating joining the Affiliate Program, IDMI is offering InCommon participants a $100 discount on its most popular service, the Shibboleth Health Check. The service ($400 with the discount) includes two hours of phone consultation followed by two hours of research and follow-up to help resolve issues in the Shibboleth and single sign-on environment. The offer is good through October 31, 2014. Email sales@idmintegration.com for more information.

About IDM Integration
Since 2007, IDM Integration has been solving identity management problems. Whether we are helping customers overcome a single technical issue, or are developing comprehensive identity management solutions that integrate with existing systems, we thrive in problem solving. In addition to problem solving, we also provide support and training to ensure continued success for our clients. We support a wide variety of organizations, including corporate, nonprofit and academic, with a strong focus on commercial service providers. For additional information, please visit http://idmintegration.com/

About InCommon
InCommon®, operated by Internet2®, serves the US education and research communities, supporting a common framework of trust services, including the US identity management trust federation for research and education, a community-driven Certificate Service, an Assurance Program providing higher levels of trust, and a multifactor authentication program. InCommon has more than 600 participants, including higher education institutions and research organizations, and their sponsored partners, making federated identity available to more than 7.8 million individuals. For more information, see www.incommon.org and www.internet2.edu.

Shibboleth Monitoring

When you deploy a production Shibboleth IdP or SP, it is important to plan out a monitoring approach.

The Shibboleth project web site has good information on how to enable IdP and SP status monitoring.

If you are deploying a clustered IdP or SP, you should make sure you are checking the status of each node in the cluster as well as the overall health of the environment.  When you enable IdP and SP status monitoring, make sure you lock down which machines or networks are allowed to connect to your IdP or SP.

Here are some other things to consider as part of your monitoring approach for Shibboleth:

  • CPU, memory and disk space
  • Log files
  • NTP
  • Shibboleth related processes (eg. Apache, Tomcat, shibd)
  • Metadata refresh
  • Certificate expiration
  • Monitoring for your authentication or web-based SSO system
  • Monitoring for your attribute repository
  • End-to-end functional monitoring of Shibboleth authentication flow (local SP, federated SP)
  • Capturing audit logs to help with security response (eg. SIEM integration)
  • Stats monitoring – keeping track of the total number of logins and number of logins by service
  • Configuration file consistency, especially if you have a clustered IdP or SP

If you have a monitoring system like SCOM or Nagios, you can add Shibboleth process monitoring and simulate a login to a test SP or federated service.  Some federations offer Shibboleth monitoring services, and the Shibboleth community has contributed Shibboleth monitoring tools.

Contact us if you need help implementing monitoring for your production Shibboleth IdP or SP environment.