[cas-dev] renew flag can be bypassed
March, Andres
amarch at soe.sony.com
Wed Mar 7 12:10:06 EST 2007
I'm an idiot. I must have missed that. By the way, any chance of
getting the AbstractDistributedTicketRegistry in the 3.0 branch? It
doesn't seem to depend upon anything in 3.1 except a couple new methods
on the Ticket interface (I'm doing a cast to AbstractTicket).
- 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: Wednesday, March 07, 2007 5:24 AM
To: Mailing list for CAS developers
Subject: Re: [cas-dev] renew flag can be bypassed
Andres,
I'm not sure what you mean. Every proxied method that may require
updating the ticket state calls a protected method called updateTicket
and passes in the original ticket, not the proxied ticket. At least it
should be in theory. Which part is passing the proxied ticket?
Thanks
-Scott
On 3/2/07, March, Andres <amarch at soe.sony.com> wrote:
So I am using a back-ported version of the
AbstractDistributedTicketRegistry now as a base class to my registry and
implemented update ticket. One problem that I face is that I don't want
to add the proxy to the registry. I want to get the proxied ticket to
re-add. This AbstractDistributedTicketRegistry's proxy tickets don't
expose the proxied value. Since I have already copied the class into
our jar, I am adding a method to do this but have you considered this
issue? If I add the proxy to the registry, the next time I would proxy
the proxy, and so on and so forth.
- Andres
________________________________
From: cas-dev-bounces at tp.its.yale.edu [mailto:
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 <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/9ee67e64/attachment-0001.html
More information about the cas-dev
mailing list