[cas-dev] JA-SIG java client

[Scott Battaglia]

Velpi,

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 <velpi at industria.be> 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
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20061003/abdbeb2e/attachment-0001.html