[09:36:54 CST(-0600)] <battags> good morning!
[09:39:36 CST(-0600)] <wgthom> too early to tell...
[09:56:46 CST(-0600)] <battags> ha
[09:56:51 CST(-0600)] <battags> production issues? 
[09:57:22 CST(-0600)] <wgthom> meeting marathon
[14:02:29 CST(-0600)] <battags> hey marvin thanks for looking into that jira issue about the services management
[14:02:46 CST(-0600)] <MarvinAddison> Sure.
[14:02:52 CST(-0600)] <MarvinAddison> Has it been assigned to me for a while?
[14:04:14 CST(-0600)] <battags> no no I just assigned it to you
[14:04:22 CST(-0600)] <MarvinAddison> Good – I thought I was slacking.
[14:04:33 CST(-0600)] <battags> Its been open for a while because no one else reported it
[14:04:44 CST(-0600)] <battags> and I would imagine it would have created more complaints if it was a real issue
[14:04:50 CST(-0600)] <MarvinAddison> Exactly.
[14:05:05 CST(-0600)] <MarvinAddison> Man, there's a lot of seeming junk in the CAS jira.
[14:05:59 CST(-0600)] <MarvinAddison> At least that was the impression I got when I browsed through last week or so.
[14:09:15 CST(-0600)] <battags> yeah I'm attempting to resolve some of it
[14:09:55 CST(-0600)] <MarvinAddison> Not for the faint of heart 
[14:11:15 CST(-0600)] <battags> oh btw I think I saw in the logs from the developer chat last Friday that I killed the Authenticationhandler discussion. I wasn't intending to kill it. Just pointing out that the AuthenticationManager API wasn't the appropriate API for AuthHandlers
[14:12:36 CST(-0600)] <MarvinAddison> I think that killed the recommendation, though, that AuthManager supersede AuthHandler, which was what Andrew had suggested.
[14:13:04 CST(-0600)] <MarvinAddison> One interface to rule them all was the idea.
[14:13:48 CST(-0600)] <battags> oh I thought there'd be discussion on the Authenticationhandler interface after that
[14:13:50 CST(-0600)] <MarvinAddison> I think there's something to the root of the suggestion, though, that maybe something richer than a boolean return type might be helpful.
[14:14:02 CST(-0600)] <MarvinAddison> See – you were right.
[14:14:39 CST(-0600)] <battags> we started out with true/false because a lot of stuff doesn't do more than that (i.e. the file readers, basic LDAP, etc.)
[14:14:49 CST(-0600)] <battags> out of the box X.509 does more than true/false
[14:14:52 CST(-0600)] <battags> LDAP has the capability
[14:14:58 CST(-0600)] <battags> if we can map vendor specific codes
[14:15:12 CST(-0600)] <battags> which I've attempted to do in CAS4
[14:15:17 CST(-0600)] <battags> though I map them to exceptions to be thrown
[14:15:28 CST(-0600)] <battags> a la Spring's SQLexception translator
[14:15:43 CST(-0600)] <battags> I thought about an Enum instead
[14:15:46 CST(-0600)] <MarvinAddison> But you can't presently indicate more than a single failure reason.
[14:16:01 CST(-0600)] <MarvinAddison> (not sure that'd be needed with just auth, but possibly multifactor, e.g.)
[14:16:10 CST(-0600)] <battags> well the AuthManager
[14:16:13 CST(-0600)] <battags> can aggregate it
[14:16:21 CST(-0600)] <battags> i.e. there is a map of Credential and a List of errors
[14:16:25 CST(-0600)] <MarvinAddison> That makes sense.
[14:16:32 CST(-0600)] <battags> it might not be a list
[14:16:34 CST(-0600)] <battags> I take that back
[14:16:39 CST(-0600)] <MarvinAddison> Each credential would use a different handler I'd imagine.
[14:16:48 CST(-0600)] <MarvinAddison> So that would work.
[14:16:59 CST(-0600)] <battags> so maybe the answer is that the AuthHandler either does nothing or throws an exception?
[14:17:07 CST(-0600)] <battags> which seems a bit wonky
[14:17:07 CST(-0600)] <MarvinAddison> I think that's preferable for sure.
[14:17:19 CST(-0600)] <battags> I can buy into that
[14:17:22 CST(-0600)] <MarvinAddison> Because there's currently ambiguity about what a handler should do.
[14:17:34 CST(-0600)] <battags> we originally had you return true/false if you wanted to try another handler
[14:17:43 CST(-0600)] <MarvinAddison> I know I asked myself that question with the changes to the X509 handler.
[14:17:45 CST(-0600)] <battags> or throw an exception if you wanted to stop the world
[14:17:51 CST(-0600)] <battags> but that changed a bit in CAS4
[14:17:57 CST(-0600)] <MarvinAddison> But AuthManagers should really do that.
[14:18:00 CST(-0600)] <battags> so maybe in CAS4 true/false doesn't make sense any more
[14:18:09 CST(-0600)] <battags> right so the exception indicated to the authentication manager to stop the world
[14:18:19 CST(-0600)] <battags> it was a feedback mechanism
[14:18:26 CST(-0600)] <battags> whether it worked or not is another story
[14:18:38 CST(-0600)] <MarvinAddison> Could easily have "stopOnThrow" flag that would do similar if everything just throws.
[14:19:34 CST(-0600)] <battags> yeah we could do that
[14:19:39 CST(-0600)] <battags> it would be per credential
[14:19:45 CST(-0600)] <battags> since in CAS4 you can pass in multiple credentials
[14:20:14 CST(-0600)] <MarvinAddison> Sounds like it could be useful functionality to preserve.
[14:22:34 CST(-0600)] <battags> okay so I usually make sure to only use exceptions in exceptional cases and not to control flow. So what we're saying is that we consider it an exceptional case when someone's credentials don't work
[14:22:40 CST(-0600)] <battags> just want to make sure that thinking makes sense
[14:23:16 CST(-0600)] <MarvinAddison> Spring Security works exactly that way, so that's a strong precedent.
[14:24:04 CST(-0600)] <MarvinAddison> Also, from my experience looking at prod logs, auth failures are an edge case.
[14:25:56 CST(-0600)] <battags> works for me
[14:26:00 CST(-0600)] <battags> I'm easy to convince sometimes
[14:26:09 CST(-0600)] <MarvinAddison> Good deal.
[14:26:25 CST(-0600)] <battags> too bad Andrew missed all this
[14:26:25 CST(-0600)] <battags> ha
[14:26:38 CST(-0600)] <battags> can we poke him in IRC like Facebook?
[14:26:39 CST(-0600)] <MarvinAddison> Yet right there he sits in the room. Must be tacit approval
[14:27:11 CST(-0600)] <MarvinAddison> Trying private msg...
[14:27:30 CST(-0600)] <battags> if you've got 30 seconds, can you capture this in a JIRA task and assign it to me for 4.0 M1?
[14:27:35 CST(-0600)] <battags> copy/paste of the chat log is probably fine
[14:27:41 CST(-0600)] <MarvinAddison> Will do.
[14:27:49 CST(-0600)] <battags> It might be rather bold to use the Jasig JIRA instance at work
[14:27:58 CST(-0600)] <MarvinAddison> heh
[14:28:05 CST(-0600)] <battags> thanks!
[14:28:24 CST(-0600)] <battags> I might have to unsuscribe to the CAS space
[14:28:33 CST(-0600)] <battags> my blackberry gets like 900 emails once we have a chat here
[14:29:12 CST(-0600)] <MarvinAddison> Can you scope the notices?
[14:30:12 CST(-0600)] <MarvinAddison> https://issues.jasig.org/browse/CAS-956
[14:30:27 CST(-0600)] <battags> you almost got me to click on that at work
[14:30:53 CST(-0600)] <MarvinAddison> Yeah, that was sneaky.
[14:31:01 CST(-0600)] <MarvinAddison> For continuity.
[14:33:02 CST(-0600)] <battags> btw did you see my reply on the cluster single log out ticket?
[14:33:15 CST(-0600)] <MarvinAddison> I did. And I need to think about it.
[14:33:29 CST(-0600)] <MarvinAddison> Think really hard because it's tricky.
[14:33:45 CST(-0600)] <MarvinAddison> The rebroadcast alternative is clear.
[14:33:54 CST(-0600)] <battags> I just thought of third middle ground. We store the stuff in some other storage mechanism and periodically poll to clear out our local mapping
[14:33:56 CST(-0600)] <MarvinAddison> And I really don't like it.
[14:34:02 CST(-0600)] <battags> or we could introduce JMS
[14:34:19 CST(-0600)] <MarvinAddison> marvin runs screaming the other direction.
[14:34:30 CST(-0600)] <battags> who doesn't <3 JMS?
[14:35:26 CST(-0600)] <MarvinAddison> The real problem is looking up a Session to invalidate it given some identifier.
[14:35:42 CST(-0600)] <MarvinAddison> There's no way to do that afaik using servlet apis.
[14:36:32 CST(-0600)] <MarvinAddison> I read your suggestion #2 as storing the entire Session object, correct?
[14:36:57 CST(-0600)] <battags> we can't really do that
[14:37:11 CST(-0600)] <battags> that was not my intention
[14:37:13 CST(-0600)] <battags> to convey that
[14:37:26 CST(-0600)] <MarvinAddison> Ok – I think there'd be problems as well.
[14:37:51 CST(-0600)] <battags> I was merely saying to convey the session id to some flag that said "destroy"
[14:38:04 CST(-0600)] <battags> and that on a request we'd need to check if the session id was in a destory state
[14:38:06 CST(-0600)] <battags> and invalidate it
[14:38:14 CST(-0600)] <battags> not a fan of the check on every request thing though
[14:38:27 CST(-0600)] <battags> I'd almost prefer JMS
[14:38:44 CST(-0600)] <MarvinAddison> Are we expecting that we can say request.getSession() and it will work on any node?
[14:39:15 CST(-0600)] <battags> for which one?
[14:39:36 CST(-0600)] <MarvinAddison> Any.
[14:39:41 CST(-0600)] <MarvinAddison> I have concerns about that.
[14:40:14 CST(-0600)] <battags> when you're in the scope of a request you can ask it for the session
[14:40:28 CST(-0600)] <battags> I'd rather not check each request to see if it should be destroyed
[14:41:08 CST(-0600)] <MarvinAddison> I don't think per-request interrogation is a big deal.
[14:41:29 CST(-0600)] <battags> maybe not
[14:41:40 CST(-0600)] <battags> if you've got a connection pool and a prepared statement
[14:41:42 CST(-0600)] <MarvinAddison> I'm still uncertain whether it's a simple given that any node in the cluster can get the session for a particular user.
[14:42:02 CST(-0600)] <battags> right
[14:42:06 CST(-0600)] <MarvinAddison> I've frankly never done this kind of clustering.
[14:42:20 CST(-0600)] <battags> my assumption here was that you were being sent to the same machine
[14:42:28 CST(-0600)] <battags> via session affinity
[14:42:40 CST(-0600)] <battags> and we just needed to stop someone from using the session
[14:42:45 CST(-0600)] <battags> when they attempted to use it
[14:42:47 CST(-0600)] <MarvinAddison> But the SLO request can't be guaranteed to hit the same node.
[14:42:56 CST(-0600)] <battags> the request no
[14:43:02 CST(-0600)] <battags> but the request can be guaranteed to be put into the db
[14:43:08 CST(-0600)] <battags> and checked when someone comes to the page
[14:43:14 CST(-0600)] <MarvinAddison> Ah, I see.
[14:43:19 CST(-0600)] <battags> not sure if I'm a fan of it
[14:43:25 CST(-0600)] <battags> its liked delayed SLO
[14:44:02 CST(-0600)] <MarvinAddison> This is reducing down to what I recommended to Andrew re https://issues.jasig.org/browse/CASC-114.
[14:44:16 CST(-0600)] <battags> dammit you got me to click
[14:44:17 CST(-0600)] <battags> lol
[14:44:22 CST(-0600)] <MarvinAddison> haha, sry
[14:44:32 CST(-0600)] <MarvinAddison> I should have summarized.
[14:45:07 CST(-0600)] <MarvinAddison> I don't see any alternative to an every-request check. Maybe we can do some optimization?
[14:45:23 CST(-0600)] <battags> I didn't see your recommendation to Andrew in the ticket
[14:45:32 CST(-0600)] <MarvinAddison> i.e. caching, checking every n requests, etc
[14:45:45 CST(-0600)] <MarvinAddison> It was in Friday's dev chat. I never updated the issue.
[14:45:53 CST(-0600)] <battags> oh okay
[14:46:01 CST(-0600)] <battags> I stopped reading once I discovered that I killed a conversation
[14:46:20 CST(-0600)] <MarvinAddison> I sincerely meant no offense.
[14:46:26 CST(-0600)] <battags> haha I'm not offended
[14:46:35 CST(-0600)] <battags> I'm more worried about what other conversations I may have accidentally killed
[14:47:01 CST(-0600)] <battags> but back to SLO
[14:47:40 CST(-0600)] <battags> I'll see Andrew in two weeks at the meet up. Wonder if it makes sense for him and I to white board it out unless you think we need to resolve this more quickly
[14:48:14 CST(-0600)] <MarvinAddison> Nah, but we do need to indicate progress and get back to that cas-user thread in a timely manner.
[14:48:26 CST(-0600)] <MarvinAddison> I'm leaning toward #2 because I detest this rebroadcast solution.
[14:48:35 CST(-0600)] <apetro> delayed single log out, yes, that is what it is. Or maybe "JIT SLO" is a better summary.
[14:48:43 CST(-0600)] <battags> whoa he arrives!
[14:48:55 CST(-0600)] <battags> I think JIT SLO has a better ring to it
[14:48:57 CST(-0600)] <MarvinAddison> I think you just talked me through how #2 could work fine.
[14:49:15 CST(-0600)] <MarvinAddison> It's amazing what good marketing can do.
[14:49:26 CST(-0600)] <battags> the beauty of JIT is that people can choose the mechanism to store the data that works in their environment
[14:49:31 CST(-0600)] <battags> similar to the PGT storage
[14:49:32 CST(-0600)] <apetro> rebroadcast is painful. leaving open the option for someone else to implement a JMS solution is attractive.
[14:49:50 CST(-0600)] <apetro> yes. Similar to PGT storage
[14:49:56 CST(-0600)] <apetro> the insight that this is like ticket registry is a good one/
[14:51:12 CST(-0600)] <MarvinAddison> Would it be possible to consolidate the gist of 114 with this present issue?
[14:51:31 CST(-0600)] <MarvinAddison> e.g. AssertionStorage is the analogy of TicketRegistry.
[14:52:22 CST(-0600)] <battags> are we saying AssertionStorage is for the purposes of SLO?
[14:52:27 CST(-0600)] <battags> err JIT SLO
[14:52:35 CST(-0600)] <MarvinAddison> One of its purposes, yes.
[14:52:39 CST(-0600)] <MarvinAddison> But it could have others.
[14:53:00 CST(-0600)] <battags> so I don't know if I quite agree with that statement
[14:53:04 CST(-0600)] <battags> I'd have to think about it
[14:53:13 CST(-0600)] <battags> to quote you, think hard
[14:53:19 CST(-0600)] <MarvinAddison> heh
[14:53:26 CST(-0600)] <MarvinAddison> In one sentence:
[14:53:30 CST(-0600)] <battags> I got the quotation wrong
[14:53:30 CST(-0600)] <battags> ha
[14:54:10 CST(-0600)] <MarvinAddison> AssertionStorage maintains the CAS client authenticated state.
[14:54:26 CST(-0600)] <MarvinAddison> To kill an entry there is to log out.
[14:54:53 CST(-0600)] <MarvinAddison> I recall from previous discussion you didn't like moving authenticated state away from the Session.
[14:55:03 CST(-0600)] <MarvinAddison> But you could use a similar next-request-kills session approach.
[14:55:28 CST(-0600)] <apetro> maybe it's next-request-optionally-kills-session-or-otherwise-fires-event?
[14:55:43 CST(-0600)] <MarvinAddison> fires event is for e.g. JMS?
[14:55:59 CST(-0600)] <battags> so even if you have assertionstorage the key has to be stored in the session which didn't give me any good incentive to put the assertion anywhere else
[14:56:04 CST(-0600)] <apetro> I hate to make things harder than it ever had to be, but there are plenty of weakly-authenticated use cases out there where the application remembers who you were even tho you're no longer authenticated
[14:56:06 CST(-0600)] <battags> unless we're saying the key is the session
[14:56:22 CST(-0600)] <battags> session id*
[14:56:47 CST(-0600)] <apetro> I suppose the key has to be the session ID, yes
[14:56:58 CST(-0600)] <battags> regardless our assertionstorage would have to allow you to use the session for storage
[14:57:02 CST(-0600)] <battags> even if its not the only option
[14:57:04 CST(-0600)] <MarvinAddison> You cold store the key in a cookie.
[14:57:56 CST(-0600)] <apetro> and thereby re-invent sessions?
[14:57:59 CST(-0600)] <MarvinAddison> Sure, SessionAssertionStorage puts it in the session.
General
Content
Integrations