Shibboleth IdP Issuer

[Cantor, Scott]

On 2/18/13 11:37 AM, "Rawlinson, Philip (rawlinpa)"
<RAWLINPA at UCMAIL.UC.EDU> wrote:

>We are looking for reasons why we are not sending the Issuer and how to
>make our IdP send the Issuer to this SP.

I am not aware of any possible behavior in Shibboleth that could result in
Issuer being omitted, but I think what's really happening is you're
returning no assertions at all from an attribute query.

> 
>A few other things to note is that Shibboleth is using the SAML 1.0
>browser post binding below.

No, it's SAML 1.1.

> We use SAML2 with all other non-ohiolink SPs so I am not sure what is
>causing that to happen.

Your metadata in InCommon has to be limited to SAML 1.1 or they have to be
hardwiring the request to your IdP to be SAML 1.1 using a legacy request.
I don't know how they do discovery, but a custom discovery solution may
often support only SAML 1.1 or have to be manually touched to deal with a
version switch. That's OhioLink's issue, the SP decides what to send, and
if your metadata includes both, they have made the choice to use SAML 1.1.

>There is an error in the IdP logs:
>10:04:19.277 - ERROR
>[org.opensaml.ws.security.provider.MandatoryAuthenticatedMessageRule:37]
>- Inbound message issuer was not authenticated.
>10:04:19.278 - WARN
>[edu.internet2.middleware.shibboleth.idp.profile.saml1.AttributeQueryProfi
>leHandler:180] - Message did not meet security requirements
>org.opensaml.ws.security.SecurityPolicyException: Inbound message issuer
>was not authenticated.

Well, that's for attribute queries, and yes, it's failing. Their
certificate is wrong or more likely your IdP environment is misconfigured
and not handling client TLS.

> 
>One of the certificates in the InCommon Metadata file for
>https://proxy.ohiolink.edu/shibboleth had expired at the end of January,
>but that has since been updated in the file and we have the latest
>InCommon Metadata file.

The expiration of the cert is irrelevant, unless you're using Apache as an
SSL endpoint and it's rejecting an expired cert.

> 
>Scott- I know Joseph from OARnet messaged you about part of this last
>week. He also mentioned that OSU uses SAML1 in their communication with
>OhioLINK.

Yes. So I know their metadata is fine, and their attribute queries are
handled fine here. That points to your IdP. If you want to use SAML 2 and
not fix the IdP's TLS behavior, then you'd have to get them to fix
whatever it is that's causing it to use SAML 1.1 instead. They use 1.1
with us because that's all our InCommon metadata advertises.

-- Scott