Service Provider Configuration Diagnostics

Shibboleth SP Configuration

A common Shibboleth Service Provider configuration file is:

shibboleth2.xml

It typically contains elements describing the application identity, session management, authentication handlers, metadata providers, and other settings.

Lint Configuration File

This command checks whether selected configuration blocks exist.

How to Use

1. Select Lint Configuration File.
2. Upload your shibboleth2.xml file.
3. Click Execute Command.
4. Review the results.

Configuration Elements Checked

Example Configuration Structure

<SPConfig xmlns="urn:mace:shibboleth:3.0:native:sp:config">
  <ApplicationDefaults entityID="https://sp.example.org/shibboleth">
    <Sessions>
      <SSO entityID="https://idp.example.org/idp/shibboleth">
        SAML2
      </SSO>
    </Sessions>
    <MetadataProvider
      type="XML"
      path="metadata.xml"/>
  </ApplicationDefaults>
</SPConfig>

This example is illustrative and not a complete production configuration.

Understanding Results

The checker reports whether each selected element is present.

Example:

ApplicationDefaults : ✓ block found

Sessions : ✓ block found

SSO : ✓ block found

MetadataProvider : ✓ block found

Missing critical blocks are marked as errors.

Missing advisory blocks are marked as warnings.

Summary Result

If the required ApplicationDefaults and Sessions blocks are present, the checker may report:

General SP XML structure checks : ✓ valid

This indicates that the two selected critical element checks passed.

It does not establish that the complete SP configuration is valid or operational.

Configuration Lint Limitations

The command does not perform full Shibboleth configuration schema validation.

It does not comprehensively check:

• Attribute values
• Metadata trust configuration
• Session lifetime compatibility
• Handler endpoint correctness
• TLS connectivity
• Authentication policy
• Complete SP version compatibility
• Actual federated login behavior

Lint Attribute Map File

Shibboleth attribute maps translate incoming SAML attributes into application-visible identifiers.

The typical file is:

attribute-map.xml

How to Use

1. Select Lint Attribute Map File.
2. Upload attribute-map.xml.
3. Click Execute Command.
4. Review the parsed entries.

Expected XML Root

The checker expects an Attributes root in the Shibboleth attribute-map namespace.

Example:

<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map">
  <Attribute
    name="urn:oid:2.5.4.42"
    id="givenName">
    <AttributeDecoder
      xsi:type="StringAttributeDecoder"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
  </Attribute>
</Attributes>

Checks Performed

For each direct Attribute entry, the checker examines:

Example Output

id=givenName, name=urn:oid:2.5.4.42, decoder=None

The checker includes the decoder description in its output.

However, its current attribute lookup for xsi:type does not correctly handle the fully qualified XML namespace representation in standard ElementTree parsing. Consequently, valid decoder types may appear as None.

Summary

The command reports:

• Number of Attribute entries checked
• Number of entries missing required fields

Limitations

The checker does not fully validate attribute decoder definitions, data types, or the runtime mapping behavior.

An attribute map can pass this check while containing other configuration problems.

Check XML Discovery

The Discovery command inspects an SP configuration for a configured identity provider discovery URL.

A discovery service can help users select an Identity Provider in a federated authentication environment.

How to Use

1. Select Check XML Discovery.
2. Upload a Shibboleth SP configuration XML file.
3. Click Execute Command.
4. Review the discovery URL and DNS results.

XML Elements Examined

The command searches for:

Sessions

and a nested:

SSO

element.

It then reads the SSO element's:

discoveryURL

attribute.

Example

<SSO discoveryURL="https://discovery.example.org/wayf">
  SAML2
</SSO>

Diagnostic Steps

Recognized Endpoint Names

The checker recognizes paths ending in:

wayf
eds
discofeed

Other endpoint names produce an advisory warning.

This list is a heuristic, not an exhaustive definition of valid discovery service URLs.

DNS Resolution

The command extracts the hostname and attempts to resolve it using the application server's DNS configuration.

A successful DNS lookup indicates that the hostname resolves.

It does not establish that the discovery service is reachable over HTTPS or functioning correctly.

Common Errors

No Sessions Block

The uploaded XML does not contain the expected Sessions element in the configured Shibboleth namespace.

No SSO Block

A Sessions block was found, but no corresponding SSO element was identified.

Missing discoveryURL

The expected attribute was not configured.

Domain Resolution Failed

The application server could not resolve the discovery hostname.

Recommended Workflow

1. Check the main SP configuration structure.
2. Inspect the attribute map.
3. Verify discovery settings.
4. Resolve any relevant missing configuration.
5. Validate the full configuration using Shibboleth's native tools.
6. Test actual authentication in an appropriate environment.

Important: These commands are structural and diagnostic checks. They do not replace native Shibboleth configuration validation or an end-to-end SAML authentication test.