The SAML message issuer https://idp.bppls.com/openathens does not match the expected issuer https://idp.eduserv.org.uk/openathens."

We are currently testing our release for the use of ComponentSpace when we are using federations. Federations are a way for a group of schools to get together with a group of service providers and have the metadata exchanged done through the federation, instead of individually.

We are currently testing with the OpenAthens federation and getting the exception in the title. The way OpenAthens works is that we do SP-Init to OpenAthens, the user enters the credentials, and then it issues a SAML from the correct IdP.

This is expected and correct functionality for these type of federations. If we use the library that they supply (which only works with OpenAthens), everything works.

Is there any way for us to turn off this checking if IdP’s that are from specific federations?

We use the issuer field in the SAML response to lookup the corresponding SAML configuration, in this case the .
Normally you would have a separate entry per partner IdP.
To assist further, could you please email support@componentspace.com mentioning this forum post?
Please enable SAML trace and send the generated log file as an email attachment.
http://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Also include your saml.config file as an email attachment and any relevant documentation including the SAML metadata for OpenAthens.
Thanks.



[quote]
ComponentSpace - Tuesday, April 12, 2016
We use the issuer field in the SAML response to lookup the corresponding SAML configuration, in this case the .
Normally you would have a separate entry per partner IdP.
To assist further, could you please email support@componentspace.com mentioning this forum post?
Please enable SAML trace and send the generated log file as an email attachment.
http://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Also include your saml.config file as an email attachment and any relevant documentation including the SAML metadata for OpenAthens.
Thanks.



[/quote]

At some point we well get to that, but our release is this weekend. I was able to work around this issue by implementing the ISSOSessionStore interface - and not store anything.

I understand that this could cause security risks about SAML coming in, but the system I work in is just the authentication piece for over 150 applications. We can't track session anyway.

Ok, fair enough.