On Wed, Jul 25, 2012 at 10:04 AM, yanis aumont <[email protected]>wrote:
> Le 25/07/2012 05:25, Scott Battaglia a écrit :
>
> 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.
>
> According to my tests, removing the attribute named CONST_CAS_ASSERTION
> ("_const_cas_assertion_") from the session is enough to get the CAS client
> to go back to the server (since AuthenticationFilter tests for the
> existence of this attribute and not the existence of the session). But I
> guess it pretty much amounts to the same as invalidating the session.
> What exactly happens when a destroyed session is renewed ? As I see it, a
> new ST is created by checking the client's TGT against the server's (and
> reauthenticating the user if renew=true). How far am I from the truth ?
>
Yes, invalidating the session, removing that attribute, or using the
request-only should result in the same behavior on a return to that client.
Whenever a service requests a new service ticket, the CAS server will vend
the service one, assuming there is a valid TGT. If a service has set
renew=true, it will first re-confirm the credentials (and destroy the old
ticket if the principal names do not match) and then issue the service
ticket.
Can you open a bug report for your session-less issue? Its possible we
introduced a bug. I can investigate and get it fixed for CAS Client 3.3 if
that is the case.
Thanks
Scott
> On a sidenote, considering the parameter useSession :
> The thing is, the configuration file web.xml where the filters are
> described is defined for the IdP. I mean that all the SPs that could use
> this IdP rely on this configuration. Some SPs will require forced
> authentication while others won't. We could still declare two
> ValidationFilters, one with renew=true and useSession=false, the other with
> the opposite, and map to the one we need to use based on the need to use
> forced authn. But I am not sure how this setting would behave, since some
> CAS client sessions would still be created while a filter states it doesn't
> use them.
> I find it more secure to invalidate the session before getting to the
> AuthenticationFilter when forced authn is required.
> (Plus I still cannot get the remote user attribute when using
> useSession=false and redirectAfterValidation=false, I have described this
> issue at the end of this mail. This is secondary for me since invalidating
> the session as explained above works well for me and I don't think I should
> use these parameters, but it could be useful to understand why it fails.).
>
>
> 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.
>
> I thought renew should have always forced the client to go back to the
> server. Things are much clearer now. Thanks.
>
>
> 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
>
>
> Here is what happens when I set useSession to false and
> redirectAfterValidation to false (my configuration is the exact same as
> this one
> https://wiki.jasig.org/display/CASUM/Shibboleth-CAS+Integrationexcept for
> these two parameters).
>
> ----
> 10:34:24.326 - DEBUG
> [org.jasig.cas.client.validation.Cas20ServiceTicketValidator:206] -
> Retrieving response from server.
> 10:34:24.350 - DEBUG
> [org.jasig.cas.client.validation.Cas20ServiceTicketValidator:214] - Server
> response: <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
> <cas:authenticationSuccess>
> <cas:user>etudiant1</cas:user>
> </cas:authenticationSuccess>
> </cas:serviceResponse>
> 10:34:24.359 - INFO
> [org.jasig.cas.client.proxy.ProxyGrantingTicketStorageImpl:88] - No Proxy
> Ticket found for [].
> 10:34:24.361 - DEBUG
> [org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter:172]
> - *Successfully authenticated user: etudiant1*
> 10:34:24.363 - TRACE
> [edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:109] -
> Attempting to retrieve IdP session cookie.
> 10:34:24.363 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.provider.RemoteUserAuthServlet:77]
> - *No remote user information was present in the request*
> ----
>
> The normal process (with useSession=true, redirectAfterValidation=true and
> the same configuration as above) gives :
>
> ----
> 11:11:02.888 - DEBUG
> [org.jasig.cas.client.validation.Cas20ServiceTicketValidator:206] -
> Retrieving response from server.
> 11:11:02.911 - DEBUG
> [org.jasig.cas.client.validation.Cas20ServiceTicketValidator:214] - Server
> response: <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
> <cas:authenticationSuccess>
> <cas:user>etudiant1</cas:user>
> </cas:authenticationSuccess>
> </cas:serviceResponse>
> 11:11:02.921 - INFO
> [org.jasig.cas.client.proxy.ProxyGrantingTicketStorageImpl:88] - No Proxy
> Ticket found for [].
> 11:11:02.923 - DEBUG
> [org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter:172]
> - *Successfully authenticated user: etudiant1*
> 11:11:02.923 - DEBUG
> [org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter:183]
> - Redirecting after successful ticket validation.
> 11:11:02.923 - DEBUG [org.jasig.cas.client.util.CommonUtils:247] -
> serviceUrl generated: https://my-idp-host/idp/Authn/RemoteUser
> 11:11:02.941 - TRACE
> [edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:109] -
> Attempting to retrieve IdP session cookie.
> 11:11:02.941 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.provider.RemoteUserAuthServlet:73]
> - *Remote user identified as etudiant1 returning control back to
> authentication engine*
> ----
>
> My thoughts about this :
> The IdP tries to get the remote user by calling
> httpRequest.getRemoteUser() after the CAS client filterchain.
> When reading the doc for the HttpRequestWrapperFilter, it actually makes
> sense that this would return null when we don't store sessions :
> * Wraps the HttpServletRequest in a wrapper class that delegates
> * <code>request.getRemoteUser</code> to the underlying Assertion
> object
> * stored in the user session.
> No session means no assertion which means we can't delegate
> getRemoteUser() to anything. That's how I see it.
> However I seem to be the only one getting this issue, apart perhaps from :
> http://jasig.275507.n4.nabble.com/per-request-validation-td263223.html .
> Am I experiencing the same issue as he was ?
>
> --
> 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
