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