IDP Attribute Query
Francesco Malvezzi
francesco.malvezzi at unimore.it
Mon Feb 27 14:53:53 GMT 2012
Il 24/02/2012 18:49, James Drews ha scritto:
>
>
> On 2/24/2012 11:38 AM, Cantor, Scott wrote:
>> On 2/24/12 12:34 PM, "James Drews"<drews at engr.wisc.edu> wrote:
>>> I've got the SP correctly authenticating to the first IDP, and it also
>>> issues a query to the second IDP with the PVI it got from the first.
>> With the aggregation plugin, I assume? Just clarifying.
>>
>
> Yup.
>
>>
>> Not of that type. You need to build your own plugin to do this, and then
>> have it respond to that format.
>>
>
> Got any pointers for building the plugin? Example somewhere?
Is it not enought to ride the
<resolver:PrincipalConnector xsi:type="Direct"
xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="direct"
nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
which you maybe are not using elsewhere?
(i.e. changing definition from Transient to Direct)
So the attribute from the SP arrives to the IdP as a principal and you
can build a (database)DataConnector with a filterTemplate like:
<![CDATA[
#if (requestContext.getProfileConfiguration().getProfileId() !=
"urn:mace:shibboleth:2.0:profiles:saml2:query:attribute")
SELECT FROM TABLE WHERE
UID=$requestContext.principalName
#else
SELECT FROM TABLE2 WHERE
OTHER_UID=$requestContext.principalName
#end
]]>
I hope it is not so ugly, because I was planning to do so (the only
difference is ldap instead of relational database)
regards,
Francesco
More information about the users
mailing list