SP handlerURL modification not working

Sun Apr 4 16:40:13 UTC 2021

Brent,

 I believe you're making an error trying to redirect the incoming SAML response to something that didn't create the original SAML request.
You are attempting to split the SAML request and response between two different SAML implementations which is almost never going to end well.

It may be helpful to go back to square one and reevaluate how the SAML flow is going to happen. Your choices should include letting the banner SAML implementation handle the authN or let the Shib SP handle the initial authN (including processing the SAML response), which may or may not then proxy/forward subsequent auth data to whatever consuming layer is behind the Shib SP layer.

From: users <users-bounces at shibboleth.net> on behalf of Brent Goebel <Brent.Goebel at du.edu>
Sent: Friday, April 2, 2021 6:07 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Re: SP handlerURL modification not working 

Hi Peter, 

Thanks for the response. 
Ellucian  is saying that the Consumer Assertion URL needs to be https://<hostname>/AppXtender/BdmSamlSso. So on their application they are looking for this URL format.  I already asked if they could modify their application code to take https://<hostname>/Shibboleth.sso/SAML2/POST and they there is no way to edit the expected Assertion URL on the application side. It has to match this AppXtender/BdmSamlSso. Not sure I buy that from them but hence I started looking into it myself. 

> Even by changing the handlerURL prefix that's not going to let you create arbitrary ACS URLs, does it? Even if this setting this worked I'd expect the final ACS URL for the SAML2 HTTP-POST binding to be /AppXtender/SAML2/POST, not /AppXtender/BdmSamlSso (nor /AppXtender).

The plan was to change the handlerURL to /AppXtender. Once the metadata showed up and updated with that handler, I was going to update the protocols.xml like below (tested protocols change separately and it did do this). 

BEFORE:
      <Binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" path="/SAML2/POST" />
AFTER:
      <Binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" path="/BdmSamlSso " />

Then I was expecting that the metadata would update the AssertionConsumerService for POST to the below:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://xtndapw01-vwq.du.edu/AppXtender/BdmSamlSso" index="1"/>

> What exactly does "the metadata does not populate" mean? What exactly is being returned at that URL?

My apologies I didn't provide the error I am seeing. I get a 500 server error: 

500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.

> Are you even talking to the Shib SP at the URL /AppXtender and not to your application?
Could you elaborate on what you mean by talking to the Shib SP at the URL /AppXtender? So far this testing here is just with getting the metadata URL to recognize the new handlerURL. Once I get this working and showing that path and assertion they are wanting, then I will test with the actual application. Right now just stuck on the metadata URL error. 

Thanks Peter!

Brent 

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Peter Schober
Sent: Friday, April 2, 2021 2:57 PM
To: users at shibboleth.net
Subject: [EXTERNAL] Re: SP handlerURL modification not working

[External Email From]: users-bounces at shibboleth.net

* Brent Goebel <Brent.Goebel at du.edu> [2021-04-02 22:12]:
> I am trying to setup SSO with Ellucian Banner Document Management 
> (Application Xtender). I’m using Shibboleth SP (v. 3.1.0.1) with it. 
> Ellician requires the Assertion URL to be in the following format

What code is supposed to process the SAML Response/Assertion, then?
If that's application code then how's the Shib SP involved?
If it's the Shib SP why should the application care at what URL the Shib SP processes the SAML? It should only care about how the Shib SP forwards that information to the application (headers, etc.).

> handlerURL="/AppXtender">

Even by changing the handlerURL prefix that's not going to let you create arbitrary ACS URLs, does it? Even if this setting this worked I'd expect the final ACS URL for the SAML2 HTTP-POST binding to be /AppXtender/SAML2/POST, not /AppXtender/BdmSamlSso (nor /AppXtender).

> I go to the metadata URL (https://<hostname>/AppXtender/Metadata)
> and the metadata does not populate.

What exactly does "the metadata does not populate" mean? What exactly is being returned at that URL?
Are you even talking to the Shib SP at the URL /AppXtender and not to your application?

-peter
--
For Consortium Member technical support, see https://urldefense.com/v3/__https://wiki.shibboleth.net/confluence/x/coFAAg__;!!NCZxaNi9jForCP_SxBKJCA!CnYuODXl4IV3Bo-x9f1LtlFM13RUqHtYdlM8f1y98AX_RcfSDurlu-cbT7cknFULrQ$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net