[cas-dev] renew flag can be bypassed
Scott Battaglia
scott.battaglia at gmail.com
Wed Mar 7 08:19:19 EST 2007
I'm not a huge fan of the proxy pattern either but in this case it makes the
most sense. It doesn't make sense to re-add a ticket as the
CentralAuthenticationService isn't aware of the internal state of the ticket
to know that "hey if I do this I need to make sure I re-save the registry."
The registry however, knows what it needs to do in order to maintain the
consistent state of the registry. I'm always open to a better solution
though :-)
-Scott
On 3/2/07, March, Andres <amarch at soe.sony.com> wrote:
>
> Ah, the old proxy pattern. Thought about doing that but at first blush
> didn't like it. I'm on 3.0.5 currently so didn't see your distributed
> registry until I just googled it. If that's the design, then so be it.
> Sorry it took this long for me to get to the heart of the issue. Look for
> an update to CAS-474 and feel free to close CAS-475. Thanks again Scott.
>
>
>
> - Andres
> ------------------------------
>
> *From:* cas-dev-bounces at tp.its.yale.edu [mailto:
> cas-dev-bounces at tp.its.yale.edu] *On Behalf Of *Scott Battaglia
> *Sent:* Thursday, March 01, 2007 6:34 PM
> *To:* Mailing list for CAS developers
> *Subject:* Re: [cas-dev] renew flag can be bypassed
>
>
>
> Its up to registry implementations to be aware of whether they need to do
> something to keep tickets up to date. If you look at the
> AbstractDistributedTicketRegistry included in the distribution it proxies
> any tickets retrieved from the data store and knows what if anything needs
> to be done to keep the data store up to date.
>
> -Scott
>
> On 3/1/07, *March, Andres* <amarch at soe.sony.com> wrote:
>
> http://www.ja-sig.org/issues/browse/CAS-475 entered. I see this as a
> critical issue for a major deployment that is supposed to take place at the
> end of this month. I can provide a patch if the issue is accepted.
>
>
>
> - Andres
> ------------------------------
>
> *From:* cas-dev-bounces at tp.its.yale.edu [mailto:
> cas-dev-bounces at tp.its.yale.edu] *On Behalf Of *March, Andres
> *Sent:* Thursday, March 01, 2007 5:05 PM
>
>
> *To:* Mailing list for CAS developers
> *Subject:* Re: [cas-dev] renew flag can be bypassed
>
>
>
> Also not sure why credentialsProvided is not the only thing that
> determines if this is a new login:
>
>
>
> *final* ServiceTicket serviceTicket = *new* ServiceTicketImpl(id, *this* ,
>
> service, *this*.getCountOfUses() == 0 || credentialsProvided,
>
> expirationPolicy);
>
>
>
> I assume there is some reason that I'm not aware of but if countOfUses was
> not considered then I also wouldn't have this issue because I verified
> credentialsProvided==fales.
>
>
>
> - Andres
> ------------------------------
>
> *From:* cas-dev-bounces at tp.its.yale.edu [mailto:
> cas-dev-bounces at tp.its.yale.edu] *On Behalf Of *March, Andres
> *Sent:* Thursday, March 01, 2007 4:58 PM
> *To:* Mailing list for CAS developers
> *Subject:* Re: [cas-dev] renew flag can be bypassed
>
>
>
> Sorry for the run around and the noise but it appears my elegant new
> ticket registry (backed by BerkeleyDB - http://www.ja-sig.org/issues/browse/CAS-474
> ) doesn't see the ticket updates because the TGT is never re-added to the
> registry. It seems the current implementation does not account for
> serialization of tickets and relies on mutable ticket state. So this is
> what happens:
>
>
>
> - login is hit with a TGC
>
> - the TGT is fetched from the registry
>
> - an ST is issued using the TGT
>
> - the TGT increments its usageCount (but this only happens in memory)
>
> - the ST is added to the registry
>
>
>
> So I think the TGT needs to be re-added to the registry, so that the next
> time it's fetched the usageCount is accurate. I believe that the ST need to
> also be re-aded to the registry at the end of a validate if they are not
> expired.
>
>
>
>
>
>
>
> - Andres
> ------------------------------
>
> *From:* cas-dev-bounces at tp.its.yale.edu [mailto:cas-dev-bounces at tp.its.yale.edu]
> *On Behalf Of *March, Andres
> *Sent:* Thursday, March 01, 2007 4:19 PM
> *To:* Mailing list for CAS developers
> *Subject:* Re: [cas-dev] renew flag can be bypassed
>
>
>
> Thanks for testing. I don't think my validation specification was set
> properly. I will check the reference implementation. It looks like we just
> screwed something up but I don't know why we would have changed it from the
> default.
>
>
>
> Here is what I had:
>
> <bean id="proxyValidateController"
>
> class=" org.jasig.cas.web.ServiceValidateController">
>
> <property
>
> name="centralAuthenticationService"
>
> ref="centralAuthenticationService" />
>
> <property
>
> name="proxyHandler"
>
> ref="proxy20Handler" />
>
> </bean>
>
> <bean
>
> id="serviceValidateController"
>
> class=" org.jasig.cas.web.ServiceValidateController">
>
> <property
>
> name="validationSpecificationClass"
>
> value= "
> org.jasig.cas.validation.Cas20WithoutProxyingValidationSpecification" />
>
> <property
>
> name="centralAuthenticationService"
>
> ref="centralAuthenticationService" />
>
> <property
>
> name="proxyHandler"
>
> ref="proxy20Handler" />
>
> </bean>
>
>
>
>
>
> And what I changed it to:
>
> <bean id="proxyValidateController"
>
> class=" org.jasig.cas.web.ServiceValidateController">
>
> <property
>
> name="validationSpecificationClass"
>
> value="
> org.jasig.cas.validation.Cas20ProtocolValidationSpecification" />
>
> <property
>
> name="centralAuthenticationService"
>
> ref="centralAuthenticationService" />
>
> <property
>
> name="proxyHandler"
>
> ref="proxy20Handler" />
>
> </bean>
>
> <bean
>
> id="serviceValidateController"
>
> class=" org.jasig.cas.web.ServiceValidateController">
>
> <property
>
> name="validationSpecificationClass"
>
> value= "
> org.jasig.cas.validation.Cas20WithoutProxyingValidationSpecification" />
>
> <property
>
> name="centralAuthenticationService"
>
> ref="centralAuthenticationService" />
>
> <property
>
> name="proxyHandler"
>
> ref="proxy20Handler" />
>
> </bean>
>
>
>
>
>
> - Andres
> ------------------------------
>
> *From:* cas-dev-bounces at tp.its.yale.edu [mailto:
> cas-dev-bounces at tp.its.yale.edu] *On Behalf Of *Andrew William Petro
> *Sent:* Thursday, March 01, 2007 3:55 PM
> *To:* Mailing list for CAS developers
> *Subject:* Re: [cas-dev] renew flag can be bypassed
>
>
>
> Andres,
>
> I have tested this just now against https://www.ja-sig.org/cas
>
> Tickets obtained without specifying renew=true to login do not
> successfully validate for me using either serviceValidate or proxyValidate
> where renew=true on the validation.
>
> Exactly what do you mean when you say
> "I have validated that the url has &renew=true but the server still
> validates a ticket issued from a non-renew auth."
>
>
> ?
>
> Andrew
>
> The acegi version (1.0.2) I am using was ignoring renew:
>
>
>
> *if*( *super* .getServiceProperties().isSendRenew())
>
> *logger* .warn("The current CAS ProxyTicketValidator does not
> support the 'renew' property. The ticket cannot be validated as having been
> issued by a 'renew' authentication. It is expected this will be corrected in
> a future version of CAS' ProxyTicketValidator.");
>
>
>
>
>
> I subclassed the ticket validator and set the renew flag:
>
>
>
> *if* (sendRenew) {
>
> pv.setRenew(sendRenew);
>
> *log* .warn(
>
> "Setting renew flag. This may not be supported by
> proxyValidate.");
>
> }
>
>
>
> I have validated that the url has &renew=true but the server still
> validates a ticket issued from a non-renew auth. I still need to debug the
> CAS server to see what happens during the validate call.
>
> - Andres
>
>
>
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>
--
-Scott Battaglia
LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20070307/5e5551f0/attachment-0001.html
More information about the cas-dev
mailing list