Configuration Reporting

Overview

The IdP includes a command line tool called “dumpconfig”, which is a wrapper around a web interface that operates an administrative flow that mocks up the internal state of a request from a particular SP running a particular profile flow and produces its best guess at the “effective” profile settings applied to the request.

This is very much approximate, as the IdP’s capability to dynamically derive settings makes it impossible to fully replicate the possible inputs to deployer-supplied custom strategies for deriving settings, but the feature does at least perform metadata lookup and replicates the MetadataDrivenConfiguration features.

The underlying web interface, which is managed as an AdministrativeConfiguration, looks like this:

http[s]://localhost/idp/profile/admin/dumpconfig?saml2&profile=saml2%2Fsso%2Fbrowser&requester=https%3A%2F%2Fsp.example.org%2Fsp

The same thing on the command line would be:

$ /opt/shibboleth-idp/bin/dumpconfig.sh --saml2 --profile saml2/sso/browser -r https://sp.example.org/sp

The parameters supported and their corresponding command line options are:

Query String	Command Line	Description

Query String	Command Line	Description
requester	--requester, -r	Required, identifies the relying party (SP) to simulate a request from
profile	--profile, -P	Required, full or partial URL identifying a specific IdP profile to simulate
protocol	--protocol	The `protocolSupportEnumeration` URI to use in accessing metadata for the relying party (if a predefined constant won't suffice)
saml1	--saml1	Value is ignored, if present designates that SP metadata supporting SAML 1.1 be used
saml2	--saml2	Value is ignored, if present designates that SP metadata supporting SAML 2.0 be used
cas	--cas	Value is ignored, if present designates that SP metadata supporting CAS be used
oidc	--oidc	Value is ignored, if present designates that SP metadata supporting OIDC be used

The output is in JSON format and will expose configuration settings in various ways to provide useful output. Settings that are recognizably absent are omitted, but many “default” settings will be exposed because the system cannot tell at this layer whether a supplied value was or wasn’t defaulted.

Sorting Output

Output may be sorted using jq or xq (part of yq).

To sort JSON : ... | jq 'walk( if type == "array" then sort else . end )'

To sort SAML : ... | xq -x 'walk( if type == "array" then sort else . end )'

On macOS, jq and xq may be installed using Homebrew brew install jq python-yq or MacPorts.

Reference

The general properties configuring this flow via admin/admin.properties are:

Name	Default	Description

Name	Default	Description
idp.dumpconfig.logging	DumpConfig	Audit log identifier for flow
idp.dumpconfig.accessPolicy	AccessByIPAddress	Name of access control policy for request authorization
idp.dumpconfig.authenticated	false	Whether authentication should be performed prior to access control evaluation
idp.dumpconfig.nonBrowserSupported	false	Whether the flow should allow for non-browser clients during authentication
idp.dumpconfig.resolveAttributes	false	Whether attributes should be resolved prior to access control evaluation

To replace the internally defined flow descriptor bean, the following XML is required:

<util:list id="shibboleth.AvailableAdminFlows">
 
    <bean parent="shibboleth.AdminFlow"
        c:id="http://shibboleth.net/ns/profiles/dumpconfig"
        p:loggingId="%{idp.dumpconfig.logging:DumpConfig}"
        p:policyName="%{idp.dumpconfig.accessPolicy:AccessByIPAddress}"
        p:nonBrowserSupported="%{idp.dumpconfig.nonBrowserSupported:false}"
        p:authenticated="%{idp.dumpconfig.authenticated:false}"
        p:resolveAttributes="%{idp.dumpconfig.resolveAttributes:false}" />
 
</util:list>

No default version of the list is provided and it may simply be placed in conf/global.xml if needed.