SAML1.1 attribute release on Shib 3

[Alex Stuart]

Hi Andi,

Your IdP is configured to support SAML 1 Attribute Query in the <ref bean="SAML1.AttributeQuery" />. An attribute query is made by an SP when it doesn't receive any pushed attributes.

The UK federation "strongly recommend[s] that SAML 1.1 Browser/POST is never implemented with attribute push" in our Technical Recommendations for Participants, so I'm pleased that you're looking to get the backchannel working. And, yes, your IdP's registration does include a SAML 1 AttributeService endpoint.

We think port 8443 of your test IdP is misconfigured. Not only do we see issues connecting with openssl, but also nmap probing of port 8443 and various browsers trying to connect there. Our Test SP says 
"
2017-02-15 16:37:03 ERROR Shibboleth.AttributeResolver.Query [858]: exception during SAML query to https://idp3.dev.cardiffmet.ac.uk:8443/idp/profile/SAML1/SOAP/AttributeQuery: CURLSOAPTransport failed while contacting SOAP endpoint (https://idp3.dev.cardiffmet.ac.uk:8443/idp/profile/SAML1/SOAP/AttributeQuery): Unknown SSL protocol error in connection to idp3.dev.cardiffmet.ac.uk:8443
"

Is there a middlebox doing something clever to port 8443?

More generally, I'll post to this list tomorrow outlining some of the things that the UK federation is doing to address our chronic case of SAML 1.

Regards,
Alex

> On 15 Feb 2017, at 18:08, Morris, Andi <amorris at cardiffmet.ac.uk> wrote:
> 
> 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>
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 

—
Alex Stuart
UK federation support team
alex.stuart at jisc.ac.uk



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3861 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20170215/ea2cfffa/attachment.p7s>