Actually, from the client's perspective, renew=true is *completely* dependent on whether a session exists or not. CAS clients manage their own session, so if they've established an authenticated session, as long as they consider it valid, they should not go back to the server to authenticate again.
renew=true says that when a client requests a new service ticket (from an expired or non-existent session), the CAS server should always prompt for authentication regardless of whether a single sign on session exists or not. Making sure a session does not exist is the *only* way to ensure that every request to your CAS client will result in a prompt to the CAS server for forced authentication. As you've noted, useSession=false and redirectAfterValidation=true are not compatible. If you'd like to post your existing configuration, we can see if we can spot a problem. Cheers, Scott On Tue, Jul 24, 2012 at 5:06 AM, yanis aumont <[email protected]>wrote: > Thanks for then answers ! > > The only subtlety that I can perhaps point out is that the setting the > 'renew' parameter for the filter applies to how the "CAS server" should > behave when it receives a /login request from the client. Presently, I > don’t think there exists a renew-specific parameter for the client itself > to enforce authN. > > This is exactly how I understood renew worked while studying the code. > This is why I find this description - > http://www.jasig.org/cas/client-integration/renew - puzzling. > > > Le 24/07/2012 02:53, Scott Battaglia a écrit : > > The user is only prompted if an existing local session does not exist. If > you want to force the authentication each time they come to the IdP then > either set the session timeout very low (i.e. 5 minutes and use renew=true) > or don't use the session storage at all (meaning each request would send an > authentication request to the CAS server). > > Setting the session timeout to a short duration would not exactly answer > my needs (forced authentication should not depend on time-based criteria). > > Using the useSession parameter feels much closer to meet my expectations. > However, I have issues dealing with it. > These issues were already mentioned in some other topics (by the same > user) but have never really been addressed : > http://jasig.275507.n4.nabble.com/Several-Questions-td2275194.html#a2275206 > http://jasig.275507.n4.nabble.com/useSession-false-problem-td2282618.html > > The first post of the second topic ( > http://jasig.275507.n4.nabble.com/useSession-false-problem-td2282618.html) > describes exactly what I face when trying to use useSessions=false. > > The CAS client first redirects to the server, the user authenticates, then > the client has to validate the ticket. But there is no assertion nor ticket > in the request (because of useSessions=false), so the test in > AuthenticationFilter I referred to in my first post fails, and the user is > redirected to the server for authentication. Endless loop. When used in > conjunction with "renew=true", the only difference is that the user is > prompted for credentials each time he gets to the CAS server, but this has > no effect on the loop. > > The mere existence of the useSession parameter strengthens my idea that > destroying the assertion (or even the session) before accessing to the CAS > client filters when forced reauth is required is not an issue. > > > On Mon, Jul 23, 2012 at 4:55 AM, yanis aumont <[email protected]>wrote: > >> Hi, >> >> I am currently working on developing a custom login handler for Shibboleth >> IdP. The goal is to allow applications protected by a CASified IdP to >> use forced authentication (which is currently not possible with the >> RemoteUserLoginHandler). >> According to CAS v2 protocol, a simple use of the parameter renew would do >> the trick. (http://www.jasig.org/cas/client-integration/renew vs forceAuthn, >> page 49 in >> http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf). >> >> However, mapping to the AuthenticationFilter and ValidationFilter >> (Cas20ProxyReceivingTicketValidationFilter) >> with the parameter "renew" set to "true" is not enough to enforce >> re-authentication. The user is not prompted for his credentials. >> >> Code-wise, this is due to the existence of an Assertion (client side) as >> an attribute of the session of the request transmitted to CAS client >> filters. More precisely, the AuthenticationFilter bypasses the >> redirection to CAS server if this assertion exists : >> >> public final void doFilter(final ServletRequest servletRequest, final >> ServletResponse servletResponse, final FilterChain filterChain) throws >> IOException, ServletException { >> ... >> final HttpServletRequest request = (HttpServletRequest) >> servletRequest; >> >> final HttpSession session = request.getSession(false); >> final Assertion assertion = session != null ? (Assertion) >> session.getAttribute(CONST_CAS_ASSERTION) >> : null; >> if (assertion != null) { >> filterChain.doFilter(request, response); >> return; >> } >> ... >> >> final String urlToRedirectTo = >> CommonUtils.constructRedirectUrl(this.casServerLoginUrl, >> getServiceParameterName(), modifiedServiceUrl, this.renew, this.gateway); >> response.sendRedirect(urlToRedirectTo); >> } >> >> I have decided to remove this attribute from the session transmitted to the >> filters when forcedAuthentication is required (and this works well). >> >> Why do I have to do so ? Do I miss something, like configuration subtleties >> ? >> >> And what do you think about my solution ? Does this cause security issues >> / break the protocol / ... ? I have studied the code and I don't think >> it does, but I would like to hear your opinion. >> >> Thank you for your time, >> Yanis. >> >> PS : I had posted this on the forum a few days ago but I hadn't >> completed my registration (subscription doesn't work well) and I don't >> think it was sent to the mailing list. It it was, sorry for the double mail. >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> > -- > You are currently subscribed to [email protected] as: > [email protected] > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
