-Scott
(comments are inline)
On 9/18/06, Velpi <[EMAIL PROTECTED]> wrote:
<snip />
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.
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.
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.
Uh oh :-) LOL
<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
_______________________________________________ cas-dev mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas-dev
