jasig-cas IRC Logs-2011-08-12

Owned by Apereo Infrastructure
Last updated: Aug 12, 2011Version comment
12 min read

[13:02:23 CDT(-0500)] <wgthom> checkin in
[13:03:35 CDT(-0500)] <wgthom> hi andrew
[13:03:59 CDT(-0500)] <apetro> hi wgthom
[13:04:08 CDT(-0500)] <apetro> took me a moment to figure out how to make Pidgin on Windows join IRC
[13:04:12 CDT(-0500)] <apetro> anyway, checking in.
[13:05:07 CDT(-0500)] <wgthom> desperately waiting for my usb video adapter… (smile)
[13:05:50 CDT(-0500)] <apetro> you know, the Amazon reviews on that didn't seem... unambiguously positive.
[13:05:58 CDT(-0500)] <apetro> you're not concerned that that's going to turn into a driver battle?
[13:06:26 CDT(-0500)] <wgthom> i read a mac article that has me convinced it will suit my purposes...
[13:06:32 CDT(-0500)] <wgthom> we'll see i guess
[13:07:09 CDT(-0500)] <wgthom> had any time to review https://source.jasig.org/cas3/branches/cas-3_4_x_maintenance/cas-server-3.4.2/cas-server-core/src/main/java/org/jasig/cas/ticket/support/TicketGrantingTicketExpirationPolicy.java
[13:07:34 CDT(-0500)] <apetro> why's it only for cas 3.4.2? kidding, kidding.
[13:08:00 CDT(-0500)] <wgthom> lol. or more importantly perhaps the tests https://source.jasig.org/cas3/branches/cas-3_4_x_maintenance/cas-server-3.4.2/cas-server-core/src/test/java/org/jasig/cas/ticket/support/TicketGrantingTicketExpirationPolicyTests.java
[13:08:30 CDT(-0500)] <apetro> hadn't reviewed, no. Skimming now.
[13:09:17 CDT(-0500)] <wgthom> scott is anxious to cut a 3.4.10 quickly to address the bean validation problem…thinking this could come along (not as the default!) if we're happy with it
[13:09:50 CDT(-0500)] <apetro> looks like it will come along, as things stand. :)O
[13:09:53 CDT(-0500)] <wgthom> I did some sanity testing with the deployed server and it seems to be doing what I expected. of course I sent the throttle to 0
[13:09:58 CDT(-0500)] <wgthom> lol
[13:10:01 CDT(-0500)] <apetro> nitpick: needs an @since JavaDoc documenting at what version it came in
[13:10:24 CDT(-0500)] <apetro> what's the time-to-run of this unit test and is that reasonable?
[13:10:27 CDT(-0500)] <wgthom> yea, was there…i removed it since I didn't know when we might get it….could add it
[13:10:55 CDT(-0500)] <wgthom> no long. don't even notice in the full test
[13:10:59 CDT(-0500)] <wgthom> not long
[13:11:23 CDT(-0500)] <wgthom> ~15 seconds
[13:11:24 CDT(-0500)] <apetro> nitpick re style: why catch exceptions that are failures in the unit test, rather than just let it throw them?
[13:12:09 CDT(-0500)] <wgthom> good question…don't have an answer…mostly was following the test that were already there.
[13:12:48 CDT(-0500)] <apetro> k. always good to follow existing styles. Always bad to suppress a perfectly good stack trace. :)O
[13:13:32 CDT(-0500)] <apetro> so that last unit test feels... interesting
[13:13:33 CDT(-0500)] <wgthom> is there a better signature on fail()…
[13:14:04 CDT(-0500)] <wgthom> or your suggesting just - throw e;
[13:14:14 CDT(-0500)] <apetro> dunno on fail() offhand. if continuing the nitpick, I'd point out that failing with the exception message adds no value over what would have been provided by just throwing the e
[13:14:20 CDT(-0500)] <apetro> yes, I'm suggesting just throw the e
[13:14:35 CDT(-0500)] <apetro> that way if I break a test my IDE will take me right to the line that threw with the stack trace and so forth
[13:14:45 CDT(-0500)] <wgthom> cool
[13:14:48 CDT(-0500)] <apetro> however. this is an academic nitpick. This isn't really important.
[13:14:56 CDT(-0500)] <wgthom> helpful nonetheless
[13:15:07 CDT(-0500)] <apetro> yeah
[13:15:13 CDT(-0500)] <wgthom> any worthy of a cas-dev chat (smile)
[13:15:17 CDT(-0500)] <wgthom> and...
[13:15:22 CDT(-0500)] <apetro> more interesting, what you're trying to communicate with that last test method
[13:15:29 CDT(-0500)] <wgthom> yes
[13:15:45 CDT(-0500)] <apetro> so, I get it that it's weird that registry cleaning can invalidate a ticket that otherwise would have required and been valid
[13:15:55 CDT(-0500)] <apetro> it's very... heisenberg esque
[13:16:06 CDT(-0500)] <apetro> the act of looking at the validity changes the validitty.
[13:16:12 CDT(-0500)] <wgthom> lol. looking at it changes it
[13:16:20 CDT(-0500)] <apetro> that's weird and wrong. Right up there with killing cats in boxes.
[13:16:29 CDT(-0500)] <wgthom> yes
[13:16:46 CDT(-0500)] <apetro> PETA might not agree. Too bad these chats are permanently publicly logged.
[13:17:14 CDT(-0500)] <apetro> anyway. I'd say that needs more. XXX doesn't do it. Needs a whole JavaDoc method comment describing why that test exists and what it's trying to communicate
[13:17:31 CDT(-0500)] <apetro> and hopefully in the near future that JavaDoc can then change to reflect that the issue's been otherwise resolved.
[13:17:40 CDT(-0500)] <apetro> anyway, more than XXX
[13:17:40 CDT(-0500)] <wgthom> hmm…I hoping we can just drop it.
[13:18:00 CDT(-0500)] <apetro> just drop it in what way?
[13:18:10 CDT(-0500)] <apetro> stop documenting the weird behavior, or resolve the weird behavior?
[13:18:18 CDT(-0500)] <wgthom> throttle is not currently in the default policy…so I don't think this one has to add it
[13:18:35 CDT(-0500)] <wgthom> just drop throttle from this policy
[13:19:25 CDT(-0500)] <wgthom> should be implemented somewhere more appriopriate (CASImpl maybe) if at all
[13:19:57 CDT(-0500)] * apetro blinks a couple times and re-reads the class
[13:22:03 CDT(-0500)] <apetro> any insight into why the throttling behavior exists? Anyone using it? is it common practice to implement it?
[13:22:26 CDT(-0500)] <apetro> I'd hate for CAS to ship with another policy implementation that in practice adopters shouldn't / don't want to use
[13:23:01 CDT(-0500)] <wgthom> don't know of anyone using. not sure even what would be reasonable value to set for minTimeBeforeUses. had to set that near 0 on my local SSD dev env
[13:23:27 CDT(-0500)] <wgthom> minTimeBetweenUsers....
[13:24:05 CDT(-0500)] <apetro> dropping the throttling would make it better comport with the JavaDoc comment for the class.
[13:24:21 CDT(-0500)] <wgthom> i suppose it would be an improvement to add a properties check to make sure timeToKillI < maxTimeToLive
[13:24:33 CDT(-0500)] <apetro> lol
[13:24:40 CDT(-0500)] <wgthom> and both not null
[13:24:44 CDT(-0500)] <apetro> yes, could add some polish / sanity checking on those.
[13:25:08 CDT(-0500)] <wgthom> both can be done with annotations?
[13:25:11 CDT(-0500)] <apetro> alright. I favor dropping the throttling from this implementation. Would make the impl simpler, easier to understand, can always be added again later if needed.
[13:25:24 CDT(-0500)] <apetro> the @notnull can be done with annotations
[13:25:28 CDT(-0500)] <wgthom> agreed
[13:25:33 CDT(-0500)] <apetro> didn't know you could do the constraints on the comparison with annotations
[13:25:49 CDT(-0500)] <wgthom> me either…was asking.
[13:26:01 CDT(-0500)] <apetro> I bet there's some fancy way to do it, and I bet that's not worth doing.
[13:26:08 CDT(-0500)] <wgthom> maybe not
[13:26:19 CDT(-0500)] <wgthom> maybe it mean less typing
[13:26:24 CDT(-0500)] <wgthom> if it...
[13:26:34 CDT(-0500)] <wgthom> and more consistency
[13:26:51 CDT(-0500)] <apetro> if you can find an example of such a fancy use of annotations elsewhere in CAS, sure.
[13:26:57 CDT(-0500)] <apetro> match the style of the existing code, as it were
[13:27:18 CDT(-0500)] <apetro> those constraints going to work with these being javabean props rather than constructor args?
[13:27:28 CDT(-0500)] <wgthom> no idea
[13:27:29 CDT(-0500)] <wgthom> :0
[13:27:47 CDT(-0500)] <wgthom> i'm sure there's a Spring answer here.
[13:27:50 CDT(-0500)] <fairwinds> hi guys. are you having regular meeting now? If so will come back later
[13:27:51 CDT(-0500)] <apetro> if you want to get too careful with ensuring sane internal state, maybe make it all constructor args, make it immutable, and rigorously verify state in constructor.
[13:28:18 CDT(-0500)] <wgthom> yea, I like the properties for the configuration files though
[13:28:31 CDT(-0500)] <apetro> fairwinds, yes, it's a regular meeting, but we're now in the weeds discussing how to constrain properties of an expiration policy, so, I bet whatever you want to talk about is just as interesting.
[13:28:49 CDT(-0500)] <apetro> wgthom, I like the properties for the literacy of the config files too
[13:29:05 CDT(-0500)] <wgthom> <!-- Ticket Granting Ticket Expiration Policy -->
[13:29:05 CDT(-0500)] <wgthom> <bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket.support.TicketGrantingTicketExpirationPolicy"
[13:29:05 CDT(-0500)] <wgthom> p:maxTimeToLiveInMilliSeconds="28800000"
[13:29:05 CDT(-0500)] <wgthom> p:timeToKillInMilliSeconds="7200000"
[13:29:05 CDT(-0500)] <wgthom> p:minTimeInBetweenUsesInMilliSeconds="0" />
[13:29:34 CDT(-0500)] <apetro> alright. I guess I'm a little concerned about the timeline on this, in that you need to get these details right before scott cuts cas 3.4.10, which is, what, this evening?
[13:29:46 CDT(-0500)] <wgthom> no idea
[13:29:54 CDT(-0500)] <wgthom> all I got is soon. (smile)
[13:30:10 CDT(-0500)] <wgthom> but i get your point
[13:30:13 CDT(-0500)] <apetro> makes me ever more in love with that git dev process blog post / diagram / article you've been passing around.
[13:30:25 CDT(-0500)] <wgthom> yep
[13:30:49 CDT(-0500)] <wgthom> fairwinds: what's up?
[13:30:58 CDT(-0500)] <fairwinds> heh. my questions was about whether cas ticket identifiers are special. I might like to change them
[13:31:07 CDT(-0500)] <wgthom> in what way?
[13:31:16 CDT(-0500)] <apetro> they're not special at all. They're just strings.
[13:31:30 CDT(-0500)] <wgthom> well..there special to the cas server that served them up. (smile)
[13:31:45 CDT(-0500)] <apetro> oh, indeed.
[13:33:07 CDT(-0500)] <apetro> the format , style , etc. of the identifier isn't special. In fact, there's APIs for that, so it's feasible to make them look other than they do. The main consideration is that they need to have enough entropy that folks can't guess them. But in principle, "correcthorsebatterystaple" would be a fine ticket.
[13:33:07 CDT(-0500)] <fairwinds> hehe. moreso I may want to change prefixes and suffixes or omit possibly
[13:33:27 CDT(-0500)] <fairwinds> heh
[13:33:42 CDT(-0500)] <wgthom> fairwinds: what's the driver for the change?
[13:33:57 CDT(-0500)] <wgthom> a fine ticket id… (smile)
[13:34:02 CDT(-0500)] <apetro> yeah. In principle you can change those. the CAS protocol document has some guidance about those prefixes, and I know the change in style to make Proxy Tickets appear as ST- rather than PT- annoyed some folks.
[13:34:18 CDT(-0500)] <wgthom> annoyed me
[13:34:24 CDT(-0500)] <apetro> it's certainly handy to have a suffix on the ticket identifying the CAS server node that issued the ticket when CAS is a cluster.
[13:34:31 CDT(-0500)] <wgthom> no doubt
[13:35:07 CDT(-0500)] <apetro> Right. The prefix thing is similar. It makes the traffic a little more literate to identify STs vs PTs, but in principle, these are just strings, and the only thing that's really important is that they not be guessable.
[13:35:14 CDT(-0500)] <apetro> Everything else is window dressing.
[13:35:26 CDT(-0500)] <wgthom> sure
[13:35:27 CDT(-0500)] <fairwinds> was just thinking that for any security system I typically want to remove any indication of what it is and what version of it I am using
[13:35:52 CDT(-0500)] <fairwinds> usually these things can be used against you
[13:35:58 CDT(-0500)] <wgthom> fair enough…but the ticket ids require confidentiality via ssl in any case
[13:36:16 CDT(-0500)] <apetro> yeah. I tend to violently disagree with that sort of thing in principle. the system is either secure or it isn't. The tickets are either sufficiently random or they're not. Everything else is just a distraction.
[13:37:14 CDT(-0500)] <wgthom> disagree with what sort of thing? confidentiality via ssl? or removing any indication of what it is?
[13:37:39 CDT(-0500)] <apetro> for instance, in the ticket granting cookie generator, you can select the name of the TGT cookie. https://source.jasig.org/cas3/branches/cas-3_4_x_maintenance/cas-server-3.4.2/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketGrantingTicketCookieGenerator.xml There's a suggestion that you might pick something else so it's harder to guess. That kind of thing annoys me. The cookie is secure because it's content is r
[13:38:31 CDT(-0500)] <apetro> that is, context for comment: I tend not to value "remove any indication of what it is" and rather, yes, lean on SSL and the randomness of the tickets.
[13:38:44 CDT(-0500)] <apetro> was disagreeing with fairwinds, not with wgthom, just to beat clarifying to death (smile)
[13:38:50 CDT(-0500)] <wgthom> ok
[13:38:52 CDT(-0500)] <wgthom> (smile)
[13:38:54 CDT(-0500)] <fairwinds> well, even for front end servers, for production I remove version number from sources so doesn't end up being displayed anywhere in error messages etc.
[13:39:24 CDT(-0500)] <apetro> yeah. I guess i can see that, since otherwise someone can execute a well known exploit associated with a certain version.
[13:39:41 CDT(-0500)] <apetro> but again, what protects you from a well known exploit is actually blocking it, not hoping that people don't realize they can use it.
[13:40:26 CDT(-0500)] <fairwinds> apetro: thing is, is that I patch etc every day but this just make things that much more difficult since you are providing the bad guys with info
[13:40:43 CDT(-0500)] <apetro> plus, if you don't display the version number and make it clear that you're using CAS, it's harder for me to use your server as a motivating example when trying to get someone else to adopt CAS (smile)
[13:40:56 CDT(-0500)] <fairwinds> apetro: hehe
[13:41:27 CDT(-0500)] <apetro> I dunno.
[13:41:39 CDT(-0500)] <apetro> wgthom, what's that security professional certification you were saying I should look into?
[13:41:40 CDT(-0500)] <wgthom> +1 for not displaying the version number though…and I get your motivation for wanting hide the implementation.
[13:41:49 CDT(-0500)] <wgthom> cissp
[13:42:46 CDT(-0500)] <apetro> maybe if I had that CISSP certification I'd feel differently. The computer scientist in me has trouble valuing anything other than the sufficient bits of entropy part and the SSL part.
[13:43:04 CDT(-0500)] <apetro> so, fairwinds, take wgthom's advice, he's wiser.
[13:43:26 CDT(-0500)] <wgthom> lol. i don't know about that
[13:43:37 CDT(-0500)] <wgthom> more paranoid maybe (smile)
[13:43:59 CDT(-0500)] <fairwinds> heh, yeah I think paranoid is way I operate for most part
[13:44:04 CDT(-0500)] <apetro> I guess this reminds me of a really old conversation about CAS development.
[13:44:11 CDT(-0500)] <apetro> so a service validates a service ticket
[13:44:18 CDT(-0500)] <apetro> and gets the service= parameter associated with the validation call wrong
[13:44:27 CDT(-0500)] <apetro> should the correct service value be in the error message from CAS?
[13:44:43 CDT(-0500)] <wgthom> no
[13:44:55 CDT(-0500)] <apetro> indeed. You argued that viewpoint very successfully then.
[13:45:01 CDT(-0500)] <apetro> whereas I say yes.
[13:45:04 CDT(-0500)] <wgthom> lol
[13:45:08 CDT(-0500)] <wgthom> i hardly remember
[13:45:21 CDT(-0500)] <apetro> because, for the poor guy trying to integrate with CAS, it's just so very useful to know what I've gotten wrong with the service parameterr
[13:45:32 CDT(-0500)] <apetro> (hint: I probably have or do not have a trailing / on it)
[13:45:40 CDT(-0500)] <apetro> and the CAS server is in a position to tell me
[13:45:54 CDT(-0500)] <wgthom> so is the CAS admin….when he sees it in the logs
[13:45:55 CDT(-0500)] <apetro> the service= param exists to protect me as the service relying upon CAS, not to protect the user
[13:46:06 CDT(-0500)] <fairwinds> hehe, I think I have stirred warm fuzzy memories (smile)
[13:46:31 CDT(-0500)] <apetro> indeed
[13:46:33 CDT(-0500)] <fairwinds> how long have you guys been with cas now
[13:47:20 CDT(-0500)] <apetro> anyway, there's a whole conversation around this, and I think we're both right, in some sense, and it gets back to this question of, do you rely upon the SSL and the randomness, or do you also try to inconvenience the adversary too.
[13:47:26 CDT(-0500)] <wgthom> https://www.owasp.org/index.php/Top_10_2007-Information_Leakage_and_Improper_Error_Handling
[13:47:40 CDT(-0500)] <apetro> I think it's been since 2003 or so.
[13:47:48 CDT(-0500)] <fairwinds> apetro: actually my intent is to do both
[13:47:57 CDT(-0500)] <wgthom> eh, late 2002
[13:48:00 CDT(-0500)] <wgthom> no?
[13:50:13 CDT(-0500)] <apetro> on the link? no, I really don't think so. If the Adversary has gotten his hands on the ST, you've already lost. The security model depends on him not being able to intercept or guess tickets. Once he's got one, adding a very few bits of difficulty of guessing what service it would have validated against is of no theoretical security benefit, and is of practical damage to the poor guy trying to legitimately integrate with CAS. It's
[13:50:14 CDT(-0500)] <fairwinds> wow. that's a good amount of time for sure
[13:50:55 CDT(-0500)] <apetro> tis. It's been a while.
[13:51:07 CDT(-0500)] <apetro> but in all that time, I haven't implemented an erlang CAS client.
[13:51:13 CDT(-0500)] <wgthom> hehe
[13:51:15 CDT(-0500)] <fairwinds> heh
[13:51:16 CDT(-0500)] <apetro> how's the project going otherwise?
[13:51:30 CDT(-0500)] <apetro> are you down to worrying about the format of tickets and the display of version numbers?
[13:51:38 CDT(-0500)] <apetro> cuz if these are you're problems, sounds like you're in great shape.
[13:51:54 CDT(-0500)] <fairwinds> great, I am having fun with it and very close yup
[13:52:10 CDT(-0500)] <apetro> excellent.
[13:52:35 CDT(-0500)] <fairwinds> It is going to be fun to see in production
[13:52:45 CDT(-0500)] <fairwinds> my target is end of month
[13:52:49 CDT(-0500)] <wgthom> nice
[13:53:01 CDT(-0500)] <apetro> well, even if you don't want an exact version number in it, would be great to include a deployment profile here: http://www.jasig.org/cas/deployments
[13:53:12 CDT(-0500)] <fairwinds> hehe, sure
[13:54:53 CDT(-0500)] <apetro> wgthom , what's the resolution on that ticket policy implementation? You're going to apply a pass of doing reasonable things and it will be good enough to ship in that 3.4.10 patch release pronto? (and disappear to a lovely camping trip and so be out of reach of any issues that arise (smile) ) ?
[13:55:11 CDT(-0500)] <apetro> guess that's been rattling around in my brain further as we've been talking of other thigns
[13:55:18 CDT(-0500)] <wgthom> fairwinds: can you tell us anymore about the deployment? industry?
[13:55:38 CDT(-0500)] <wgthom> yes. the former
[13:55:57 CDT(-0500)] <wgthom> er…yes, both.
[13:56:23 CDT(-0500)] <apetro> k. well, I'll be around, I'll keep an eye out for any issues around it.
[13:56:48 CDT(-0500)] <wgthom> cool. i'm reachable in any case.
[13:57:52 CDT(-0500)] <fairwinds> wgthom, apetro: SaaS for verticals but will be able to show in a couple weeks
[13:58:26 CDT(-0500)] <apetro> that'd be awesome.
[13:58:49 CDT(-0500)] <apetro> we do cas community calls from time to time, there might be an appropriate and valuable way for you to showcase your efforts in one of those if interested.
[13:59:13 CDT(-0500)] <fairwinds> apetro: sure
[14:00:17 CDT(-0500)] <fairwinds> apetro: this is all about high availability and scalability
[14:00:41 CDT(-0500)] <fairwinds> that is why erlang and distributed data etc
[14:03:39 CDT(-0500)] <fairwinds> apetro, wgthom: I was thinking of writing a CAS server in js
[14:05:06 CDT(-0500)] <fairwinds> but I need to walk before I run but this is something that is on my mind right now
[14:05:55 CDT(-0500)] <wgthom> my time is up…i thank you for yours. fairwinds…good luck with your deployment…please keep us up to date.
[14:06:05 CDT(-0500)] <apetro> sounds an interesting project. Speaking of needing to walk and run, I'm out of time. I thank you for yours. Darn, wgthom beat me to the line.
[14:06:12 CDT(-0500)] <wgthom> lol
[14:06:18 CDT(-0500)] <wgthom> later
[14:06:25 CDT(-0500)] <fairwinds> heh sure. cu