The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.
AACLI
- Scott Cantor
- Rod Widdowson
The IdP includes a greatly improved version of a command line tool included in previous versions called "aacli", which stood for Attribute Authority Command Line Interface. In V3, the command line tool is a wrapper around a web interface that operates an administrator 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:
http[s]://localhost/idp/profile/admin/resolvertest?principal=jdoe&requester=https%3A%2F%2Fsp.example.org%2Fsp
The same thing on the command line would be:
$ /opt/shibboleth-idp/bin/aacli.sh -n jdoe -r https://sp.example.org/sp
The parameters supported and their corresponding command line options are:
| Query String | Command Line | Description |
|---|---|---|
requester | --requester, -r | Required, identifies the relying party (SP) to simulate a resolution for |
principal | --principal, -n | Required, names the subject/user to simulate a resolution for |
acsIndex | --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 |
saml1 | --saml1 | Value is ignored, if present causes the output to be encoded into a SAML 1.1 assertion |
saml2 | --saml2 | 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. It operates very quickly since it runs within the existing application context. 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 only produce the same output if very unusual things aren't being done 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 very low-level details from the authentication process.
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 appropriate encoding into SAML is done, and this includes the production of a <NameID> or <NameIdentifier>, based on the overall configuration of the system.