[cas-dev] JA-SIG java client

[Scott Battaglia]

I'm heading to lunch soon so I'll give the explanation on how to use it
after, but I did want to answer some of your questions first.  Though if you
do need a quickstart on how to configure it, the web.xml and the Spring
context files should be a good start.

-Scott

(comments are inline)

On 9/18/06, Velpi <velpi at industria.be> wrote:
<snip />

>
>
> ####################################
> -----------------
> NOTE: you can only retrieve a ProxyGrantingTicket once with this method.
>       * Its removed after retrieval.
> -----------------
> That's not so nice...
> Can we add a function/flag that says don't remove it from the cache? PGT'
> are
> meant to be reusable for a certain amount of time. (also see next remark)


There's nothing preventing you from re-using a PGT for a period of time.
You can only retrieve it via PGTIOU for a certain period of time.  In fact,
the goal is that you should never have to know the PGTIOU, as you don't need
to.  If you look at the Assertion interface it includes a method called
getProxyTicketId.  Whenever you need the PGT ID to obtain a Proxy Ticket,
you should get the Id from that.    Everything you need about the User is in
the Assertion.

####################################
> We currently use the java client as a java library as described at the
> website,
> will that also be possible with this new code?
> (you hand a PGTIOU to the library and it gets a PT for you by looking up
> the PGT
> from the cache and fetching a new PT; you never see the PGT in the app's
> code)


Yes, the code can be used directly as a library.  We have a ProxyRetriever
interface and implementation that takes a target service and the PGT ID.  As
mentioned before, the Proxy Granting Ticket Id is available from the
Assesertion.  I'm even looking at exposing a method directly on the
Assertion to get a Proxy Ticket.  I'd be interested in your thoughts on
that.

####################################
> It seems there's a lot of filters that you need to configure in the right
> order
> to make it work properly. While this is a great to do it when you know
> very well
> what you're doing, I think it might prevent easy adoption. Maybe it would
> be a
> good idea to create another filter that just takes a few parameters and
> then
> configures all the commonly used filters itself? It's convenient and it
> will
> make it easier for people to switch from the YALE to the JA-SIG filter...


 I don't believe the number of filters is significantly more or less than
the Yale filters. We have one for Authentication and Validation (which Yale
has I believe), and a simple one for Authorization (which most people will
never use).  The only addition is the one to wrap the request to use
getRemoteUser (which is optional).  We include common example web.xml and
applicationContext.xml files that should be sufficient for the majority of
the installations.

[more remarks later :)]


Uh oh :-) LOL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20060918/e3e960d5/attachment.html