CAS assertions

[Andrew R Feller]

Hey Scott,

 

Thanks for the reply!

 

I apologize as I realize I mistyped when I wrote the first question.  I
meant that developers could only get a principal/username by getting it
directly from the session or by using the HttpServletRequestWrapper
filter whereas in the JA-SIG CAS 3.1 client, there is now a third
option: the AssertionHolder.  I never meant that the Assertion was never
available in the session.

 

Thanks once again!,

Andy

 

Andrew R Feller, Analyst

University Information Systems

200 Fred Frey Building

Louisiana State University <http://www.lsu.edu/> 

Baton Rouge, LA, 70803

(225) 578-3737 (Office)

(225) 578-6400 (Fax)

 

________________________________

From: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu]
On Behalf Of Scott Battaglia
Sent: Monday, June 23, 2008 1:19 PM
To: Yale CAS mailing list
Subject: Re: CAS assertions

 

On Mon, Jun 23, 2008 at 11:37 AM, Andrew R Feller <afelle1 at lsu.edu>
wrote:

Two questions:

 

Question: What is the recommended way to access the CAS assertion
identifying authenticated users?  AssertionThreadLocal filter?

 

I ask because I noticed a number of internal changes in the recent 3.1
client while upgrading and realize it breaks some of our legacy code.
In the older 3.0 client, the only way to access the principal was to
grab it from the session yourself.

As far as I recall the Assertion was always available in the session and
ultimately still is.  If you merely need to access the Remote User name
or the Principal you can enable the Wrapper for the HttpServletRequest
which overrides those two methods. 

	 

	Question: How likely will the AssertionHolder class be kept
unchanged in future versions?  Is there any reason why an interface
wasn't created for it?

Its a concrete class because it has static methods so you'd be calling
the implementation anyway.  ;-). There's no reason to see that it would
change since all it does is give you the Assertion for the current
Thread.  Even if we made additional enhancements (a la Spring Security)
the static methods wouldn't change.

	 

	 I noticed the org.jasig.cas.client.validation.Assertion
interface and org.jasig.cas.client.validation.AssertionImpl, so I assume
that the interface will be consistent in the next client version.

Yes it should.  3.0 has a dependency on the CAS Server code, purely for
convenience purposes, so we removed that dependency so that the client
can evolve on its own.  Though we continue to recommend where possible
that you only rely on the standard Servlet Security points so that if
you wanted to you could change clients or security libraries (i.e. using
Spring Security instead of the CAS client directly).

 

-Scott 

	 

	Thanks for the help!

	 

	Andrew R Feller, Analyst

	University Information Systems

	200 Fred Frey Building

	Louisiana State University <http://www.lsu.edu/> 

	Baton Rouge, LA, 70803

	(225) 578-3737 (Office)

	(225) 578-6400 (Fax)

	 

	
	_______________________________________________
	Yale CAS mailing list
	cas at tp.its.yale.edu
	http://tp.its.yale.edu/mailman/listinfo/cas

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080624/5950f9e3/attachment.html