SAML1.1 attribute release on Shib 3

[Morris, Andi]

Thanks Scott,
I'm now more confused.

We now have this working over the attribute push method. Great. However if that's an insecure method rather than using attribute query, even if it's limited to just the SPs that really require it, then I'd like to get this working using the backchannel and attribute query, which puts me back to square one with this problem. Where do I tell the IdP to use the attribute query? It's in the metadata:

        <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp3.dev.cardiffmet.ac.uk:8443/idp/profile/SAML1/SOAP/AttributeQuery"/>

Do I allow this in the same way I allowed the attribute push? In the relyingparty.xml? Looking here, I can't see that it has any Boolean type operators to enable it:
    <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
                <bean parent="Shibboleth.SSO" />
                <ref bean="SAML1.AttributeQuery" />
                <ref bean="SAML1.ArtifactResolution" />
                <bean parent="SAML2.SSO" />
                <ref bean="SAML2.ECP" />
                <ref bean="SAML2.Logout" />
                <ref bean="SAML2.AttributeQuery" />
                <ref bean="SAML2.ArtifactResolution" />
                <ref bean="Liberty.SSOS" />
            </list>
        </property>
    </bean>

And none are listed here:
https://wiki.shibboleth.net/confluence/display/IDP30/RelyingPartyConfiguration

Cheers,
Andi

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: 15 February 2017 17:58
To: Shib Users <users at shibboleth.net>
Subject: Re: SAML1.1 attribute release on Shib 3

On 2/15/17, 12:49 PM, "users on behalf of Morris, Andi" <users-bounces at shibboleth.net on behalf of amorris at cardiffmet.ac.uk> wrote:

> We're not intending to push any personally identifiable information
> via this method, just the targetedID and the scoped affiliation attributes. Is this still risky?

A targeted ID is a personally sensitive piece of information, it's entire reason for existing is to provide a way to identify somebody in a way that isn't easily associated to somebody without other data. Pushing them around in the clear in ways they can be linked back to people is really making them useless. Just don't bother and push over a fixed identifier that's much simpler to deal with.

> Should I pull the attribute query out of the metadata if I'm pushing
> the attributes? If I push, does this still go through the backchannel connection?

Pushing attributes is something you do to get rid of the back channel or to accomodate a system that doesn't support it. If you're getting rid of the back channel, then you alter your configuration to reflect that, and you publish updated metadata once it's no longer supported and in use and before completely disabling it.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
________________________________

[Cardiff Metropolitan University - Queens Anniversary Prizes 2015]<http://www.cardiffmet.ac.uk/news/Pages/Cardiff-Met-research-recognised-in-Queens-Anniversary-Prizes-for-Higher-and-Further-Education.aspx>