Page Comparison

[13:03:28 CST(-0600)] <apetro__> Greetings Programmers.
[13:04:12 CST(-0600)] <wgthom> checking in
[13:07:02 CST(-0600)] <apetro> likewise checking in
[13:10:09 CST(-0600)] <apetro> I did draw the password policy code into Jasig sandbox source control since last cas-dev IRC chat, so I wish MarvinAddison were here for wooting purposes. https://source.jasig.org/sandbox/cas-password-policy/
[13:10:57 CST(-0600)] <wgthom> I don't give a woot!?!?
[13:13:47 CST(-0600)] <apetro> You do, but you haven't asked about the task as many times as he has.
[13:14:14 CST(-0600)] <wgthom> i'm sure I do...poor attempt at humor
[13:14:28 CST(-0600)] <apetro> Anyway, that progress, and then direct followup with historical participants in that extension has unearthed additional code, so some progress there.
[13:19:07 CST(-0600)] <MarvinAddison> hey
[13:19:11 CST(-0600)] <MarvinAddison> woot
[13:19:17 CST(-0600)] <apetro>
[13:19:55 CST(-0600)] <MarvinAddison> Which "historical participants"?
[13:20:43 CST(-0600)] <apetro> Andrew Tillinghast from Connecticut College, who replied to my reaching out with updated source code
[13:20:52 CST(-0600)] <apetro> and Eric Pierce from USF, original poster of the extension
[13:21:01 CST(-0600)] <MarvinAddison> Ah, see those messages now.
[13:21:36 CST(-0600)] <apetro> they're the two people who had edited/posted to that wiki page regarding the extension, so I figured they deserved my reaching out directly to let them know of intent and solicit participation
[13:21:53 CST(-0600)] <MarvinAddison> Good thinking.
[13:22:09 CST(-0600)] <MarvinAddison> Does it build cleanly? Deploy?
[13:22:35 CST(-0600)] <apetro> the fixed additional code sent via email? Haven't tried yet.
[13:22:59 CST(-0600)] <apetro> The code that's in SVN so far? No, unless I'm missing something important, but that's after all part of the impetus for the productization project
[13:24:21 CST(-0600)] <battags> hey!
[13:24:27 CST(-0600)] <battags> glad you all check your IMS :-p
[13:24:43 CST(-0600)] <wgthom> battaglia in the house.
[13:24:44 CST(-0600)] <MarvinAddison> Hey Scott – glad you made it.
[13:24:57 CST(-0600)] <battags> Web Chat and I fought
[13:24:59 CST(-0600)] <battags> I won this time
[13:25:09 CST(-0600)] <MarvinAddison> Yeah, saw your note.
[13:25:44 CST(-0600)] <battags> Andrew saw you sandboxed the code (woot!)
[13:25:50 CST(-0600)] <MarvinAddison> Andrew, I see that trunk of pwexp module is empty. What's the plan?
[13:26:05 CST(-0600)] <battags> do we need to go to Incubation?
[13:26:25 CST(-0600)] <MarvinAddison> I think we're going to work out some stuff in sandbox, then head that route.
[13:26:28 CST(-0600)] <apetro> My next move is to triage among the available code, put some reasonable starting point in /trunk, and iterate on it
[13:26:36 CST(-0600)] <MarvinAddison> Sounds good.
[13:27:32 CST(-0600)] <MarvinAddison> Just realized the title of your email, Andrew: "birthing CAS password policy extension module into Jasig SVN"
[13:27:34 CST(-0600)] <MarvinAddison> Love it.
[13:28:09 CST(-0600)] <apetro> birthing living projects rather than just contributing code snapshots, as it were
[13:28:22 CST(-0600)] <apetro> not that sharing code snapshots isn't a totally welcome starting point
[13:28:51 CST(-0600)] <MarvinAddison> Right on.
[13:29:15 CST(-0600)] <apetro> re Incubation, I guess I am interested in the JIRA issue tracker that Incubation could afford, but otherwise I see no hurry.
[13:29:31 CST(-0600)] <apetro> Immediate term even the issue tracker won't add much value, till a starting point stabilizes in sandbox
[13:29:51 CST(-0600)] <MarvinAddison> No hurry, but it's one specific direction for formalization.
[13:30:07 CST(-0600)] <MarvinAddison> Another possibility is a cas-server integration module.
[13:30:57 CST(-0600)] <MarvinAddison> Actually it might be helpful to discuss whether we envision this remaining a standalone project, or ever becoming part of cas-server proper.
[13:31:06 CST(-0600)] <apetro> Yes.
[13:31:22 CST(-0600)] <apetro> I definitely envision the part of cas-server proper endgame
[13:32:08 CST(-0600)] <MarvinAddison> I think it's perfectly justifiable if we assume or have evidence that it would be widely used/useful.
[13:32:09 CST(-0600)] <apetro> but am open to a couple paths to that, as a well-factored extension ala ClearPass for CAS 3, perhaps, and as more in-built in CAS 4.
[13:33:03 CST(-0600)] <apetro> Yes. Especially if we succeed in making it broader than just LDAP, there are several references of existing CAS adopters who have had this use case bad enough to customize CAS to meet it.
[13:33:57 CST(-0600)] <apetro> at the least, Connecticut and USF on record via that wiki page, the folks who participated in that cas-user thread incuding SacState
[13:34:26 CST(-0600)] <MarvinAddison> If it starts to creep toward multiple backends, then it certainly would make sense to be more tightly integrated in the server sourcebase since we already have integration modules for various backends auth systems.
[13:34:48 CST(-0600)] <apetro> I think we could convince ourselves that it would be widely used and useful, and that adopters increasingly expect password policy enforcement out of their Web SSO solution.
[13:35:00 CST(-0600)] <MarvinAddison> I think that's reasonable.
[13:35:09 CST(-0600)] <MarvinAddison> Password expiration comes up frequently on cas-user.
[13:35:46 CST(-0600)] <battags> CAS4 supports converting LDAP error codes to exceptions
[13:35:56 CST(-0600)] <battags> right now it only supports Microsoft AD
[13:36:31 CST(-0600)] <MarvinAddison> We could probably develop something similar for the Jdbc auth handler.
[13:36:35 CST(-0600)] <MarvinAddison> conceptually similar
[13:36:50 CST(-0600)] <apetro> yes
[13:37:02 CST(-0600)] <battags> https://source.jasig.org/cas3/trunk/cas-server-support-ldap/src/main/java/org/jasig/cas/server/authentication/GeneralSecurityExceptionTranslator.java
[13:37:09 CST(-0600)] <MarvinAddison> The handler would be responsible for throwing exceptions on certain cases, then the CAS4 plumbing would handle accordingly.
[13:37:18 CST(-0600)] <battags> https://source.jasig.org/cas3/trunk/cas-server-support-ldap/src/main/java/org/jasig/cas/server/authentication/MicrosoftActiveDirectoryGeneralSecurityExceptionTranslator.java
[13:37:19 CST(-0600)] <apetro> also need to handle case where authentication succeeds but password will expire "soon" and need to advise user of this unhappy fact
[13:37:30 CST(-0600)] <battags> that is available in CAS4 also
[13:37:32 CST(-0600)] <MarvinAddison> Optionally handle, yes.
[13:37:51 CST(-0600)] <apetro> ok
[13:37:59 CST(-0600)] <battags> https://source.jasig.org/cas3/trunk/cas-server-api/src/main/java/org/jasig/cas/server/authentication/MessageResolver.java
[13:38:03 CST(-0600)] <MarvinAddison> I believe warnings are much harder to handle generally.
[13:38:11 CST(-0600)] <MarvinAddison> Not sure if OpenLDAP ppolicy supports that.
[13:38:16 CST(-0600)] <apetro> sounds like a two pronged approach: articulate how this is solved in CAS 4, ideally shipping with viable example configuration and the relevant user experiences/flows
[13:38:27 CST(-0600)] <apetro> and factor extension module to address use case in cas3
[13:38:50 CST(-0600)] <MarvinAddison> For now we should focus on #3 since the API is fixed.
[13:38:59 CST(-0600)] <MarvinAddison> #2==cas3 I mean
[13:39:13 CST(-0600)] <apetro> seems like it's sometimes custom stuff anyway, driving the "your password will expire soon" use case
[13:39:36 CST(-0600)] <MarvinAddison> It certainly is in our case at present – I just finished implementing this stuff for VT.
[13:39:39 CST(-0600)] <apetro> so having flow support for it with a pluggable API for CAS to determine whether a given account is afflicted could scratch the itch