Page Comparison

[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
[13:40:31 CST(-0600)] <MarvinAddison> In the clustered case, you have to be very careful.
[13:40:40 CST(-0600)] <apetro> so when we're clustered, the sessions are clustered onto all the client application nodes, right? So any node should be able to do that same lookup of session identifier from ST and invalidate() the session?
[13:40:41 CST(-0600)] <MarvinAddison> The ST-SessionID mapping MUST be global.
[13:41:03 CST(-0600)] <MarvinAddison> If not, you only contain a mapping of the sessions you have, and it's no different than load-balanced case.
[13:41:08 CST(-0600)] <apetro> and the ST->SessionID map, that's in some reasonable clustered map technology?
[13:41:19 CST(-0600)] <MarvinAddison> It MUST be to work.
[13:41:26 CST(-0600)] <apetro> but presently isn't?
[13:41:30 CST(-0600)] <MarvinAddison> No
[13:41:32 CST(-0600)] <apetro> aha
[13:41:50 CST(-0600)] <apetro> ok
[13:41:53 CST(-0600)] <MarvinAddison> The extension points are there, but no one has built the cluster-supported solution.
[13:42:04 CST(-0600)] <MarvinAddison> SessionMapping interface iirc.
[13:42:13 CST(-0600)] <apetro> that much sounds like a CAS client library lack-of-necessary-feature
[13:42:15 CST(-0600)] <MarvinAddison> confirming...
[13:42:21 CST(-0600)] <MarvinAddison> agreed
[13:42:44 CST(-0600)] <apetro> wgthom, agreeing that much is unambiguously an issue for the CAS client library to address?
[13:42:53 CST(-0600)] <MarvinAddison> org.jasig.cas.client.session.SessionMappingStorage
[13:44:06 CST(-0600)] <apetro> CASC-114 seems pretty abstract. Is it the JIRA that would address this specific issue, is there one more specific, or do we need one more specific?
[13:44:17 CST(-0600)] <wgthom> reasonable CAS Client support for Clustered deployment...yes
[13:44:47 CST(-0600)] <MarvinAddison> 114 is a step further, but we need an issue to track the obvious solution – an impl of SessionMappingStorage suitable for clustered deployments.
[13:45:13 CST(-0600)] <apetro> agreed needed. Who wants the action item to create that JIRA?
[13:46:27 CST(-0600)] <apetro> Alright, even I can create a JIRA. Taken.
[13:46:43 CST(-0600)] <MarvinAddison> https://issues.jasig.org/browse/CASC-142
[13:46:50 CST(-0600)] <apetro> even better
[13:47:02 CST(-0600)] <MarvinAddison> Easy enough.
[13:47:20 CST(-0600)] <MarvinAddison> I've actually been meaning to work on this because we have a use case.
[13:47:25 CST(-0600)] <MarvinAddison> That puts me a step closer.
[13:47:29 CST(-0600)] <apetro> Ok. That solves the problem for truly clustered applications, yes?
[13:47:36 CST(-0600)] <MarvinAddison> Believe so.
[13:47:47 CST(-0600)] <apetro> Clustered means any node can successfully invalidate the session if it can find it, CASC-142 would allow it to find it.
[13:48:02 CST(-0600)] <MarvinAddison> Correct.
[13:48:11 CST(-0600)] <MarvinAddison> Assuming the session data is also clustered.
[13:48:19 CST(-0600)] <apetro> Ok. So then there's the weird case where application is load balanced but not clustered.
[13:48:23 CST(-0600)] <MarvinAddison> Both the mapping and session data must be global/shared between all nodes.
[13:48:50 CST(-0600)] <MarvinAddison> I envisioned 114 as a solution for that case and possibly others, like JAAS, as noted on the issue.
[13:48:59 CST(-0600)] <MarvinAddison> AssertionStorage models after TicketRegistry.
[13:49:08 CST(-0600)] <MarvinAddison> Conceptually.
[13:49:11 CST(-0600)] <apetro> Interesting.
[13:49:40 CST(-0600)] <apetro> So on every request, cas client library verifies that assertion that authenticated the session is still valid?
[13:49:47 CST(-0600)] <MarvinAddison> I borrowed the idea from a proposal Scott Holodak made, but I thought it was a good one.
[13:49:51 CST(-0600)] <MarvinAddison> Correct.
[13:50:16 CST(-0600)] <apetro> and so a logout callback to node-the-user-isn't-on yields change in assertion storage state such that on next user request to node-user-is-actually-on, that node intercepts and kills session.
[13:50:26 CST(-0600)] <MarvinAddison> Exactly.
[13:50:36 CST(-0600)] <apetro> Gross.
[13:50:42 CST(-0600)] <apetro> Not saying it's not necessary, but gross.
[13:50:51 CST(-0600)] <MarvinAddison> But it supports more types of deployments, which is good.
[13:51:08 CST(-0600)] <apetro> Yeah
[13:51:09 CST(-0600)] <MarvinAddison> We eschew true clustering here for simplicity and are happy.
[13:51:16 CST(-0600)] <MarvinAddison> JBoss
[13:51:17 CST(-0600)] <apetro> Happy is good
[13:51:21 CST(-0600)] <apetro> I dunno
[13:51:22 CST(-0600)] <MarvinAddison> Tomcat
[13:52:04 CST(-0600)] <MarvinAddison> Regardless of those opinions, lots of folks want simple yet scalable deployment strategies.
[13:52:17 CST(-0600)] <apetro> Sure
[13:52:18 CST(-0600)] <MarvinAddison> And load balanced with session affinity is a good one.
[13:52:34 CST(-0600)] <apetro> agreed
[13:52:53 CST(-0600)] <apetro> I dunno, wgthom. I'm as weasely as the next guy but I'm not sure how we weasel out of this one.
[13:53:08 CST(-0600)] <apetro> CASC-114 is sounding like a good, practical, reasonable answer
[13:53:15 CST(-0600)] <apetro> especially if someone wants to write an impl that actually performs
[13:53:25 CST(-0600)] <apetro> (looking up remote state on every request is a loser, e.g.)
[13:54:04 CST(-0600)] <MarvinAddison> Depends on the backend, but I hear you.
[13:54:52 CST(-0600)] <apetro> yeah
[13:55:14 CST(-0600)] <apetro> I guess I'm having to agree that this is the CAS client library's problem because it's the CAS client library that's keeping track of the logged in user identity, setting remoteUser, etc.
[13:57:00 CST(-0600)] <MarvinAddison> I'd agree.
[13:57:36 CST(-0600)] <apetro> How does Shibboleth solve this problem?
[13:57:50 CST(-0600)] <wgthom> gotta run
[13:57:53 CST(-0600)] <MarvinAddison> afaik, they have avoided single logout like the plague
[13:57:56 CST(-0600)] <MarvinAddison> Later, Bill.
[13:58:20 CST(-0600)] <apetro> Later, wgthom. Looking forward to meeting up at meetup.
[13:59:09 CST(-0600)] <apetro> ok. I forget offhand where Shib is at on single logout. Might be worth looking.
[13:59:36 CST(-0600)] <MarvinAddison> Last I heard they're still saying "it's fundamentally hard and we really recommend you close the browser."
[13:59:47 CST(-0600)] <apetro> well, yes
[13:59:54 CST(-0600)] <apetro> I really recommend you close the browser too
[13:59:58 CST(-0600)] <MarvinAddison> haha
[14:00:04 CST(-0600)] <MarvinAddison> I mean instead of slo.
[14:00:09 CST(-0600)] <apetro> indeed
[14:00:20 CST(-0600)] <MarvinAddison> "We don't support this because you're better off closing your browser."
[14:00:30 CST(-0600)] <apetro> oh, I agree with that too
[14:00:48 CST(-0600)] <apetro> taking another tack, isn't there a spot on the latest FIFER diagrams for a shared Session Service?
[14:00:54 CST(-0600)] <MarvinAddison> One does not win friends, tho, saying it.
[14:01:24 CST(-0600)] <MarvinAddison> I haven't see those.
[14:01:29 CST(-0600)] <MarvinAddison> I'm asking my Shib dev colleague.
[14:02:04 CST(-0600)] <apetro> ok. I don't think that phantom more strategic answer will let CAS off the hook in tactically addressing this, but it might be interesting to articulate the requirement up into FIFER.
[14:02:19 CST(-0600)] <apetro> that if only that service actually existed and was adopted, here's some work we could stop doing.
[14:02:36 CST(-0600)] <apetro> It doesn't really sound like a lot of work, though. Just a matter of time to write working code to implement this.
[14:02:38 CST(-0600)] <MarvinAddison> Ok. Got a link for me?
[14:03:03 CST(-0600)] <apetro> FIFER generally: https://wiki.jasig.org/display/FIFER/Home
[14:03:41 CST(-0600)] <MarvinAddison> Ah. This is OpenRegistry++?
[14:03:48 CST(-0600)] <apetro> Diagram specifically: https://wiki.jasig.org/download/attachments/39257146/IDM+OSS+Reference+Architecture.png
[14:04:03 CST(-0600)] <apetro> I don't think of FIFER as OpenRegistry++
[14:04:17 CST(-0600)] <MarvinAddison> Sounds like it would be a component.
[14:04:22 CST(-0600)] <apetro> OpenRegistry is a concrete open source product for doing user registry stuff
[14:04:39 CST(-0600)] <MarvinAddison> But user (de)provisioning is a huge part of an IDM product.
[14:04:59 CST(-0600)] <apetro> FIFER is an architecture, a vision for mushing open source IdM-related packages together to a complete system, ideally allowing one to avoid proprietary vendor-lockin-inducing crud entirely.
[14:05:21 CST(-0600)] <apetro> (Benn and other FIFER principles would likely cringe at that summary.)
[14:05:52 CST(-0600)] <apetro> yeah
[14:05:54 CST(-0600)] <MarvinAddison> I was thinking it would take and provide at least partial integration of existing Jasig/open source products that do those operations.
[14:06:03 CST(-0600)] <MarvinAddison> We have things that fill some of those boxes.
[14:06:23 CST(-0600)] <MarvinAddison> re Shib, https://spaces.internet2.edu/display/SHIB2/IdP3Details makes no mention.
[14:06:27 CST(-0600)] <apetro> that's this diagram: https://wiki.jasig.org/download/attachments/39257146/IDM+Reference+OSS+Overlay.png
[14:06:45 CST(-0600)] <MarvinAddison> Ah, so there is thinking in that direction.
[14:09:30 CST(-0600)] <apetro> agreed not seeing single log out in Shibboleth
[14:09:43 CST(-0600)] <apetro> too bad, would have been nice to borrow solutions and experiences
[14:10:18 CST(-0600)] <apetro> We're past our hour
[14:10:22 CST(-0600)] <apetro> action items, next steps?
[14:10:41 CST(-0600)] <MarvinAddison> Write some code on things we've already identified as important.
[14:10:48 CST(-0600)] <apetro> sounds like a plan
[14:10:50 CST(-0600)] <MarvinAddison> Ldap pw exp, 114, 142.
[14:10:59 CST(-0600)] <apetro> I do intend to get on top of that password policy extension
[14:11:08 CST(-0600)] <apetro> coming up on the deadline to show progress for Q1, after all
[14:11:15 CST(-0600)] <MarvinAddison> Hopefully we'll be able to recommend code reviews next fri.
[14:11:35 CST(-0600)] <MarvinAddison> Yeah, bout 30 days.
[14:12:00 CST(-0600)] <apetro> figure we should continue that AuthenticationHandler API discussion on the cas-dev thread?
[14:12:24 CST(-0600)] <MarvinAddison> Scott pretty much killed it unless you have further comments that could revive.
[14:12:40 CST(-0600)] <apetro> Yeah, saw that.
[14:12:51 CST(-0600)] <apetro> I'll have to decide if it's important enough to resurrect.
[14:12:52 CST(-0600)] <MarvinAddison> I merged in the X509 handler stuff yesterday and it went ok based on his comments.
[14:13:12 CST(-0600)] <MarvinAddison> So the existing API isn't horrible, but potentially confusing.
[14:13:17 CST(-0600)] <apetro> That's worth a lot, real experience using the API
[14:13:30 CST(-0600)] <MarvinAddison> Clarity matters, just how much?
[14:13:46 CST(-0600)] <apetro> would be interesting to get password policy implemented in trunk, see how well the APIs work for that if if they make any difference at all.
[14:13:50 CST(-0600)] <MarvinAddison> I don't really buy the assertion that some handlers can only do true/false.
[14:14:02 CST(-0600)] <MarvinAddison> Hmm, interesting.
[14:14:13 CST(-0600)] <apetro> And even if they are boolean, they can express that boolean as a richer type
[14:14:32 CST(-0600)] <MarvinAddison> That's good point.
[14:14:54 CST(-0600)] <MarvinAddison> You have more API cred with Scott than I, so maybe it's worth expressing that point.
[14:15:07 CST(-0600)] <apetro> alright
[14:15:17 CST(-0600)] <apetro> you can form your own expectations as to how much time I'll be able to make for that
[14:15:24 CST(-0600)] <apetro> password policy higher on the queue.
[14:15:25 CST(-0600)] <MarvinAddison>
[14:15:52 CST(-0600)] <MarvinAddison> We do what we can. No one expects further.
[14:16:20 CST(-0600)] <apetro> Alright. I'll try to leave my IRC client logged in, and expect to be back for next week's designated dev chat session.
[14:18:31 CST(-0600)] <MarvinAddison> See you then if not sooner.
[14:42:11 CST(-0600)] <battags> hello cas-developers!
[14:42:26 CST(-0600)] <battags> I am out of my horrendously long meeting just in time to apparently miss all the fun conversations
[14:43:19 CST(-0600)] <matt_uconn> nobody here but us lurkers ...
[14:43:22 CST(-0600)] <apetro> greetings battags
[14:44:42 CST(-0600)] <matt_uconn> Hey, everyone have a good weekend. Time to sign off.
[14:44:45 CST(-0600)] <battags> I'm catching up on some of the conversations from before
[14:44:50 CST(-0600)] <battags> have a good weekend!
[14:48:34 CST(-0600)] <MarvinAddison> Closing the barn door after the horses done got out.
[14:48:57 CST(-0600)] <MarvinAddison> (you must say that with a Tennessee drawl, or it doesn't work)
[14:50:09 CST(-0600)] <MarvinAddison> Anyway, if you have any feedback on the clustering disucssion, Scott, speak up.
[14:52:44 CST(-0600)] <battags> my plan is to read the ticket, the thread, and the conversation tonight or tomorrow
[14:53:58 CST(-0600)] <MarvinAddison> Sounds good. Feel free to start a new thread on cas-dev if there's anything worth discussing.
[14:54:53 CST(-0600)] <battags> yeah either way further discussion should be moved there. I think the existing thread was on cas-user ?
[14:55:38 CST(-0600)] <MarvinAddison> Yeah. It started as "you should support this" and quickly got into dev discussion.
[14:56:18 CST(-0600)] <battags> I'd actually rather not support it
[14:56:32 CST(-0600)] <MarvinAddison> Bill had your back on that.
[14:56:34 CST(-0600)] <battags> because the converse is people expect local apps to update the CAS session
[14:56:56 CST(-0600)] <MarvinAddison> God, I hope this feature doesn't add to that morass.
[14:58:55 CST(-0600)] <battags> ha
[14:59:00 CST(-0600)] <battags> off to another meeting
[14:59:05 CST(-0600)] <MarvinAddison> Later.