I've started to make modications into the JA-SIG CAS Client for Java CVS module. So it may be in a state of flux if you try and use it. I'm pulling in my changes and your patches :-). I have already made the change to allow you to do assertion.getProxyTicketFor(...)
There is a reason that the AuthenticationFilter and the ValidationFilter are seperate. There are instances where you'd like to do validation *if* a ticket is on the request, otherwise don't. We've configured a bunch of stuff that way.
-Scott
On 9/19/06, Velpi <[EMAIL PROTECTED]> wrote:
(sorry for the length of this message...)
> 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.
I missed the examples somehow, sorry. Will try those, thanks.
> 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.
Oh, great!
So I can do something like this (trying to check the use case here):
---
Assertion assertion = validate(ticketFromRequest, "thisServer.org");
String userPGT = assertion.getProxyTicketId();
String userPT = cas20ProxyRetriever.getProxyTicketIdFor(userPGT,
"myGreatBackend.org ")
---
In the Yale version it was possible to configure the servlet filter for a webapp
and then do (somewehere with the same context) a static:
---
(get receipt from session and then)
String userPT =
ProxyTicketReceptor.getProxyTicket(receipt.getPgtIou(),"myGreatBackend.org")
---
can that somehow be translated into
---
(get assertion from session and then)
String userPT =
Cas20ProxyRetriever( assertion.getProxyTicketId(),"myGreatBackend.org")
---
Or even better (like you suggest and I highly recommend):
---
String userPT = assertion.getProxyTicket("myGreatBackend.org");
---
I think we need that... What's the loss? Memory?
If you don't need to (are not allowed to!) fetch the PGT into the webapp, then
that sounds safer to me so I'd say: we need it, go for it.
> 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.
Yale has Authentication and Validation combined into one filter, that feels more
safe to me. I'll epxlain why:
---[CasAuthenticationFilter]---
if (CommonUtils.isBlank(ticket) && assertion == null && !wasGatewayed) {
...
}
filterChain.doFilter(request, response);
--
This means that if someone forgets to put the CasValidationFilter filter in the
chain after the CasAuthenticationFilter, then you could pass all authentication
by providing a (fake) ticket. So actually a CasAuthenticationFilter should
always be followed by a CasValidationFilter, am I right? Then why not just
hard-code that and make it safe(r) by design?
I like the idea of a separate CasAuthorizationFilter though. Expecially the idea
that it's possible to configure a "CasAuthorizedDecider".
Maybe it would be more clean to make one big CasFilter that is configured in the
web.xml just once. It does everything it needs for Authentication AND
Authorization by itself (including ticket validation). Then set the
CasAuthorizedDecider by default to a dummy one that lets everything pass through.
Disadvantage to this approach is losing some CPU cycles in most cases because of
the dummy decider, so maybe it's better to just use a configurable flag to
choose whether to enable the authZ methods in the filter.
The use case I want to get this is this:
(conditional Single Sign On)
if request is from a certain machine
* yes:
** check the type of user (student or employee (LDAP lookup now, later CAS3
protocol))
** if eg employee: don't use session and request ticket and &renew every request
*no: normal CAS auth
practically this could be done by:
delegationfilter based on HTTP parameter, both filters use the same assertion
context
* one is the default one
* special one is triggered by parameter value
** special one uses a "decider" about whether to use the assertion if there's
one present, or request a new authentication at the server&renew (based on an
LDAP/CAS3protocol value).
** possibly this special one is configured not to save the assertion
It's the special filter with the decider that doesn't exist yet, I think. I'll
need to build it anyway so if there's lots of interest in it then maybe we can
build it properly and put it with the rest of the filters.
-- Velpi
_______________________________________________
cas-dev mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas-dev
_______________________________________________ cas-dev mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas-dev
