Assessing Attribute Release Policies with AACLI

Assessing Attribute Release Policies with AACLI

Shibboleth Identity Provider (IdP) includes an incredibly useful and powerful tool for determining, without doing an actual authentication sequence, what attributes will be released for a given user (principal) and service provider.

That tool is the Attribute Authority Command Line Interface (AACLI).

You can invoke the AACLI tool by executing a script in the terminal, i.e. {idp.home}/bin/ (or {idp.home}/bin/aacli.bat for Windows installations):

[user @ /opt/shibboleth-idp/]$ .bin/ -n user -r

If you have correctly configured Access Controls for Administrative Functions, you may access the output of the script via a special resolvertest endpoint as such:

This URL you could access via curl for use in custom scripting.


Query Parameter Shell Flag Description
principal –principal, -n Names the user for which to simulate an attribute resolution.
requester –requester, -r Identifies the service provider for which to simulate an attribute resolution.
acsIndex –acsIndex, -i Identifies the index of an <AttributeConsumingService> element in the SP’s metadata.
saml2 –saml2 Value is ignored, if present causes the output to be encoded into a SAML 2.0
saml1 –saml1 Value is ignored, if present causes the output to be encoded into a SAML 1.1


Shell Script, Simple Output

[ shibboleth-idp]# ./bin/ -n john -r


"requester": "",
"principal": "john",
"attributes": [

    "name": "uid",
    "values": [
              "John"          ]

    "name": "mail",
    "values": [
              ""          ]

    "name": "sn",
    "values": [
              "Doe"          ]


Shell Script, Output formatted as SAML 2.0 Assertion

[ shibboleth-idp]# ./bin/ -n john -r


<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion ID="_057aa390d3cebb0d9c7b90524667edd1"
    IssueInstant="2020-09-18T16:20:55.242Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            NameQualifier="" SPNameQualifier="">AAdzZWNyZXQx49glc8r4c80yYO2LWKJ9yHk4GV3IzMIZvBYsEKNnbmxuRfySoLSAZBu7H3OTxNzJKTPIpTJ0o2Ye9YnyMIve0at0+QWNSGz/Rjuu1PW/wvse24m40MFlYWQoWu2EDO5cmYWYUWze/jBPtuyCN0XqM6MJczyAujM=</saml2:NameID>
        <saml2:Attribute FriendlyName="uid"
            Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml2:Attribute FriendlyName="mail"
            Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml2:Attribute FriendlyName="sn" Name="urn:oid:" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

URL Request, Simple Output


URL Request, Output formatted as SAML 2.0 Assertion


Attribute Resolution Trouble?

You can use AACLI to debug issues related to attribute release… but why is a given attribute not being released? Here are some common issues:

  • The attribute isn’t being provided by a data connector. This is perhaps because the attribute is null for that principal.
  • There is no attribute definition defined for that attribute.
  • The attribute definition does not define a dependency from which to pull the source attribute (i.e. explicitly specify the attribute or say which resolver it’s from).
  • The attribute definition is marked as a dependency only attribute and thus is not released from the resolver.
  • The attribute definition does not define an encoder appropriate for the given request protocol (i.e. SAML1 encoder exists but SAML2 doesn’t).
  • The attribute is being filtered out by the attribute filter policy.

The last point, the lack of an appropriate policy releasing the attribute for a given SP in attribute-filter.xml is the most likely cause of a missing attribute, and as such should most likely be checked first.

Need help debugging an attribute issue? Contact us to discuss your needs. IDM Engineering is a team of dedicated, honest SSO support engineers that are standing by to help!