Shibboleth and Academic Federations: Hardening the IdP and Federation Metadata Trust

A Shibboleth Identity Provider in a research and education federation is trusted by thousands of services it has never met, so a stale metadata feed, an over-generous attribute release rule or an exposed signing key affects partners well beyond the campus. Federations such as InCommon publish signed SAML metadata about their members, and eduGAIN aggregates national federations' metadata so that a home login works at services in other countries. This guide covers the operational controls that keep that trust sound: verifying and expiring metadata in the Shibboleth IdP, consuming InCommon and eduGAIN feeds, writing attribute filter policy, protecting keys and administrative functions, logging, and taking part in Sirtfi incident response. It is written for identity engineers who run a Shibboleth IdP and for the security teams who support them. The broader sector picture, including the REFEDS MFA Profile and the Research and Scholarship category in detail, is in the Research Institution Identity Security Guide; this page goes deeper on the IdP and the federation plumbing.

This is an independent guide from NHI Mgmt Group, based on the Shibboleth Consortium's public Identity Provider 5 documentation and the published guidance of InCommon, eduGAIN and REFEDS as of November 2026. It is not sponsored or reviewed by the Shibboleth Consortium or any federation. Product features change, so confirm settings against the current Shibboleth and federation documentation.

Key takeaways

• Signature verification is the linchpin. The Shibboleth documentation calls the SignatureValidationFilter the linchpin of most deployments' security; pair it with RequiredValidUntilFilter in the "sign and expire" model for every remote metadata source.
• Do not let TLS stand in for signatures. InCommon's guidance is to verify the XML signature on every refresh, reject metadata without a valid, plausible validUntil, and obtain the signing certificate through a secure channel.
• Release nothing by default. Shibboleth attribute filtering only removes values, deny rules override permit rules, and a processing failure releases nothing; build policies from permits for named partners or entity categories.
• Keep DEBUG logging away from encryption. Setting idp.loglevel.encryption to DEBUG writes cleartext versions of encrypted content to the process log.
• Sirtfi is an operational promise. Asserting Sirtfi in metadata and publishing a REFEDS security contact commits your team to coordinated incident response with federation partners.

How identity and access work in Shibboleth and academic federations

Three layers of trust stack on top of each other. Each has an owner and a failure mode.

eduGAIN's technical pages describe how the MDS works: it pulls federation metadata every hour, validates each federation's feed, drops a feed that fails validation and keeps the last valid copy, and removes a federation's data if errors persist beyond that copy's validUntil. The aggregate is signed with a key generated at a public key signing ceremony in Stockholm on 8 March 2022; the certificate is published at https://technical.edugain.org/mds-v2.cer with its SHA-256 fingerprint on the same page. Check the fingerprint out of band before you trust the certificate.

Inside the IdP, the SAML relying party is identified by its entityID in metadata. Everything the IdP decides about a partner (which keys to trust, which endpoints to send assertions to, which attributes to release) depends on that metadata being authentic and current, which is why the metadata pipeline is the first thing to harden. For SAML protocol risks such as signature wrapping and assertion replay, see the SAML Security Guide.

Admin roles and privileged access

A Shibboleth IdP has no separate administrator console in the product sense; privilege sits with whoever can change its configuration, read its keys or reach its administrative flows.

• Configuration and keys: the IdP's signing and encryption private keys and its configuration directory are the crown jewels. Anyone who can read the signing key can mint assertions accepted by every federated service. Restrict file system access to the service account and a small operations group, keep configuration in version control with review, and hold an offline backup of keys under dual control. See the Golden SAML and Federation Trust Abuse Defence Guide.
• Administrative flows: the IdP exposes REST-style administrative functions such as configuration reload, the status page and attribute resolver diagnostics, configured in conf/admin/admin.properties. The administrative framework supports authentication and access control policies with user-based or attribute-based rules, and idp.feature.authenticated marks a flow as requiring authentication. Require authentication for every administrative flow you enable and restrict them to administrator networks.
• Federation registration: in InCommon, Site Administrators update entity metadata (for example to assert Sirtfi). Treat that role as privileged: name at least two people, use MFA on the federation's administration tool, and review the holders when staff change.
• Staff authentication: administrators, research computing staff and help desk operators who can reset credentials should sign in with phishing-resistant factors. See the Phishing-Resistant MFA Guide.

Integrations, API tokens and service accounts

Consuming federation metadata

InCommon's best practice for consuming metadata sets these rules, which map directly to Shibboleth configuration:

The Shibboleth SignatureValidationFilter page adds two details that matter in practice. Filter order matters: signature validation must come before any filter that alters the metadata. And alwaysVerifyTrustedSource defaults to false, so the root signature is not rechecked when a FileBackedHTTPMetadataProvider loads its own local backup file; protect that backup file's directory as carefully as the configuration. InCommon also notes that MDQ server IP addresses change, so allow HTTPS to mdq.incommon.org by name rather than pinning addresses in firewall rules.

Other metadata filters let you narrow trust: EntityRoleFilter, PredicateMetadataFilter (for example to accept only named entities or entity categories for a sensitive SP integration), EntityAttributesFilter, NameIDFormatFilter, AlgorithmFilter and ScopeFilter appear in the IdP 5 filter documentation.

Attribute release

Attribute release is governed by conf/attribute-filter.xml, whose root element is <AttributeFilterPolicyGroup>. Each <AttributeFilterPolicy> applies only when its <PolicyRequirementRule> is true, and contains <AttributeRule> elements, keyed by attributeID, with a <PermitValueRule> or <DenyValueRule>. The documentation states that filtering can only remove attributes or values, never add or change them; denied values are removed from the permitted set, so deny overrides permit; and on a processing failure the engine releases nothing. Use the AACLI tool to test what a given relying party would receive before deploying a change.

Decision guidance: entity category matching scales across thousands of SPs and suits low-risk, research-oriented attributes; named-entity rules suit anything involving personal data beyond the R&S bundle, licensed resources or institution-internal services. A small institution can start with one R&S policy and a short named list; a large research university should keep each service's release rule in its own reviewed file, using the idp.service.attribute.filter.resources property to load several files. For the authorisation side, see the Authorisation Models Guide.

Signing key rollover with federation partners

Because partners read your public key from federation metadata, a signing key change is a coordinated event, not a local one. Plan it as a sequence: publish the new certificate in your federation metadata alongside the old one; wait until partners have had time to refresh (federations generally expect partners to refresh metadata at least daily, so allow a margin of several days for slower consumers; check your federation's own rollover guidance); switch the IdP to sign with the new key; watch idp-process.log and help desk tickets for SPs that still fail; then remove the old certificate from metadata. Keep the old key available for rollback until the old certificate has been removed. An unplanned rollover after a suspected key compromise follows the same steps compressed into hours, which is a strong reason to rehearse it. The same logic applies when a federation rotates its own metadata signing key: install the new certificate, verified by fingerprint, before the federation switches. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Service accounts and directory connections

The IdP itself authenticates to directories and attribute stores. Give it a dedicated read-only directory account per environment, protect its bind credential in configuration with file permissions limited to the service account, and alert on its use from anywhere other than the IdP hosts.

Logging and detection

The IdP 5 logging configuration lives in conf/logback.xml, a reloadable service, with levels set through idp.loglevel.* properties in conf/idp.properties.

Logs are kept for idp.loghistory days (default 180), roll over at midnight and are compressed. The documentation warns that idp.loglevel.encryption at DEBUG logs cleartext versions of encrypted content, that the encrypter and PROTOCOL_MESSAGE loggers capture unencrypted SAML content (both off by default), and that the MDC header feature records client-supplied header values that can be manipulated. Keep these off in production and limit who can read the logs.

Alert on: metadata providers failing to refresh or failing signature validation; a sudden rise in authentications to one SP or from one account across many SPs (a compromised account used federation-wide); changes to attribute-filter.xml or key files outside a change window; and administrative flow access. These are the events a Sirtfi partner will ask about during an incident.

Metrics: hours since last successful signed metadata refresh for each provider (target under 24); share of relying parties released attributes by named or category rules rather than broad defaults; number of attribute release rules reviewed in the last year; time to provide logs to a federation partner during an incident exercise; and number of administrators with access to the signing key.

Hardening baseline

1. Inventory trust: list every metadata source, signing certificate, attribute release policy and directory connection.
2. Fix the metadata pipeline: SignatureValidationFilter first, RequiredValidUntilFilter, at least daily refresh or MDQ, fingerprint-verified certificates. Test by loading a deliberately expired copy in staging and confirming it is rejected.
3. Tighten attribute release: move to permit rules per entity category or named entity; test each change with AACLI against representative SPs before deploying.
4. Protect keys and configuration: file permissions, version control with review, offline backups under dual control, and a documented rollover plan coordinated with your federation's metadata update process.
5. Lock down admin flows: authentication and network restrictions on every enabled administrative function.
6. Signal MFA correctly: implement the REFEDS MFA Profile as the sector guide describes, so SPs can require it.
7. Join incident response: assert Sirtfi through your federation's registration process and publish a monitored REFEDS security contact.
8. Logging and patching: ship audit logs to the SIEM, confirm DEBUG settings are off, subscribe to Shibboleth Consortium announcements and apply security updates promptly. Roll back configuration changes from version control and reload the affected service.

Common misconfigurations

• Metadata fetched over HTTPS without a signature filter: the provider trusts whatever the server returns, which InCommon's guidance explicitly rules out.
• Filters in the wrong order: a filter that alters metadata runs before SignatureValidationFilter, so validation sees modified content and fails or is bypassed.
• Refresh tied to validUntil: the IdP refreshes weekly because the feed is valid for longer, and misses partners' key rollovers.
• Release-all defaults: a legacy policy releases a full attribute set to any SP in the aggregate, including eduGAIN entities the institution has never reviewed.
• Encryption DEBUG left on: troubleshooting settings remain after an incident and write cleartext assertion content to logs kept for 180 days.
• Sirtfi asserted, contact unmonitored: the security contact is a former employee's address, so a partner's incident notification goes unanswered.

Practitioner checklist

• Configure SignatureValidationFilter first and RequiredValidUntilFilter on every remote metadata provider.
• Verify federation signing certificates by fingerprint through a separate channel before installing them.
• Use MDQ where your federation offers it, or refresh aggregates at least daily.
• Write attribute release as permit rules per entity category or named entity, and test with AACLI.
• Restrict access to signing keys, configuration and the metadata backup directory.
• Require authentication and network restrictions for all administrative flows.
• Keep encryption and protocol message DEBUG logging off in production and protect log access.
• Assert Sirtfi and keep a monitored REFEDS security contact in your metadata.
• Rehearse a federated incident: suspend an account and supply logs to a partner within your target time.

Standards and references

• Shibboleth: SignatureValidationFilter (Identity Provider 5)
• Shibboleth: AttributeFilterConfiguration (Identity Provider 5)
• Shibboleth: LoggingConfiguration (Identity Provider 5)
• Shibboleth: AdministrativeConfiguration (Identity Provider 5)
• InCommon: Best practices for consuming metadata
• eduGAIN: Metadata
• REFEDS: Sirtfi
• InCommon: Baseline Expectations for Trust in Federation

Related NHI Mgmt Group resources: Research Institution Identity Security Guide, Federation and Trust Relationships Guide, Identity Federation Failure Modes, SAML Security Guide.