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 ?
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+Integration
except 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
