CAS in IdP v3

Marvin Addison marvin.addison at gmail.com
Thu Feb 4 11:32:52 EST 2016


On Thu, Feb 4, 2016 at 10:21 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> This is a Jetty specific bug, I take it?


No. Jetty actually provides a flag to disable the servlet-specified
behavior.

The root problem is that many Spring components that compute redirects
(RedirectView, externalRedirect SpEL) call
HttpServletResponse#encodeRedirectUrl [1] unconditionally. Here's where
it's biting us in the CAS login flow:

    <end-state id="RedirectToService"
view="externalRedirect:#{flowScope.redirectUrl}">
        <on-entry>
            <evaluate expression="PopulateAuditContext" />
            <evaluate expression="WriteAuditLog" />
        </on-entry>
    </end-state>

I initially argued that they should try to infer whether it's a "remote"
system and suppress that behavior, but I warmed up to "it's hard to
determine" and now I think they need additional flags to allow the
programmer to decide what to do. If they added those controls, we could
leverage them in the CAS flow. I suppose we could hack the view components
to suppress that behavior, but I think our time is better spent on the Jira
issue I mentioned. Until then, toggling the Jetty flag I mentioned is a
reasonable fix.


> We should start charging container projects to *not* choose them as our
> baseline.
>

What I can say about Jetty is that they are reasonably receptive to
thoughtful feature requests. That's worth something IMO.

M <users-unsubscribe at shibboleth.net>

[1]
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#encodeRedirectURL(java.lang.String
)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160204/cd106522/attachment.html>


More information about the users mailing list