> Hmm, I didn't expect the IdP to return HTML in the SAML.
Me neither. I think that is just wrong, but from what you say it is not
the actual cause of the problem here.
> But I expect
> this is just a side-effect of the exception we are getting on the IdP,
> which is then returning the generic error page instead of attributes. If
> you can look further into your decoded response you will probably see
> error text.
Yup...
Sorry, but there's been an error while trying to authenticate you.
Please contact [log in to unmask]
or the IT service desk
> Since the test page at
> https://target.iay.org.uk/secure/printenv.cgi can request attributes
> from there okay I'm pretty sure that URL does work sometimes, just not
> most of the time.
I thought this might be because that is a 2.0 SP that was preferentially
using your other (2.0) bindings and therefore seeing different things
than older (1.3) SPs, but it turns out that one is a 1.3 SP too,
so it should be going through the same path as the others.
You wrote previously:
> It now gets to the
> Shibboleth part and fails there, as my idp-process.log shows errors.
Can you tell me what is being reported please, e.g., for that access
at 08.31.
> The only thing of interest
> was that the target.iay.org.uk test SP does successfully get attributes,
> and it's the only one I could see with a certificate embedded in the
> metadata.
That's possible but neither Ian nor I can think why it might affect you.
The IdP logs may shed some light. Ian points out that one other thing
that is different about that SP from most others is that its attribute
requester certificate is one of our old SDSS project CA certificates,
and one of the properties of that CA is that it does not have/require
an intermediate CA certificate, so if the errors reported by the IdP
are related to missing or unavailable intermediates that might explain
why it was behaving differently.
Finally, I'm happy to take this discussion off-list if the minutiae are
likely to be boring the other participants!
Cheers,
Fiona.
|
