<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<p dir="auto" style="text-align:left; margin-top:25px; margin-bottom:25px; font-family:sans-serif; font-size:11pt; color:black; background-color:white">
Thanks for the detailed response there Scott. That's all very helpful indeed.</p>
<p dir="auto" style="text-align:left; margin-top:25px; margin-bottom:25px; font-family:sans-serif; font-size:11pt; color:black; background-color:white">
Alex, thanks also for replying and showing the test sp logs. That really helps to narrow this down. We have a load balancer providing reverse proxy, so I guess it must be something that's doing. As far as I know we're not doing any offloading, or similar type
inspection, but I will definitely look further at that when I'm back in tomorrow.</p>
<p dir="auto" style="text-align:left; margin-top:25px; margin-bottom:25px; font-family:sans-serif; font-size:11pt; color:black; background-color:white">
Thanks again all.<br>
Andi</p>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> users <users-bounces@shibboleth.net> on behalf of Cantor, Scott <cantor.2@osu.edu><br>
<b>Sent:</b> Wednesday, February 15, 2017 6:34:23 PM<br>
<b>To:</b> Shib Users<br>
<b>Subject:</b> Re: SAML1.1 attribute release on Shib 3</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 2/15/17, 1:08 PM, "users on behalf of Morris, Andi" <users-bounces@shibboleth.net on behalf of amorris@cardiffmet.ac.uk> wrote:<br>
<br>
> We now have this working over the attribute push method. Great. However if that's an insecure method rather than using<br>
> 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<br>
> backchannel and attribute query, which puts me back to square one with this problem.<br>
<br>
Insecure implies a binary, but this is about risk. I can't impose my risk calculus on others, I'm simply stating the issues as I see them and that motivated the use of queries in the original system.<br>
<br>
If you were pushing a single attribute with a generic entitlement to access a library journal, that's a clear argument for push. It's just pointless to worry about confidentiality there. It depends on the data and depends on what you care about.<br>
<br>
> Where do I tell the IdP to use the attribute query? It's in the metadata:<br>
<br>
You can't tell them. If an SP (such as Shibboleth) supports queries as part of SSO, it happens when they receive no attributes during SSO and can find a query endpoint in the metadata to contact to try and get them. That was all automatic.<br>
<br>
There is no standard for that, and there are plenty of SAML 1.1 SPs that don't support queries and people had no choice but to push attributes to them.<br>
<br>
If you have an IdP today that doesn't push any attributes and supports SAML 1.1, then you're relying on queries already and all you're trying to do is deploy V3 in the same way. So that's fine, and your problem is that you don't have a working back channel
yet on some new system.<br>
<br>
The way you debug that is by running an SP operating in that mode. That's just how it works, you need both ends, otherwise you're flying blind.<br>
<br>
> 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<br>
> any Boolean type operators to enable it:<br>
<br>
If you include a profile bean in a relying-party block, requests that fall into that relying-party defintion are allowed to leverage that profile at a basic level. SAML1.AttributeQuery is the ID of the bean supplied by us that enables SAML 1 queries using default
settings, and all of that is enabled by default for compatibility with how people used to run things.<br>
<br>
It is deeply unlikely that the problem has anything to do with your IdP configuration, the problem is probably with your container, network, back-channel TLS certificate, etc.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br>
</div>
</span></font>
<hr>
<br>
<a href="http://www.cardiffmet.ac.uk/news/Pages/Cardiff-Met-research-recognised-in-Queens-Anniversary-Prizes-for-Higher-and-Further-Education.aspx" target="_blank"><img src="http://campaigns.cardiffmet.ac.uk/queensprize/QueensPrize.jpg" alt="Cardiff Metropolitan University - Queens Anniversary Prizes 2015" width="200" height="251" border="0"></a>
</body>
</html>