shib-cas-authn3 Different service URLs between login and validation when entityIdLocation=embed

[Carlos Fernandez]

So, I found the root cause for this issue.

During login, HttpServletRequest.getRequestUrl() returns
https://cas.sju.edu/idp/Authn/ExtCas?conversation=e1s1, but during
validation it returns
https://cas.sju.edu/idp/Authn/ExtCas?conversation=e1s1&entityId=https://sju.zoom.us
because CAS always redirects to the service URL (with the service ticket in
tow) upon successful login. When Shibcas constructs the service URL it
appends the entity ID in either situation, resulting in the doubled-up
embedded entity ID.

I've successfully tested a simple patch for this, overloading the method
ShibcasAuthServlet.constructServiceUrl() to take a boolean indicating
whether or not a ticket is being validated; if true, it'll return the
string from CommonUtils unmodified.

----&<----
---
/var/tmp/shib-cas-authn3-master/src/main/java/net/unicon/idp/externalauth/ShibcasAuthServlet.java
2017-05-01 18:48:21.000000000 -0400
+++
shib-cas-authn3-master/src/main/java/net/unicon/idp/externalauth/ShibcasAuthServlet.java
2017-08-01 16:33:25.707861000 -0400
@@ -93,7 +93,7 @@
                                    final String authenticationKey, final
boolean force) throws ExternalAuthenticationException, IOException {
         try {
             ticketValidator.setRenew(force);
-            String serviceUrl = constructServiceUrl(request, response);
+            String serviceUrl = constructServiceUrl(request, response,
true);
             logger.debug("validating ticket: {} with service url: {}",
ticket, serviceUrl);

             Assertion assertion = ticketValidator.validate(ticket,
serviceUrl);
@@ -255,6 +255,18 @@
         return serviceUrl;
     }

+    /**
+     * Like the above, but with a flag indicating whether we're validating
a service ticket,
+     * in which case we should not modify the service URL returned by CAS
CommonUtils; this
+     * avoids appending the entity ID twice when entityIdLocation=embed,
since the ID is already
+     * embedded in the string during validation.
+     */
+    private String constructServiceUrl(final HttpServletRequest request,
final HttpServletResponse response, final boolean isValidatingTicket ) {
+        return isValidatingTicket
+            ? CommonUtils.constructServiceUrl(request, response, null,
serverName, serviceParameterName, artifactParameterName, true)
+            : constructServiceUrl(request, response);
+    }
+
     private void loadErrorPage(final HttpServletRequest request, final
HttpServletResponse response) {
         RequestDispatcher requestDispatcher =
request.getRequestDispatcher("/no-conversation-state.jsp");
         try {
----8<----



Best regards,
--
Carlos M. Fernández
Enterprise Systems Manager
*Saint Joseph’s University*
Philadelphia PA 19131
T: +1 610 660 1501

On Mon, Jul 31, 2017 at 3:22 PM, Carlos Fernandez <cfernand at sju.edu> wrote:

> Setup: IdP 3.3.0, shib-cas-authn 3.2.2, CAS 5.0.5, CAS client 3.4.1
>
> When shibcas.entityIdLocation=embed, the service URL sent with the
> validation request differs from the one sent for the login request.
>
> From the logs:
> `org.jasig.cas.client.validation.TicketValidationException: Ticket '
> ST-8997-qwrkgYqHLZqAHEvlf2EZ-cas.sju.edu' does not match supplied
> service. The original service was 'https://cas.sju.edu/idp/
> Authn/ExtCas?conversation=e1s1&entityId=https://sju.zoom.us' and the
> supplied service was 'https://cas.sju.edu/idp/Authn/ExtCas?conversation=
> e1s1&entityId=https%3A%2F%2Fsju.zoom.us&entityId=
> https://sju.zoom.us'.`
> <https://cas.sju.edu/idp/Authn/ExtCas?conversation=e1s1&entityId=https%3A%2F%2Fsju.zoom.us&entityId=https://sju.zoom.us'.>
>
> The validation service URL appears to have the entityID embedded twice,
> which CAS flags as invalid and refuses to validate. This results in our IdP
> returning an AuthnFailed to the SP (we don't have any other authn methods
> in our IdP).
>
> From rifling through the code a bit, it seems that the CAS CommonUtils
> class returns a service URL with the entityID already embedded when the
> browser returns from login with the service ticket, after which ShibCAS
> embeds the entityID again.
>
> Has anyone else run into this issue? I think this might not be an issue
> with older CAS releases -- I know from experience that CAS 3.5 doesn't care
> about the service URL during validation, which we discovered when we
> upgraded to CAS 5.0.5 and one of our applications no longer worked.
>
> Best regards,
> --
> Carlos M. Fernández
> Enterprise Systems Manager
> *Saint Joseph’s University*
> Philadelphia PA 19131
> T: +1 610 660 1501
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170801/c6caf79e/attachment.html>