Page Comparison

[12:41:42 CDT(-0500)] <apetro> thesaint, what compile error are you getting?
[13:00:09 CDT(-0500)] <wgthom1> checking in
[13:00:51 CDT(-0500)] <apetro> checking in likewise
[13:01:22 CDT(-0500)] <wgthom1> hi scott
[13:04:57 CDT(-0500)] <battags> hey
[13:05:00 CDT(-0500)] <battags> you added a 1 to your name
[13:05:09 CDT(-0500)] <wgthom1> any shaking today?
[13:06:24 CDT(-0500)] <serac> Checking in.
[13:06:33 CDT(-0500)] <wgthom1> hi marvin
[13:06:38 CDT(-0500)] <serac> s'up
[13:08:32 CDT(-0500)] <serac> Bill, have you done any research to get a sense of what's needed for the ppolicy integration?
[13:08:42 CDT(-0500)] <wgthom1> on going
[13:08:54 CDT(-0500)] <serac> It was my understanding you'd have to develop a custom LDAP control.
[13:09:00 CDT(-0500)] <serac> With DER encoding and all.
[13:09:16 CDT(-0500)] <serac> (limited understanding, admittedly)
[13:09:17 CDT(-0500)] <wgthom1> going against AD
[13:09:52 CDT(-0500)] <wgthom1> i've go the password warn behavior working.
[13:09:56 CDT(-0500)] <wgthom1> i've got
[13:10:04 CDT(-0500)] <wgthom1> need to exercise the rest
[13:10:09 CDT(-0500)] <wgthom1> still
[13:10:10 CDT(-0500)] <serac> ack
[13:10:15 CDT(-0500)] <apetro> exciting stuff
[13:10:42 CDT(-0500)] <apetro> code's needed some, um, tweaking, but it's been good to collaborate on it
[13:10:43 CDT(-0500)] <serac> I know folks are interested, so it's good.
[13:11:36 CDT(-0500)] <wgthom1> yes, at a glance there are some rough edges and probably needs a good refactoring.. right now I'm still understanding what's there and how it plugs in
[13:11:51 CDT(-0500)] <wgthom1> the folk of CASImp and BindauthNH need to be resolved
[13:11:54 CDT(-0500)] <wgthom1> the fork
[13:12:21 CDT(-0500)] <wgthom1> and possible some of the swf could be merged into existing actions
[13:12:29 CDT(-0500)] <serac> I'll try to review diffs this weekend.
[13:12:29 CDT(-0500)] <wgthom1> not totally sure yet
[13:12:44 CDT(-0500)] <wgthom1> i'll get a status out the end of the day
[13:12:45 CDT(-0500)] <serac> The CASImpl changes are somewhat concerning, the auth handler changes less so.
[13:13:10 CDT(-0500)] <wgthom1> yes, it's one method to get the Principal...maybe there's a better way to do that
[13:13:22 CDT(-0500)] <wgthom1> called from swf action
[13:13:23 CDT(-0500)] <serac> But that's all sight unseen, so probably should keep my mouth shut until I review.
[13:13:32 CDT(-0500)] <wgthom1>
[13:14:45 CDT(-0500)] <serac> In terms of developing a plan for incorporating this into core, I'd like to gauge interest in AD-only support.
[13:14:58 CDT(-0500)] <wgthom1> at a minimum I'd like to get to 1. apply patch to local cas server source, 2. local mvn install, 3, maven overay build, 4. good to go.
[13:14:59 CDT(-0500)] <serac> Personally I think it's a bad idea until it becomes a generalized framework.
[13:15:27 CDT(-0500)] <serac> i.e. pluggable for arbitrary authentication handlers.
[13:16:10 CDT(-0500)] <wgthom1> then we can think about refactoring, etc.
[13:16:22 CDT(-0500)] <serac> But if the community is excited about AD-only support, I'd take that seriously.
[13:17:16 CDT(-0500)] <wgthom1> i think the code will work against Sun LDAP (is that still available), but I haven't tried it.
[13:17:28 CDT(-0500)] <serac> It's got Oracle in the name now
[13:17:32 CDT(-0500)] <serac>
[13:17:57 CDT(-0500)] <wgthom1> well at least they haven't killed it off yet
[13:18:07 CDT(-0500)] <wgthom1> a slow painful death perhaps
[13:18:09 CDT(-0500)] <apetro> seems there's two goals here. 1) Make the existing-feasible AD password policy integration technology easy to adopt with existing CAS release, and 2) refactor, improve, extend, and consider for mainlining as part of a CAS 3.5 release.
[13:18:11 CDT(-0500)] <serac> They won't kill anything that provides a revenue stream.
[13:18:39 CDT(-0500)] <wgthom1> lol. Oracle the new CA
[13:18:47 CDT(-0500)] <serac> indeed
[13:18:48 CDT(-0500)] <wgthom1> where software goes to die
[13:19:19 CDT(-0500)] <apetro> I was toying with some kind of "Build Community Not Yachts" tagline the other day...
[13:19:26 CDT(-0500)] <wgthom1> apetro: yes with #1 the immediate need for Lamar University
[13:20:01 CDT(-0500)] <wgthom1> need to make this more of a real extentions and less just a code dump
[13:20:42 CDT(-0500)] <serac> A code dump is fine for something that interested parties will sweat over as an extension.
[13:21:03 CDT(-0500)] <wgthom1> yes, preferably in snv were collaboratino can take place
[13:21:41 CDT(-0500)] <serac> But it should have clearly-defined API for extension in order for consideration to merge into core.
[13:22:04 CDT(-0500)] <apetro> sustainability. Living code. Maintenance path. I'm all for all of it. Makes the most of Lamar's / coop dev cas's efforts in contribution to CAS community and in Lamar's / subscriber's interests. Insert cheerleading here.
[13:22:37 CDT(-0500)] <serac> I must admit I'm a little uncomfortable talking so much about Unicon driving forces for this development.
[13:22:56 CDT(-0500)] <apetro> Certainly inclusion into core needs to be earned. The operative words here are collaboration, exploratory.
[13:23:01 CDT(-0500)] <serac> I realize it may be generally useful and you guys are moving it toward that end. And that's enough to get excited about for me.
[13:23:10 CDT(-0500)] <wgthom1> http://www.youtube.com/watch?v=cXRWQa9tQLw
[13:23:31 CDT(-0500)] <serac> haha
[13:23:41 CDT(-0500)] <apetro> Real actual CAS adopter Lamar is an important player here too, albeit in part via engaging Unicon.
[13:24:03 CDT(-0500)] <wgthom1> yes, lamar is the driving force....not unicon. unicon is partner to lamar.
[13:24:23 CDT(-0500)] <battags> inclusion in core must include a sustainable path for support
[13:24:25 CDT(-0500)] <wgthom1> highed ed is the driving force behind coop dev
[13:24:34 CDT(-0500)] <apetro> This isn't code that originated with Unicon. The extent of code dumping and of adopters implementing this in spite of the impediments have been significant. I see Unicon as more doing cleanup than innovation here, not to take anything away from wgthom's excellent efforts.
[13:24:47 CDT(-0500)] <serac> I'll take you at your word that's the case.
[13:25:18 CDT(-0500)] <battags> any talk of inclusion has to reconcile the differences without 4.0 is looking at solving the problem
[13:25:27 CDT(-0500)] <battags> that should read with*
[13:25:31 CDT(-0500)] <battags> I apparently can't type
[13:25:35 CDT(-0500)] <serac> I'm willing to consider the maintenance burden as part of maintaining LDAP integration components. With caveats of course.
[13:26:11 CDT(-0500)] <serac> +1 to Scott's point about considering the existing solution in 4.0.
[13:26:27 CDT(-0500)] <serac> At least being familiar with it so not to reinvent wheels.
[13:34:21 CDT(-0500)] <apetro> k. Does that CAS 4 approach bear discussion here, or are we leaving it an asynchronous exercise?
[13:35:00 CDT(-0500)] <serac> I was imagining the latter, but Scott may want to comment.
[13:35:36 CDT(-0500)] <wgthom1> it would be good to get a status as to where things stand
[13:35:48 CDT(-0500)] <wgthom1> at this point the development is all scott?
[13:36:21 CDT(-0500)] <battags> that framework is already coded
[13:36:35 CDT(-0500)] <battags> it just needs plugins for the various LDAP servers
[13:36:47 CDT(-0500)] <battags> we'd probably also ned to look at the other policy support that you guys were talking about
[13:36:57 CDT(-0500)] <battags> but it works as part of the authentication handler
[13:38:28 CDT(-0500)] <wgthom1> "that framework" meaning the support password policy?
[13:38:52 CDT(-0500)] <battags> the framework for translating the LDAP errors into usable exceptions to pass back up
[13:39:09 CDT(-0500)] <wgthom1> can you point to that in svn?
[13:39:17 CDT(-0500)] <battags> its part of the LDAP support
[13:39:41 CDT(-0500)] <wgthom1> perhaps that can be merged into cas3 solution
[13:41:14 CDT(-0500)]

 <apetro>  if (namingException != null && namingException instanceof AuthenticationException) {             throw getGeneralSecurityExceptionTranslator().translateExceptionIfPossible((AuthenticationException) namingException);         }