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] > <mailto:[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 [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > > > To unsubscribe, change settings or access archives, > seehttp://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
