Hello Scott,

Just wanted to confirm that using the Saml11AuthenticationFilter does indeed 
solve the problem and make sense of how the argumentExtractors are meant to 
work.

Thanks for the help,
-Tom


On 10/26/10 10:14 AM, "Talbott, Thomas" <[email protected]> 
wrote:

I am not.  I do not see that referenced in the wiki page 
https://wiki.jasig.org/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml.
  I only see a reference to the validation filter.

I now see Saml11AuthenticationFilter and will give that a try.

Thanks,
- Tom


On 10/26/10 9:42 AM, "Scott Battaglia" <[email protected]> wrote:

On the client, are you using the SamlAuthenticationFilter?  It should trigger 
the appropriate response on the server side.


On Tue, Oct 26, 2010 at 12:38 PM, Talbott, Thomas 
<[email protected]> wrote:
Sorry if this is a repeat, but it doesn’t look like it went out yesterday.

In short, could somebody specify what parameters I should be seeing in the 
initial request, the redirect back to the client, and the validation request 
when using the new SAML 1.1 compliance.  The new client code’s 
Saml11TicketValidationFilter appears to require the redirect back to the client 
to have SAMLart as a parameter, but I don’t see any way for the server to set 
this.  Please see below for details.

Thanks,
-Tom


On 10/25/10 6:24 PM, "Talbott, Thomas" <[email protected] 
<http://[email protected]> > wrote:

Hello Scott,

I am moving from 3.1.10 to 3.1.12 as well as moving our CAS implementation to 
3.4.3.  I am unable to get the new SAML 1.1 support to work correctly.  The new 
Saml11TicketValidationFilter requires that the artifactParameterName that 
contains the ticket be “SAMLart”, but the server is always sending it as 
“ticket”.

Based on the login-webflow.xml, I see:

    <action-state id="redirect">
        <evaluate 
expression="flowScope.service.getResponse(requestScope.serviceTicketId)" 
result-type="org.jasig.cas.authentication.principal.Response" 
result="requestScope.response" />
        <transition to="postRedirectDecision" />
    </action-state>

This suggest that the service that is discovered using the argumentExtractors 
is supposed to be generating the response.  Yet, I do not see how the 
SamlArgumentExtractor would ever get invoked based on the code in 
SimpleWebApplicationServiceImpl.createServiceFrom() which always gets called 
first and seems to always return that service type.

Am I not configuring the client correctly to send the correct arguments so that 
the server knows it wants a SAML response?  I don’t see anything in the 
documentation requiring this.  I’m following the wiki page:

https://wiki.jasig.org/display/CASC/Configuring+the+JA-SIG+CAS+Client+for+Java+in+the+web.xml

Thanks for your help,

-Tom

On 10/13/10 7:44 PM, "Scott Battaglia" <[email protected] 
<http://[email protected]> > wrote:

Dear CAS Community:

We're pleased to announce the release of the Jasig CAS Client for Java 3.1.12.



This version offers a number of new features:

* Assertion Caching Facility for JAAS Authentication

* Tomcat Integration support (big thanks to Marvin for really fleshing this out 
beyond the initial implementation)

* Add support properly configuring SAML1.1 support via SamlAuthenticationFilter



A number of improvements:

* Improve error message due to clock drift in SAML validation

* Improved error reporting when receiving proxy tickets

* Fixed breaking exception chain in JAAS support



A bug:

* Error in encoding of redirects for validation filters



You can download the archives from:

http://downloads.jasig.org/cas-clients/



or use the Maven repository:

* groupId: org.jasig.cas.client



Thanks

Scott

-- 
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

Reply via email to