0
votes

I'm trying to configure Shibboleth SP with WS02 Identity Server IDP.

Shibboleth SP version 2.5.3 is installed and configured on Linux Redhat. Apache HTTPD 2.4.6 is installed and configured on the same server. Both services are running.

WSO2 Identity Server version 5.0.0 is installed on Linux on a separate server to the Shibboleth SP/ Apache HTTPD server.

Both servers can communicate with each other.

I have broadly followed this article http://www.yenlo.com/en/creating-single-sign-on-between-liferay-and-wso2-identity-server/ to set-up the resident IDP and to register the Shibboleth Service Provider.

I created the IDP Metadata and have it stored on the SP server.So far so good.

I have created a simple test page and secured it by putting the following into my httpd.conf:

<Location /secure>
  AuthType shibboleth
  ShibRequestSetting requireSession 1
  require shib-session
</Location>

Testing the service it works to a point, from the browser I enter the secure location ../secure/secure.html and then it is redirected to the WS02 IDP login screen. I enter a username and password and the WSO2 IDP authenticates the user but can't redirect back to the SP for some reason.

The following error is reported in the wso2carbon.log:

TID: [0] [IS] [2015-03-25 17:53:28,041] ERROR {org.wso2.carbon.identity.sso.saml.processors.SPInitSSOAuthnRequestProcessor} - ALERT: Invalid Assertion Consumer URL value 'http://xx.xx.xx.xx/Shibboleth.sso/SAML2/POST' in the AuthnRequest message from the issuer 'devqa.labs.xxxxxxx.net'. Possibly an attempt for a spoofing attack {org.wso2.carbon.identity.sso.saml.processors.SPInitSSOAuthnRequestProcessor}

The metadata for the SP indicates that "//xx.xx.xx.xx/Shibboleth.sso/SAML2/POST" is a valid Assertion URL.

There aren't many posts on the internet with such an error so I would be obliged if somebody could point me in the right direction.

Regards Stephen

1

1 Answers

1
votes

the exception message really indicates that IS considers requested and configured ACS URL different. Please provide (or check) the ACS sent in the SAML AuthnRequest and ACS configured with your service provider's SAML configuration. (must be the same including case sensitive expressions)

Best regards Gabriel