The Shibboleth IdP V4 software will leave support on September 1, 2024.


The IdP includes a command line tool included in older versions called "aacli", which stood for Attribute Authority Command Line Interface. The command line tool is a wrapper around a web interface that operates an administrative flow that runs the Attribute Resolver and Attribute Filter services, and produces output in various forms.

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


The same thing on the command line would be:

$ /opt/shibboleth-idp/bin/ -n jdoe -r

The parameters supported and their corresponding command line options are:

Query String

Command Line


Query String

Command Line



--requester, -r

Required, identifies the relying party (SP) to simulate a resolution for


--principal, -n

Required, names the subject/user to simulate a resolution for


--acsIndex, -i

Identifies the index of an <md:AttributeConsumingService> element in the SP's metadata, which allows certain uncommonly used filtering rules to be run



Value is ignored, if present causes the output to be encoded into a SAML 1.1 assertion



Value is ignored, if present causes the output to be encoded into a SAML 2.0 assertion

The tool essentially reproduces the results that would ordinarily be produced during a SSO or Attribute Query request. There are a couple of caveats to the reproduction of the results:

  • It bypasses any caching of results by data connectors so can occasionally provide different output, but this can help identify issues involving caching.

  • It can produce the same output under the assumption that plugins don't do unusual things that would be impossible to reproduce outside of a real transaction.

As an example of the second, if the resolution of data depended on some characteristic of the client, such as a network address, that would be unlikely to behave consistently, as would a scenario where the resolution of the data depended on details from the authentication process aside from just the canonicalized principal name.

For the vast majority of deployments, this tool can produce very accurate, often 100% accurate, results.

The format of the output is controlled by the presence or absence of the "saml1" and "saml2" options. With neither present, the output is derived directly from the internal attributes produced by the resolver, and are rendered using a simple JSON notation that is neutral in form and doesn't follow any particular standard. Otherwise, the configured encoding into SAML is done.

While this includes the production of a <NameID> or <NameIdentifier>, based on the overall configuration of the system, it will not account for the case of an SP explicitly requiring a particular format via its request messages.


V4.0 and upgraded systems include a bean defined in conf/admin/general-admin.xml to control aspects of the flow's behavior.

V4.1 includes properties to control various aspects of the flow's behavior using an internally-defined bean that may be overridden if required.

The general properties configuring this flow via admin/ are:









Audit log identifier for flow



Name of access control policy for request authorization



Whether authentication should be performed prior to access control evaluation



Whether the flow should allow for non-browser clients during authentication



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="" p:loggingId="%{idp.resolvertest.logging:ResolverTest}" p:policyName="%{idp.resolvertest.accessPolicy:AccessByIPAddress}" p:nonBrowserSupported="%{idp.resolvertest.nonBrowserSupported:false}" p:authenticated="%{idp.resolvertest.authenticated:false}" p:resolveAttributes="%{idp.resolvertest.resolveAttributes:false}" /> </util:list>

In older versions and upgraded systems, this list is defined in conf/admin/general-admin.xml. In V4.1+, no default version of the list is provided and it may simply be placed in conf/global.xml if needed.

How to sort 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.