I was wondering if there is better way for me to approach this problem. Is there a possible idp configuration that I have missed.
idp-process log Excerpt
07:40:27.092 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:85] - shibboleth.HandlerManage
r: Looking up profile handler for request path: /SAML2/POST/SSO
07:40:27.092 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.IdPProfileHandlerManager:93] - shibboleth.HandlerManager: Located profile handler of the following type for the request path: edu.internet2.middleware.shibboleth.idp.profile.saml2.
07:40:27.092 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:144] - Incoming request does not contain a login context, processing as first leg of request
07:40:27.093 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:288] - Decoding message with decoder binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
07:40:27.093 - DEBUG [org.opensaml.ws.message.decoder.BaseMessageDecoder:72] - Beginning to decode message from inbound trans
port of type: org.opensaml.ws.transport.http.HttpServletRequestAdapter
07:40:27.093 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:317] - Error decoding authentication request message
org.opensaml.ws.message.decoder.MessageDecodingException: This message deocoder only supports the HTTP POST method
> I was trying to get from a (incommon) wayf page to get to a SP. However I
> am getting an error from the idp. I have included an excerpt from the
The InCommon WAYF (as with any legacy WAYF) can't handle any SAML 2
behavior, so whatever you're doing doesn't make sense. Probably your
metadata for the IdP is pointing the WAYF to send a legacy request to a SAML
2 endpoint, which is not possible to do.
Our institution just joined InCommon and I just happened on their WAYF page and I got that error. So I whipped up a quick WAFY (our own custom html page). Configured our IDP and SP and I get the same error. Furthermore I was reading the documentation here https://spaces.internet2.edu/display/SHIB2/DSInstall
I am not sure if I am going about it the right way. Are there specific procedures that have to be followed to make a custom WAYF page. We are not installing DS at this point. I am looking more for guidance or any where you can point me.
[hidden email] wrote on 2009-05-12:
> Our institution just joined InCommon and I just happened on their WAYF
> page and I got that error.
And my point is that for that to happen, you had to have registered the
wrong locations with InCommon for your IdP. You can't tell it to send
requests to a SAML 2 endpoint, because InCommon is still SAML 1.1 only
right now, partly because the WAYF is still the older code.
> I am not sure if I am going about it the right way. Are there specific
> procedures that have to be followed to make a custom WAYF page. We are
> installing DS at this point. I am looking more for guidance or any where
> you can point me.
The IdP doesn't support starting at the IdP end for SAML 2. This is covered
on the list in many threads. To make the IdP do anything, you have to send
it an AuthnRequest, either a SAML 2 message, or the legacy SAML 1.1
extension, which is a simple redirect protocol. The WAYF does the latter, so
is specific to SAML 1.1 responses, and requires that the endpoint in the
metadata it loads be the legacy Shibboleth SSO endpoint at the IdP.