aacli for oidc op

[Martin Leonhartsberger]

hi peter, 

just tested on one of my idp's, the aacli also outputs attributes for an oidc OP using the client-id as requester. 
possibly my relying-party predicate at OIDC.SSO p:alwaysIncludedAttributes="#{ {... does the trick here as there is no parameter for a scope request on aacli I'm aware of. 

/aacli.sh -n marie.curie -r *

{
"requester": "*",
"principal": "marie.curie",
"attributes": [


  {
    "name": "SECCLASS",
    "values": [
        "1"
    ]
  },


  {
    "name": "samlPairwiseID",
    "values": [
        "..."
    ]
  },

]
}

-martin

On 06.10.23, 10:18, "users on behalf of Peter Schober via users" <users-bounces at shibboleth.net <mailto:users-bounces at shibboleth.net> on behalf of users at shibboleth.net <mailto:users at shibboleth.net>> wrote:


I'd like to test attribute (ok, claims) release with the Shibboleth
IDP when used as OIDC OP.


Seems to me that either aacli does not support that (yet?) or I'm
doing something wrong by feeding it the OIDC RP's `client_id`
as `requester` parameter:


$ ./bin/aacli.sh -n foo -r bar


{
"requester": "bar",
"principal": "foo",
"attributes": [




]
}


The output simply echoes the input, no matter whether the `principal`
or the `requester` exist, attributes are always empty.


Any suggestions for testing the OP part of the machinery (client
registration, attribute resolver, attribute filter, attribute
registry) other than using real clients and watching the audit log (or
process log) closely?


-peter
-- 
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw <https://shibboleth.atlassian.net/wiki/x/ZYEpPw>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>