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.