Page Comparison

[13:05:19 CST(-0600)] <MarvinAddison> Welcome CAS developers – all 2 of us.
[13:05:22 CST(-0600)] <AndrewPetro> Greetings, programmers.
[13:05:49 CST(-0600)] <AndrewPetro> It's a fine start for what I expect will be a valuable ongoing resource.
[13:05:52 CST(-0600)] <MarvinAddison> I was hoping to briefly discuss 3.4.6 release schedule and had a 4.0 api question.
[13:06:29 CST(-0600)] <MarvinAddison> Hopefully Scott will show up since his input is vital to both.
[13:06:44 CST(-0600)] <MarvinAddison> Anything on your mind, Andrew?
[13:06:51 CST(-0600)] <AndrewPetro> Cool. I'd like to express intent to heat up efforts on productizing the password policy extension over the next 5 weeks or so.
[13:07:30 CST(-0600)] <AndrewPetro> And I'd also like to nuance how we intend to use this chat room, that certainly there are these scheduled times for dev discussion, but really the room exists ongoingly and would be a fine place to hang out.
[13:07:48 CST(-0600)] <MarvinAddison> That's my understanding.
[13:07:51 CST(-0600)] <AndrewPetro> (Did that post come through cut off like it looks in my terminal?)
[13:08:07 CST(-0600)] <MarvinAddison> Reads complete to me.
[13:08:16 CST(-0600)] <AndrewPetro> Great. Local weirdness.
[13:08:22 CST(-0600)] <MarvinAddison> re password policy...
[13:08:42 CST(-0600)] <MarvinAddison> I'd like to see an OpenLdap ppolicy-based implementation.
[13:09:13 CST(-0600)] <AndrewPetro> That sounds lovely. I'd like to see it factored as a minimally invasive plugin to the existing CAS release.
[13:09:22 CST(-0600)] <MarvinAddison> Between the existing AD solution and a ppolicy solution, I'm hopeful we can develop an API that could be used for policies on arbitrary ldap server platforms.
[13:09:25 CST(-0600)] <AndrewPetro> Not incompatible goals, but a difference of emphasis, perhaps.
[13:09:46 CST(-0600)] <MarvinAddison> Not incompatible at all.
[13:09:47 CST(-0600)] <AndrewPetro> I'd really like it to be more general than LDAP
[13:10:15 CST(-0600)] <MarvinAddison> That's fine, but it will be important to manage dependencies sanely in that case.
[13:10:20 CST(-0600)] <AndrewPetro> Both AD and OpenLDAP are what people would really use, and I owe it more of a code sketch, but offhand it seems very desirable to make the API more general.
[13:10:40 CST(-0600)] <MarvinAddison> I think generality is good, and doable as well.
[13:10:49 CST(-0600)] <AndrewPetro> Alright
[13:10:58 CST(-0600)] <MarvinAddison> Is the existing code in Jasig sandbox yet?
[13:11:06 CST(-0600)] <AndrewPetro> so it sounds mostly a matter of marshalling effort to do the code sketch
[13:11:07 CST(-0600)] <MarvinAddison> Once it gets there, it's rubber-hits-road.
[13:11:21 CST(-0600)] <AndrewPetro> not that I know of, I haven't pulled it there yet, so it would have had to have been someone other than me if it's gotten done.
[13:11:31 CST(-0600)] <MarvinAddison> Not me.
[13:11:37 CST(-0600)] <MarvinAddison> Probably not done yet.
[13:12:10 CST(-0600)] <MarvinAddison> I'd recommend the "branches are disposable" approach to this.
[13:12:31 CST(-0600)] <AndrewPetro> Especially in sandbox, yes.
[13:13:31 CST(-0600)] <MarvinAddison> I don't have any concrete API ideas yet, but working on the ppolicy stuff should be sufficiently different from what's there that it may help stimulate ideas. I like to get concrete in any case.
[13:13:53 CST(-0600)] <AndrewPetro> What's your motivation in advocating for OpenLDAP impl? Local use cases driving that? To the point of resources to sketch the OpenLDAP impl?
[13:14:11 CST(-0600)] <MarvinAddison> We have a lot of OpenLDAP expertise here and the resources to test it.
[13:14:22 CST(-0600)] <AndrewPetro> Excellent.
[13:14:24 CST(-0600)] <MarvinAddison> Not sure if we'd use it, but we might someday.
[13:14:44 CST(-0600)] <MarvinAddison> The ancillary reason is it's what the "other half" uses aside from AD.
[13:15:03 CST(-0600)] <MarvinAddison> Figure we cover lots of ground, as you noted, with both.
[13:15:07 CST(-0600)] <AndrewPetro> Yes. Agree it's the right products to be supporting from a cas-as--product perspective.
[13:15:53 CST(-0600)] <MarvinAddison> I'll make some time to work on this next week.
[13:16:03 CST(-0600)] <MarvinAddison> If it's not in sandbox by that time, I'll dump it in.
[13:16:13 CST(-0600)] <AndrewPetro> I'll make a real effort to beat you to that.
[13:16:17 CST(-0600)] <MarvinAddison>
[13:17:07 CST(-0600)] <MarvinAddison> I just pinged scott on gtalk. We'll see if that helps.
[13:17:18 CST(-0600)] <MarvinAddison> Is that it for password policy?
[13:17:22 CST(-0600)] <AndrewPetro> Ok. I'm feeling good about the password policy item.
[13:17:26 CST(-0600)] <AndrewPetro> Just a matter of applying efforts.
[13:17:32 CST(-0600)] <MarvinAddison> Sounds like it.
[13:17:46 CST(-0600)] <AndrewPetro> Next steps are disposable code sketches in sandbox (leading to non-disposable worthwhile results, of course)
[13:17:59 CST(-0600)] <AndrewPetro> with active discussion on cas-dev
[13:18:09 CST(-0600)] <AndrewPetro> and followup on that thread on cas-user about this
[13:18:18 CST(-0600)] <MarvinAddison> That sounds like a concrete action plan to me.
[13:18:26 CST(-0600)] <AndrewPetro> there was talk there about more ambitious code, I believe I solicited that source and didn't hear, can poke again.
[13:18:45 CST(-0600)] <MarvinAddison> "ambitious"?
[13:18:45 CST(-0600)] <AndrewPetro> as in, someone fixed issues and implemented more features beyond policy enforcement
[13:18:56 CST(-0600)] <MarvinAddison> I don't recall that.
[13:19:22 CST(-0600)] <MarvinAddison> Always shocks me when folks fix but don't share.
[13:19:42 CST(-0600)] <MarvinAddison> I know it takes more effort, but it's pretty marginal.
[13:20:05 CST(-0600)] <AndrewPetro> Yeah. We haven't put our best foot forward here though.
[13:20:17 CST(-0600)] <AndrewPetro> Which is going to be a lot of the upside of getting it into source control and more formalized.
[13:20:33 CST(-0600)] <MarvinAddison> Agreed.
[13:20:46 CST(-0600)] <AndrewPetro> I don't see the email offhand. Will happily keep looking if we're still waiting for Scott, otherwise will have to follow up post-chat.
[13:21:04 CST(-0600)] <MarvinAddison> Have you looked at 4.0 apis?
[13:21:13 CST(-0600)] <AndrewPetro> Not seriously
[13:21:22 CST(-0600)] <MarvinAddison> You have source available now?
[13:21:37 CST(-0600)] <AndrewPetro> but I do want to make looking at how to achieve this same password policy in 4 another outcome of my effort on the extension for present CAS
[13:21:57 CST(-0600)] <AndrewPetro> I'll have no problem with zero of the present-generation extension code being reusable, so long as the use case can otherwise be met in 4.
[13:22:10 CST(-0600)] <AndrewPetro> I do have CAS 4 trunk avail, yes.
[13:22:43 CST(-0600)] <MarvinAddison> re code reuse, I think we should focus on the existing 3.4.x apis to get something working.
[13:22:55 CST(-0600)] <MarvinAddison> Which is to basically agree with what you said, I believe.
[13:23:03 CST(-0600)] <AndrewPetro> Exactly
[13:23:16 CST(-0600)] <MarvinAddison> Trying to abstract to both apis is likely going to be a non-starter, and a time sink besides.
[13:23:26 CST(-0600)] <AndrewPetro> Agreed.
[13:23:47 CST(-0600)] <MarvinAddison> I have a philosophical comment about the AuthenticationHandler interface in 4.0.
[13:23:55 CST(-0600)] <MarvinAddison> comment/question
[13:24:04 CST(-0600)] <MarvinAddison> boolean authenticate(Credential credentials) throws GeneralSecurityException;
[13:24:13 CST(-0600)] <MarvinAddison> Is confusing.
[13:24:41 CST(-0600)] <AndrewPetro> https://source.jasig.org/cas4/trunk/cas-server-api/src/main/java/org/jasig/cas/server/authentication/AuthenticationHandler.java for those following from home
[13:25:07 CST(-0600)] <AndrewPetro> yeah
[13:25:08 CST(-0600)] <MarvinAddison> seems you should either not throw in any security-related conditions and return false, or otherwise return void and throw GeneralSecurityException on security failures. but not both
[13:25:19 CST(-0600)] <AndrewPetro> that's painfully confusing
[13:25:27 CST(-0600)] <AndrewPetro> I agree philosophically troubling
[13:25:37 CST(-0600)] <MarvinAddison> As it is I'm not sure what to do with some changes I have to merge into the X.509 handler.
[13:25:54 CST(-0600)] <AndrewPetro> Not sure I'm sold on modeling the failure as an exception in the first place
[13:26:04 CST(-0600)] <MarvinAddison> I like it very much.
[13:26:29 CST(-0600)] <MarvinAddison> It allows the handler to decide to fail on a number of interesting conditions.
[13:26:29 CST(-0600)] <AndrewPetro> Because of downstream framework support for flow/UX routing based on the exception?
[13:26:44 CST(-0600)] <MarvinAddison> boolean is too narrow a result
[13:26:55 CST(-0600)] <AndrewPetro> Ah. Yes. I'm definitely agreed that boolean is unhelpful
[13:26:56 CST(-0600)] <MarvinAddison> If there were a complex type for the result, that would be fine.
[13:27:27 CST(-0600)] <AndrewPetro> I'm wondering whether the API should be returning a complex type, yes, a domain object designed to represent AuthenticationAttemptResult or the like
[13:27:28 CST(-0600)] <MarvinAddison> But the use of GeneralSecurityException in the signature suggests that authentication failures should result in throw.
[13:27:32 CST(-0600)] <AndrewPetro> ideally with a less hideous name.
[13:28:24 CST(-0600)] <AndrewPetro> ok
[13:28:35 CST(-0600)] <MarvinAddison> There is AuthenticationRequest/Response.
[13:29:01 CST(-0600)] <AndrewPetro> maybe the most interesting philosophical question is whether there's potentially something bigger than one bit to say about a success.
[13:29:32 CST(-0600)] <AndrewPetro> (like, say, your attempt succeeded but your password is going to expire soon. )
[13:29:36 CST(-0600)] <MarvinAddison> I think both success and failure are potentially interesting events where you'd like a lot of room to be descriptive.
[13:29:59 CST(-0600)] <MarvinAddison> There is support for that kind of thing at a higher level – LoginRequest/Response.
[13:30:12 CST(-0600)] <AndrewPetro> ok
[13:30:14 CST(-0600)] <AndrewPetro> yes, I see that
[13:30:18 CST(-0600)] <MarvinAddison> Pretty sure that has the messaging functionality to support cases like password exp.
[13:30:29 CST(-0600)] <AndrewPetro> indeed
[13:30:30 CST(-0600)] <MarvinAddison> I'm fairly hazy, myself, on some of these.
[13:30:34 CST(-0600)] <AndrewPetro> looks like that's at the AuthenticationManager level
[13:30:49 CST(-0600)] <AndrewPetro> as in, AuthenticationManager consumes AuthenticationRequest, returns AuthenticationResponse
[13:31:06 CST(-0600)] <AndrewPetro> maybe we should be asking if there needs to be an API other than AuthenticationManager?
[13:31:16 CST(-0600)] <MarvinAddison> See LoginResponse#getAuthenticationWarnings()
[13:31:31 CST(-0600)] <AndrewPetro> that is, just write AuthenticationManagers and remove AuthenticationHandler from the API entirely?
[13:31:52 CST(-0600)] <MarvinAddison> I think we still need them both.
[13:32:00 CST(-0600)] <MarvinAddison> The manager wires together multiple handlers.
[13:32:14 CST(-0600)] <MarvinAddison> The handlers is where all the strategy-specific details live.
[13:32:45 CST(-0600)] <MarvinAddison> The manager is where you do fast-fail, map-based, etc, logic.
[13:33:33 CST(-0600)] <AndrewPetro> You wouldn't rather have a Manager that wires together multiple Managers?
[13:33:55 CST(-0600)] <MarvinAddison> Interesting.
[13:34:02 CST(-0600)] <AndrewPetro> I guess I'm worried the Handler API is anemic in the way we identified
[13:34:07 CST(-0600)] <AndrewPetro> one solution is to use a richer API
[13:34:21 CST(-0600)] <AndrewPetro> hey look! AuthenticationManager is a richer but in-the-same-vein API
[13:34:31 CST(-0600)] <MarvinAddison> haha
[13:34:52 CST(-0600)] <MarvinAddison> There's definitely a reason Scott chose to use GeneralSecurityException on the auth signature.
[13:34:57 CST(-0600)] <MarvinAddison> Can't remember exactly what it is.
[13:35:04 CST(-0600)] <AndrewPetro> Ok.
[13:35:04 CST(-0600)] <MarvinAddison> JAAS?
[13:35:12 CST(-0600)] <AndrewPetro> Dunno.
[13:35:14 CST(-0600)] <MarvinAddison> That's a bad reason off the top of my head, tho.
[13:35:16 CST(-0600)] <AndrewPetro> This conversation certainly needs Scott
[13:35:22 CST(-0600)] <MarvinAddison> But your point is definitely noted.
[13:35:30 CST(-0600)] <AndrewPetro> maybe we've identified a topic to thread on cas-dev?
[13:35:49 CST(-0600)] <MarvinAddison> I really want this dev chat session to include API discussions. So I'm happy it has already started.
[13:36:03 CST(-0600)] <AndrewPetro> ok
[13:36:11 CST(-0600)] <AndrewPetro> I'm game to discuss, but I can't presume to represent Scott
[13:36:28 CST(-0600)] <MarvinAddison> To actually answer the question, tho, we should probably put on the list where Scott can answer at his convenience.
[13:36:31 CST(-0600)] <AndrewPetro> and if I get you to volunteer to start that thread on cas-dev, I'll buy myself another couple minutes to beat you to dealing with the sandbox source
[13:36:50 CST(-0600)] <MarvinAddison> We can cite the logs in the posting.
[13:36:58 CST(-0600)] <AndrewPetro> Yes. Should.
[13:37:11 CST(-0600)] <MarvinAddison> Here goes...
[13:38:31 CST(-0600)] <AndrewPetro> Doing your action items while still in the chat session? That's so cheating.
[13:39:00 CST(-0600)] <MarvinAddison> I call it efficiency.
[13:39:14 CST(-0600)] <MarvinAddison> But if you have something else to discuss, I can hold up.
[13:39:20 CST(-0600)] <AndrewPetro> Yeah. The more I think about this, the more passionate I'm getting about advocating for all AuthenticationHandlers simply being AuthenticationManagers
[13:39:47 CST(-0600)] <MarvinAddison> It's an interesting idea, certainly.
[13:41:00 CST(-0600)] <AndrewPetro> It attempts to address some awkwardness we've actually experienced with the CAS 3 APIs, possibly attribute collection?
[13:42:07 CST(-0600)] <MarvinAddison> The only downside is that it would be a bigger API change. There are lots of handlers whose signatures would change significantly.
[13:42:28 CST(-0600)] <AndrewPetro> yes
[13:42:38 CST(-0600)] <AndrewPetro> but if the API changes at all, that's most of the work
[13:42:48 CST(-0600)] <AndrewPetro> suppose an adapter to the old API is feasible?
[13:42:59 CST(-0600)] <MarvinAddison> Could be, yeah.
[13:43:15 CST(-0600)] <MarvinAddison> I'd have to think a little harder, but sounds feasible at face value.
[13:43:20 CST(-0600)] <AndrewPetro> if CAS4 doesn't have an AuthenticationHandler, might even be appropriate to keep around exactly the CAS3 AuthenticationHandler, marked @deprecated, and ship an AuthenticationManager adapter to it
[13:45:26 CST(-0600)] <MarvinAddison> Deprecation is the nice way to handle huge API changes, so I like it.
[13:45:40 CST(-0600)] <AndrewPetro> yeah
[13:45:45 CST(-0600)] <AndrewPetro> offhand it feels right.
[13:45:46 CST(-0600)] <MarvinAddison> "This is not the right way to do this, but it'll still work for a while."
[13:46:11 CST(-0600)] <AndrewPetro> keeping around all the old APIs would be annoying, but if we hand-pick those that will be the very most annoying to update, like this one, that may improve the upgrade experience a lot.
[13:47:16 CST(-0600)] <MarvinAddison> Handlers are one of the components users configure most, so it's certainly liable to special treatment.
[13:47:47 CST(-0600)] <AndrewPetro> as long we we're talking about this
[13:47:59 CST(-0600)] <AndrewPetro> it's probably worth looking at that API through the lens of
[13:48:09 CST(-0600)] <AndrewPetro> what's it look like to build a web-based, live configurable implementation of it
[13:48:44 CST(-0600)] <MarvinAddison> Not sure I follow.
[13:48:59 CST(-0600)] <AndrewPetro> so it might be worth at least considering adding annoyances like getDisplayName()
[13:49:13 CST(-0600)] <AndrewPetro> one of the biggest complaints about CAS is having to edit those Spring XML files
[13:49:31 CST(-0600)] <MarvinAddison> Ah, I see where you're going.
[13:49:34 CST(-0600)] <AndrewPetro> what if one were to write the DynamicallyConfiguredAuthenticationManager
[13:49:42 CST(-0600)] <AndrewPetro> which, I dunno, looked up its configuration in a database or something
[13:49:43 CST(-0600)] <AndrewPetro> that's fine
[13:49:48 CST(-0600)] <AndrewPetro> I can certainly write one of those to this API
[13:50:01 CST(-0600)] <AndrewPetro> but then, thinking about the thankless task of implementing that thing
[13:50:19 CST(-0600)] <AndrewPetro> what does it want to consume out of the AuthenticationManager API that would allow that UI to be, well, usable?
[13:51:37 CST(-0600)] <AndrewPetro> Could deal with that with wrappers and adornments later, tho
[13:51:51 CST(-0600)] <AndrewPetro> most AuthenticationManagers will have rich dependencies needing custom UIs for configuration anyway
[13:52:14 CST(-0600)] <MarvinAddison> Certainly.
[13:52:32 CST(-0600)] <AndrewPetro> (as in, needing those rich UIs if we got to a configured-via-browser world; not needing those APIs so long as we're all willing to edit Spring bean XML via my favorite UI ever, gedit.)
[13:52:34 CST(-0600)] <MarvinAddison> I was thinking a component that does everything would require both an insane component and insane UI.
[13:53:02 CST(-0600)] <MarvinAddison> "favorite UI ever, gedit" – haha
[13:53:09 CST(-0600)] <MarvinAddison> vim ftw!
[13:53:21 CST(-0600)] <MarvinAddison> Certainly stretching the definition of UI.
[13:53:49 CST(-0600)] <AndrewPetro> vim's good for the brain
[13:54:03 CST(-0600)] <AndrewPetro> a general-case configurable-through-browser UI might be hard, I agree
[13:54:07 CST(-0600)] <AndrewPetro> perhaps a CAS 5 requirement
[13:54:17 CST(-0600)] <MarvinAddison> It's a noble goal in any case.
[13:54:33 CST(-0600)] <AndrewPetro> a specific-constrained-cases configurable through browser AuthenticationManager ought to be doable writing to CAS 4 APIs and doing a traditional overlay
[13:54:43 CST(-0600)] <AndrewPetro> or else we've not designed the APIs properly
[13:54:48 CST(-0600)] <AndrewPetro> I'll stick my neck out and posit