[08:33:41 CST(-0600)] <battags> hey Marvin. I've got a meeting at 2pm today so I figured I'd see who's on chat now
[08:33:51 CST(-0600)] <MarvinAddison> Hey man.
[08:34:09 CST(-0600)] <MarvinAddison> I actually wanted to talk to you.
[08:34:21 CST(-0600)] <battags> that's why we have this chat room
[08:34:21 CST(-0600)] <MarvinAddison> I merged the x509 revocation checking into trunk.
[08:34:24 CST(-0600)] <MarvinAddison> You should take a look.
[08:34:41 CST(-0600)] <MarvinAddison> r23023
[08:34:46 CST(-0600)] <battags> ok I'll take a look tonight
[08:34:50 CST(-0600)] <MarvinAddison> Tests pass, but other eyeballs are good.
[08:35:13 CST(-0600)] <battags> how is our test coverage on X.509? its pretty good right
[08:35:22 CST(-0600)] <battags> I've been working on adding coverage back to other sections
[08:35:25 CST(-0600)] <MarvinAddison> I added a lot of tests in 936, so pretty good.
[08:35:31 CST(-0600)] <MarvinAddison> I ported those over in merge.
[08:35:35 CST(-0600)] <battags> we've been dropping our coverage over the years
[08:35:39 CST(-0600)] <battags> which I suppose is mostly my fault haha
[08:36:23 CST(-0600)] <MarvinAddison> It's hard to maintain tests, for sure.
[08:36:37 CST(-0600)] <MarvinAddison> Who likes testing anyway
[08:36:45 CST(-0600)] <MarvinAddison> We do it cuz it's right, not fun.
[08:36:53 CST(-0600)] <battags> I started adding a bunch for the SAML 1.1 support
[08:37:03 CST(-0600)] <battags> everything was failing until I realized we need to bootstrap OpenSAML
[08:37:46 CST(-0600)] <MarvinAddison> Speaking of SAML....
[08:38:00 CST(-0600)] <MarvinAddison> Work estimate for backporting opensaml2 libs into 3.4.x?
[08:38:44 CST(-0600)] <battags> the backport is probably less than a day's worth of work
[08:38:49 CST(-0600)] <battags> not sure its ready to be backported
[08:38:58 CST(-0600)] <battags> I need to understand the OpenSAML library a bit better
[08:38:59 CST(-0600)] <MarvinAddison> Sounds encouraging.
[08:39:06 CST(-0600)] <battags> i.e. are all those object builders threadsafe
[08:39:16 CST(-0600)] <battags> I keep building new ones
[08:39:32 CST(-0600)] <battags> haven't had a chance to read the code yet
[08:39:37 CST(-0600)] <MarvinAddison> There's no thread safety discussion in the javadocs?
[08:39:49 CST(-0600)] <battags> I'll have to double check
[08:39:54 CST(-0600)] <battags> I was really focused on getting it to work
[08:39:58 CST(-0600)] <MarvinAddison> sure
[08:40:21 CST(-0600)] <battags> though digital signing is disabled for now until we figure out services management
[08:40:42 CST(-0600)] <MarvinAddison> I will spend some time on that in the coming week.
[08:41:42 CST(-0600)] <MarvinAddison> I hope some of that work will point to what exactly we want to support in SAML initially.
[08:41:53 CST(-0600)] <MarvinAddison> Obviously signing.
[08:42:06 CST(-0600)] <MarvinAddison> I've never seen a relying party in my shib work that uses message encryption.
[08:42:37 CST(-0600)] <battags> I want to do the minimal effort to help the most people
[08:42:39 CST(-0600)] <MarvinAddison> If we could ignore that now (and maybe forever), would reduce work.
[08:42:45 CST(-0600)] <MarvinAddison> Exactly.
[08:43:01 CST(-0600)] <MarvinAddison> I'm not exactly sure what that means, but I'm fairly confident it doesn't include encryption.
[08:43:05 CST(-0600)] <battags> ha
[08:43:16 CST(-0600)] <MarvinAddison> At least until someone shows up and asks for it with a compelling argument.
[08:44:57 CST(-0600)] <MarvinAddison> On another topic....
[08:45:01 CST(-0600)] <battags> and of course the bar for compelling is that they need to convince either you or I
[08:45:08 CST(-0600)] <MarvinAddison> ha
[08:45:29 CST(-0600)] <battags> what is the other topic?
[08:45:31 CST(-0600)] <MarvinAddison> I feel really good about helping that Greek fellow. I'm blushing that he showed up on Sept and just today we got it sorted out.
[08:45:52 CST(-0600)] <MarvinAddison> Hopefully other folks are having the same issue with attribute release – not selecting attrs in svc mgr.
[08:46:24 CST(-0600)] <MarvinAddison> Seems like there's been a lot of folks with attribute release problems in the past weeks.
[08:47:04 CST(-0600)] <MarvinAddison> Do we need to show a screen shot of the service manager with attributes selected to make that clear? Seems like other folks have had that problem.
[08:47:09 CST(-0600)] <battags> I don't think a lot of people realize we don't just automatically release attributes
[08:47:29 CST(-0600)] <MarvinAddison> Yeah, I don't think we say that explicitly.
[08:48:07 CST(-0600)] <MarvinAddison> We probably ought to have some general discussion of that on https://wiki.jasig.org/display/CASUM/Attributes prior to the config discussion.
[08:48:32 CST(-0600)] <MarvinAddison> Damn, documentation can be time consuming.
[08:49:24 CST(-0600)] <MarvinAddison> Just going to do it now.
[08:51:43 CST(-0600)] <battags> I also want to see how to apply your patch of logging to the CAS4 code base
[08:53:49 CST(-0600)] <MarvinAddison> Should be easy. It's like 8-10 lines total.
[08:56:16 CST(-0600)] <MarvinAddison> Edited https://wiki.jasig.org/display/CASUM/Attributes with a warning. Hopefully that'll help.
[09:00:04 CST(-0600)] <MarvinAddison> Have any thoughts about that "Clustered CAS client logout request" thread on cas-user?
[09:41:18 CST(-0600)] <battags> my goal is to look at it over the weekend
[09:41:26 CST(-0600)] <battags> well to think about it
[09:41:27 CST(-0600)] <battags> that is
[09:42:45 CST(-0600)] <battags> I need to re-read the thread
[13:04:45 CST(-0600)] <apetro> It's 2pm Eastern on a Friday; do you know where you CAS server is?
[13:05:42 CST(-0600)] <apetro> wgthom , EricDalquist : Anything we particularly need to discuss in this designated cas-dev IRC timeslot?
[13:06:19 CST(-0600)] <EricDalquist> I'm just lurking here
[13:06:24 CST(-0600)] <EricDalquist>
[13:08:11 CST(-0600)] <apetro> That's fine. I have little useful progress to report, embarrassingly. Just been absolutely slammed.
[13:09:07 CST(-0600)] <apetro> For the IRC log records, I continue to intend to get on top of productizing the password policy CAS extension, ideally abstracting it beyond just LDAP-backed policy and definitely polishing its relationship with and ease of installation onto the latest CAS release.
[13:09:45 CST(-0600)] <apetro> With an eye especially to reducing invasiveness, ideally eliminating its replacement of any class shipping with CAS and instead factoring it entirely as plugging in to CAS extension points.
[13:09:57 CST(-0600)] <apetro> That will all be more interesting to talk about once I have working code.
[13:11:04 CST(-0600)] <apetro> I know John Martin of Unicon has been designing some beautiful mockups of screens for the next major CAS release. I expect those images will be added to their respective JIRA issues promptly if they're not already there.
[13:11:36 CST(-0600)] <apetro> I believe the CAS project response to the parseDouble vulnerability has been sufficient, with announcements going out on-list and on the CAS website news feed. Also on my own blog, for whatever that's worth.
[13:12:30 CST(-0600)] <apetro> That's all the news I have to summarize, off hand. I'll hang out here for the remainder of the designated hour, and if anyone wants to kick off discussion of some aspect of CAS development, I'm game, but I have no further prepared material this week.
[13:17:45 CST(-0600)] <apetro> matt_uconn , welcome
[13:18:07 CST(-0600)] <matt_uconn> Hey Andrew, sorry I'm late to the show. Just review the logs now.
[13:18:20 CST(-0600)] <apetro> Any topics on CAS development you're looking to discuss in this designated weekly time slot?
[13:18:43 CST(-0600)] <matt_uconn> Nope, just looking forward to the 3/15 Meetup
[13:19:48 CST(-0600)] <apetro> welcome, serac
[13:19:54 CST(-0600)] <MarvinAddison> Howdy.
[13:20:03 CST(-0600)] <MarvinAddison> Power blip today killed my UPS – just got back up.
[13:20:14 CST(-0600)] <MarvinAddison> Hella winds here.
[13:20:54 CST(-0600)] <MarvinAddison> Anyone read that thread I mentioned above?
[13:21:05 CST(-0600)] <MarvinAddison> About clustering w/clients.
[13:21:26 CST(-0600)] <apetro> missed that mention, seeking Confluence logs...
[13:21:54 CST(-0600)] <MarvinAddison> Ah, right. irc doesn't do room history – I use Jabber too much I guess.
[13:22:40 CST(-0600)] <wgthom> checking in
[13:22:59 CST(-0600)] <MarvinAddison> Hey Bill.
[13:23:16 CST(-0600)] <wgthom> looking for the NYC meetup as well. i'd like to see us grow the particpant list a lil bit
[13:23:48 CST(-0600)] <MarvinAddison> Yeah. And participants hopefully lead to devs.
[13:24:09 CST(-0600)] <matt_uconn> There is competition now for the date – there is a Shib Workshop @UMass on 3/14-3/15
[13:24:33 CST(-0600)] <MarvinAddison> I wish those Shib guys would quit horning in on our time slots
[13:25:02 CST(-0600)] <wgthom> i don't have cycles to help, but I'd the idea of extended flows on the cas login to handle password policy
[13:25:30 CST(-0600)] <MarvinAddison> It's going to happen, just a matter of time frame.
[13:25:54 CST(-0600)] <MarvinAddison> I just completed custom work here for password expiration and yearly change.
[13:26:05 CST(-0600)] <wgthom> nice
[13:26:10 CST(-0600)] <MarvinAddison> Was easy.
[13:26:24 CST(-0600)] <MarvinAddison> But "productizing" something will be more work, but doable.
[13:26:37 CST(-0600)] <MarvinAddison> That's Andrew's word for LDAP pwd expiration stuff.
[13:27:05 CST(-0600)] <apetro> It's doable. And I'm on the hook to deliver this as part of the Q1 2011 Coop Support for CAS Coop Dev effort
[13:27:14 CST(-0600)] <MarvinAddison> In sandbox yet?
[13:27:31 CST(-0600)] <apetro> so there will be something, whether it's updated code based on what's already in Confluence, or going further
[13:27:44 CST(-0600)] <apetro> nope, not in sandbox yet. Haven't had cycles this week.
[13:27:58 CST(-0600)] <MarvinAddison> You failed the woot test
[13:28:07 CST(-0600)] <apetro> But that deadline's approaching. Going to have to find cycles.
[13:28:10 CST(-0600)] <MarvinAddison> Really wanted to give it to you.
[13:29:17 CST(-0600)] <apetro> I'd really like to earn it.
[13:29:22 CST(-0600)] <MarvinAddison> Right on.
[13:29:28 CST(-0600)] <MarvinAddison> You read through that thread yet?
[13:29:37 CST(-0600)] <MarvinAddison> Was hoping you'd have some feedback.
[13:30:51 CST(-0600)] <apetro> that's a long thread
[13:30:53 CST(-0600)] <apetro> skimmed
[13:31:34 CST(-0600)] <apetro> what's the issue? We think work needs done to broadcast the CAS server logout callback to all members of an set of clustered relying party application nodes?
[13:31:59 CST(-0600)] <MarvinAddison> That's the suggested impl, which I have issues with as stated.
[13:32:08 CST(-0600)] <MarvinAddison> It's not what we were leaning toward.
[13:32:36 CST(-0600)] <apetro> I guess my immediate grouchy reaction is to question whether this is an issue for CAS. The logout callback on whatever server it reaches results in that instance updating state, right? As in, like, killing the session? Why doesn't that kill the session on all the load balanced nodes?
[13:32:50 CST(-0600)] <apetro> How are these applications handling it if a user explicitly locally logs out from that application?
[13:33:23 CST(-0600)] <MarvinAddison> Problem is that session affinity doesn't apply to the CAS server issuing the LogoutRequest.
[13:33:31 CST(-0600)] <MarvinAddison> So to LB, the source appears different.
[13:33:41 CST(-0600)] <MarvinAddison> And can get routed to different node than one holding session.
[13:33:58 CST(-0600)] <MarvinAddison> So without either shared authn state, or rebroadcast, it simply won't work a large percentage of time.
[13:34:02 CST(-0600)] <wgthom> troll...single sign out is evil
[13:34:13 CST(-0600)] <apetro> wgthom, agreed, troll
[13:34:21 CST(-0600)] <apetro> ok
[13:34:27 CST(-0600)] <MarvinAddison> s/evil/hard/ and I'm right with you.
[13:34:33 CST(-0600)] <wgthom> lol
[13:34:34 CST(-0600)] <apetro> so, the confusion is mostly mine, from having just skimmed the thread
[13:34:36 CST(-0600)] <MarvinAddison> It's never going to work 100% of the time.
[13:34:40 CST(-0600)] <MarvinAddison> It's best effort at best.
[13:34:45 CST(-0600)] <apetro> but let's get more rigorous in talking about what problem we're solving here
[13:34:52 CST(-0600)] <wgthom> I'ts a best effort beast.
[13:34:59 CST(-0600)] <MarvinAddison> haha
[13:35:03 CST(-0600)] <apetro> so the issue isn't client applications that are truly clustered
[13:35:14 CST(-0600)] <apetro> since if they were truly clustered, then poking one node ought to be sufficient
[13:35:20 CST(-0600)] <MarvinAddison> Depends on your definition of cluster and LB architecture, for sure.
[13:35:36 CST(-0600)] <apetro> the issue is client applications that are load balanced
[13:35:47 CST(-0600)] <apetro> in that the CAS logout callback won't necessarily reach the correct node
[13:36:00 CST(-0600)] <wgthom> seems like an application specific issue...no?
[13:36:02 CST(-0600)] <MarvinAddison> If you want to be strict about distinction between load balanced and clustered, yes.
[13:36:10 CST(-0600)] <apetro> I do
[13:36:12 CST(-0600)] <MarvinAddison> It is app-specific, but important case.
[13:36:20 CST(-0600)] <MarvinAddison> apetro – ok
[13:36:21 CST(-0600)] <apetro> hard enough to get my brain around this even being strict
[13:36:27 CST(-0600)] <MarvinAddison> agreed
[13:36:34 CST(-0600)] <wgthom> app specific...meaning not a CAS client concern per se
[13:36:38 CST(-0600)] <MarvinAddison> Even if they're clustered, strictly...
[13:36:48 CST(-0600)] <MarvinAddison> The CAS server will never have the session identifier.
[13:37:04 CST(-0600)] <MarvinAddison> So even for "clustered" ala JBossCache session-sharing, won't work.
[13:37:26 CST(-0600)] <apetro> wgthom, hold off on the trolling long enough for me to grok this? I'll abolutely agree with you that CAS should weasel out of dealing with this concern, but I suppose I need to understand the concern to maximize the weaseling.
[13:37:28 CST(-0600)] <MarvinAddison> You can't look up a session without the identifier, at least not via servlet apis.
[13:38:07 CST(-0600)] <apetro> ok, MarvinAddison, you definitely lost me now
[13:38:34 CST(-0600)] <apetro> how does this work in the not-clustered, not-load-balanced, just one client node case?
[13:38:34 CST(-0600)] <MarvinAddison> The premise is that in clustered (true cluster), the authenticated state is in the session, so you must kill session to logout.
[13:38:58 CST(-0600)] <MarvinAddison> In simple case the CAS server sends LogoutRequest to service URL.
[13:39:25 CST(-0600)] <MarvinAddison> Since there's only one host servicing the app, it holds the session and, given an ST, can lookup the sessionID, grab the session and #invalidate() it.
[13:39:47 CST(-0600)] <apetro> ok
[13:39:48 CST(-0600)] <apetro> I got that
General
Content
Integrations