[10:32:44 CST(-0600)] <ries> Cool I have CASified Jahia 
[13:04:55 CST(-0600)] <serac> It's dev chat hour.
[13:05:21 CST(-0600)] <serac> We discussed on cas-dev on Tues/Wed that we'd be discussing lppe today.
[13:06:11 CST(-0600)] <serac> Guess we didn't agree on the 2-3pm slot, but was what I was thinking.
[13:08:07 CST(-0600)] <serac> Hey battags.
[13:08:36 CST(-0600)] <battags> hey. sorry for the delay. no one sounded like they would really be on
[13:09:01 CST(-0600)] <battags> IRC on the phone. so responses may be slow and autocorrected
[13:09:29 CST(-0600)] <serac> May be hard.
[13:09:52 CST(-0600)] <battags> it autocorrected my password 3 times.
[13:09:57 CST(-0600)] <battags> lol
[13:09:57 CST(-0600)] <serac> haha
[13:11:41 CST(-0600)] <battags> are there any good docs on the ldap policy stuff?
[13:11:55 CST(-0600)] <serac> afaik it's code only
[13:11:58 CST(-0600)] <serac> Reviewing now...
[13:12:02 CST(-0600)] <battags> not sure if I've ever seen how the responses would be returned.
[13:12:37 CST(-0600)] <serac> Wish atilling or wgthom were here to field these questions.
[13:15:24 CST(-0600)] <battags> have they implemented the policy support. I though they just did exceptions.
[13:16:21 CST(-0600)] <serac> No ppolicy yet.
[13:16:26 CST(-0600)] <serac> The core component is PasswordChecker.
[13:16:41 CST(-0600)] <serac> Sorry, org.jasig.cas.authentication.PasswordWarningCheck.
[13:16:51 CST(-0600)] <serac> /**
[13:16:51 CST(-0600)] <serac> * @param userID The unique ID of the user
[13:16:51 CST(-0600)] <serac> * @return Code for this status
[13:16:51 CST(-0600)] <serac> */
[13:16:51 CST(-0600)] <serac> public int getPasswordWarning(String userID);
[13:16:58 CST(-0600)] <serac> That's pretty generic, which is good.
[13:17:03 CST(-0600)] <serac> Should support ppolicy fine.
[13:17:27 CST(-0600)] <serac> The idea here afaik is that you do a separate bind and in the case of AD translate the exception.
[13:17:39 CST(-0600)] <serac> For ppolicy you'd bind and parse the PPolicy response control.
[13:17:57 CST(-0600)] <serac> So I think this framework can be used as-is for the ppolicy use case, at least at first glance.
[13:19:14 CST(-0600)] <Masterious> hmmm'
[13:19:15 CST(-0600)] <battags> I'm only interested in how ppolicy works. we haven't committed to that implementation. no one bothered to compare to the CAS4 apis yet.
[13:19:51 CST(-0600)] <serac> Ppolicy setup in JNDI is fairly involved — stuff I'd never seen before.
[13:19:58 CST(-0600)] <Masterious> what are you discussing guys?
[13:20:15 CST(-0600)] <serac> What we mentioned on cas-dev Tues/Wed: lppe.
[13:20:16 CST(-0600)] <Masterious> may i join it?
[13:20:31 CST(-0600)] <serac> If you know anything about either CAS or ppolicy, yes.
[13:21:09 CST(-0600)] <serac> Anyway the setup for JNDI involves setting some environment stuff, catching a NamingException, then getting the response controls as a byte array and parsing it.
[13:21:21 CST(-0600)] <serac> Raymond from ASU mentioned something about support for ppolicy in spring security.
[13:21:27 CST(-0600)] <serac> battags — know anything about that?
[13:21:49 CST(-0600)] <battags> not off the top of my head but I can check it out.
[13:22:04 CST(-0600)] <battags> I hope it ties in with spring ldap
[13:22:08 CST(-0600)] <serac> I was surprised by his comments.
[13:22:23 CST(-0600)] <serac> Cuz I was not aware there were hooks for any of this stuff in spring-ldap.
[13:22:38 CST(-0600)] <serac> I'm thinking if it exists, must build on top of spring-ldap.
[13:23:24 CST(-0600)] <battags> spring security might have had their support before spring ldap was around.
[13:23:38 CST(-0600)] <serac> At first glance looks like this is entirely specific to spring-sec.
[13:23:44 CST(-0600)] <serac> http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/ldap/ppolicy/package-summary.html
[13:24:21 CST(-0600)] <serac> I'm concerned about building on top of this for CAS.
[13:25:49 CST(-0600)] <serac> Specifically, concerned about sucking in all of spring-sec for something ldap specific.
[13:26:18 CST(-0600)] <battags> we already have it as a dependency for webapp
[13:26:49 CST(-0600)] <serac> For service manager only, correct?
[13:28:30 CST(-0600)] <battags> yeah.
[13:28:51 CST(-0600)] <serac> I suppose we can debate implementation details at a future date.
[13:29:26 CST(-0600)] <serac> I think this makes it clear there's a reasonable API for doing ppolicy in CAS. We can table whether to use it or roll our own for a future discussion.
[13:29:40 CST(-0600)] <battags> at a minimum the code will tell us what needs to be done.
[13:30:34 CST(-0600)] <serac> I think what we'd need to do specifically will be driven by the library we use.
[13:30:56 CST(-0600)] <serac> If we go the spring-sec route, looks like we'd need to use a custom context source, which I could foresee as problematic.
[13:31:48 CST(-0600)] <serac> Problematic more for deployers I suppose than for devs, but problematic nonetheless.
[13:31:48 CST(-0600)] <battags> I me
[13:32:01 CST(-0600)] <battags> hit enter accidentally
[13:32:07 CST(-0600)] <serac> np
[13:32:11 CST(-0600)] <serac> Damn mobile devices.
[13:32:50 CST(-0600)] <battags> let me read through the code later. we may just be able to use underlying parts and write a better abstraction on top.
[13:33:05 CST(-0600)] <serac> ack
[13:33:37 CST(-0600)] <battags> we also need to reconcile the two different CAS apis
[13:33:42 CST(-0600)] <serac> My assessment of current feature-lppe branch is that it would support ppolicy.
[13:33:53 CST(-0600)] <serac> I'm reviewing cas4 api now to try to do same eval.
[13:34:35 CST(-0600)] <battags> I don't mean whether it would support it or not
[13:34:43 CST(-0600)] <serac> I know what you mean.
[13:35:03 CST(-0600)] <battags> I specifically didn't use the other API because it didn't integrate well
[13:35:15 CST(-0600)] <battags> it was a good start
[13:35:40 CST(-0600)] <battags> but it suffered from not working with someone who can modify core 
[13:36:26 CST(-0600)] <serac> We're going to have to modify some existing components either way to add this support.
[13:38:07 CST(-0600)] <serac> What's the core API component for mapping exceptions in cas4 api?
[13:38:53 CST(-0600)] <battags> there is a translator right now that works with spring ldap
[13:39:08 CST(-0600)] <battags> I don't know its name off the top of my head.
[13:40:32 CST(-0600)] <serac> It's coming back to me now. One sec...
[13:41:39 CST(-0600)] <serac> GeneralSecurityExceptionTranslator
[13:43:23 CST(-0600)] <serac> Here's the obstacle with this component in regard to ppolicy?
[13:43:25 CST(-0600)] <serac> :
[13:43:35 CST(-0600)] <battags> I'm going to switch to a real computer in about two minutes
[13:43:36 CST(-0600)] <serac> the exception doesn't contain all the information about the problem.
[13:43:44 CST(-0600)] <serac> I'll just wait till then.
[13:44:54 CST(-0600)] <battags> thanks Haha
[13:45:00 CST(-0600)] <serac>
[13:47:24 CST(-0600)] <battags> I'm on a real computer now
[13:47:33 CST(-0600)] <serac> Sure you'll have more to say now
[13:47:33 CST(-0600)] <battags> let me bring up the spring security docs
[13:47:37 CST(-0600)] <serac> Sure.
[13:48:14 CST(-0600)] <battags> so my first thought: my vision is not for LDAP policy support. its for CAS policy support
[13:48:20 CST(-0600)] <battags> so we're working with two levels
[13:48:25 CST(-0600)] <battags> the CAS abstraction
[13:48:32 CST(-0600)] <serac> Sure.
[13:48:32 CST(-0600)] <battags> and the way each authentication mechanism maps to that abstraction
[13:48:35 CST(-0600)] <battags> beyond just LDAP
[13:48:39 CST(-0600)] <serac> I'm on board with that.
[13:48:54 CST(-0600)] <battags> unfortunately the mapping per authentication mechanism is super specific to that mechanism
[13:48:55 CST(-0600)] <battags> bleh
[13:49:13 CST(-0600)] <serac> If we had to pick a single API I'd go with exception translation.
[13:49:33 CST(-0600)] <serac> We could always wrap the NamingException in something else that encapsulated the ppolicy data.
[13:50:20 CST(-0600)] <serac> And if we can do that for this specific use case, we could handle other mechanisms.
[13:51:07 CST(-0600)] <battags> it just looks like the Spring Security stuff binds as the user to get the policy info
[13:51:12 CST(-0600)] <battags> and they just do it in the context
[13:51:19 CST(-0600)] <battags> we could do it outside the context, right?
[13:52:23 CST(-0600)] <serac> Strictly speaking, yes.
[13:52:34 CST(-0600)] <serac> Though I'm not certain we can do this (easily) with spring-ldap components.
[13:53:51 CST(-0600)] <battags> Spring Security uses Spring LDAP so it may not be super-hard
[13:54:03 CST(-0600)] <serac> I'm reading spring-ldap now.
[13:54:11 CST(-0600)] <serac> Think I'm in agreement on that evaluation.
[13:54:24 CST(-0600)] <battags> I'm more concerned that it looks like the integration/modifications to the authentication handlers
[13:54:30 CST(-0600)] <serac> You get a standard DirContext, which is the central actor.
[13:54:31 CST(-0600)] <battags> might be a bit more involved/deeper
[13:55:19 CST(-0600)] <battags> we need to retrieve the policy regardless of whether an exception was thrown or not
[13:55:29 CST(-0600)] <serac> That's correct.
[13:55:36 CST(-0600)] <battags> wait so two questions
[13:55:40 CST(-0600)] <serac> The throw case is easy.
[13:55:43 CST(-0600)] <battags> actually it might only be one
[13:55:59 CST(-0600)] <battags> does password policy support come into play when its things like account locked?
[13:56:05 CST(-0600)] <serac> Yes.
[13:56:29 CST(-0600)] <battags> so what happens? the bind fails but the policy info is returned?
[13:56:34 CST(-0600)] <serac> Good question.
[13:56:44 CST(-0600)] <serac> I'm not entirely certain what happens on all platforms.
[13:56:53 CST(-0600)] <serac> I can speak to OpenLDAP, which is hopefully our primary use case.
[13:57:06 CST(-0600)] <battags> we'll speak for whichever ones people are willing to implement
[13:57:09 CST(-0600)] <serac> After your password expires, you get N grace logins where bind succeeds.
[13:57:12 CST(-0600)] <battags> which at the moment is OpenLDAP
[13:57:42 CST(-0600)] <serac> Any bind with graceLogins=0 fails and the error code for the ppolicy control is set to the cause enum value.
[13:58:09 CST(-0600)] <serac> You can also get into a case where excessive unsuccessful binds will cause the locked condition.
[13:58:24 CST(-0600)] <serac> Where bind also fails in a similar fashion, but with a different enum value.
[13:58:42 CST(-0600)] <battags> so no exception but a failed find
[13:58:43 CST(-0600)] <serac> So binds always fail in the error cases.
[13:58:44 CST(-0600)] <battags> bind*
[13:58:48 CST(-0600)] <battags> and then we need to read the policy stuff
[13:58:55 CST(-0600)] <serac> JNDI treats bind failure as NamingException.
[13:59:09 CST(-0600)] <battags> but the naming exception wouldn't have all the policy info in it?
[13:59:12 CST(-0600)] <serac> So you catch the exception and read the response controls.
[13:59:16 CST(-0600)] <serac> No.
[13:59:28 CST(-0600)] <serac> The DirContext is the link to the response controls.
[14:00:14 CST(-0600)] <serac> The NamingException in the case of OpenLDAP is pretty generic: error 49 (invalid credentials).
[14:01:47 CST(-0600)] <serac> Although I should note that OpenLDAP can be customized to provide some additional information in the error string. I believe it's either straightforward or commonplace to do that, but additional work nonetheless.
[14:03:23 CST(-0600)] <battags> I was hoping the AuthenticationErrorCallback would give us a good handle on the DirContext
[14:03:29 CST(-0600)] <battags> it does not
[14:04:42 CST(-0600)] <battags> though we can modify the ldap authentication handler to pass it in to the exception translator
[14:05:11 CST(-0600)] <battags> would that allow us to extract the policy?
[14:05:57 CST(-0600)] <serac> Let's clarify something first:
[14:06:10 CST(-0600)] <serac> we're still trying to have any eye toward generalizing this for all handlers, right?
[14:07:14 CST(-0600)] <battags> yes, but there are two levels. There is actually the CAS part which is completely generic, and the part that each handler must do to translate to the generic support
[14:07:25 CST(-0600)] <serac> Sure.
[14:07:31 CST(-0600)] <battags> the generic support is basically the exception heirarchy
[14:07:35 CST(-0600)] <serac> This may be a good use case for generics.
[14:07:49 CST(-0600)] <serac> Where there some contextual type T that would be DirContext for LDAP.
[14:07:56 CST(-0600)] <serac> Maybe something else for JDBC, etc.
[14:08:02 CST(-0600)] <serac> Connection maybe?
[14:08:31 CST(-0600)] <battags> possibly though I wasn't overly concerned it each handler extracted/translated using the same API
[14:08:36 CST(-0600)] <battags> I just wanted the end result to be generic
[14:08:48 CST(-0600)] <serac> I like a single API.
[14:08:58 CST(-0600)] <battags> single APIs work for me
[14:09:05 CST(-0600)] <battags> maybe we can even get it to work with AOP
[14:09:06 CST(-0600)] <serac> Ideally it's a natural extension of the authentication handler APIs.
[14:09:26 CST(-0600)] <serac> We need to also keep in mind cases that are effectively warnings.
[14:09:49 CST(-0600)] <battags> well so currently warnings and actual exceptions are treated differently
[14:09:53 CST(-0600)] <serac> Where authentication succeeds but there is contextual information about authenticated state that needs to be caputred.
[14:09:57 CST(-0600)] <battags> they get triggered in two different parts of the CAS4 API
[14:10:09 CST(-0600)] <serac> Messages and Exceptions, right?
[14:10:21 CST(-0600)] <battags> someone read the API, woohoo!
[14:10:22 CST(-0600)] <battags> :-p
[14:10:32 CST(-0600)] <serac> I've definitely spent some time on it.
[14:10:45 CST(-0600)] <serac> Here we should probably be specific: warning and error.
[14:11:11 CST(-0600)] <serac> Warning is a case where auth succeeds but has information to present to user and error is failed auth that could be represented as exception.
[14:11:34 CST(-0600)] <serac> I'm really just advocating for calling it a warning in this case.
[14:11:50 CST(-0600)] <serac> Impending password expiration is a known use case.
[14:11:54 CST(-0600)] <serac> Dunno about others.
[14:12:19 CST(-0600)] <battags> that sounds fine
[14:12:30 CST(-0600)] <battags> I called it messages in the API because sometimes people display other crap
[14:12:43 CST(-0600)] <battags> not specific to the user
[14:13:53 CST(-0600)] <serac> Sure, so we could use the Message type here, but the method should be getWarnings() or similar.
[14:15:01 CST(-0600)] <serac> Big question: how pass warnings back from authentication handlers with existing api?
[14:15:12 CST(-0600)] <serac> Exceptions are pretty clear; warnings no so much.
[14:16:18 CST(-0600)] <battags> its why there was a generic API for messages because it seemed rather difficult to do it in the authenticationhandler
[14:16:31 CST(-0600)] <battags> though modifying existing APIs might get us in trouble
[14:16:40 CST(-0600)] <serac> It will be a roadblock.
[14:16:59 CST(-0600)] <battags> I'd rather make sure we do this support right the first time
[14:17:05 CST(-0600)] <battags> even if it does mean modifying APIs
[14:17:10 CST(-0600)] <serac> I'm totally open.
[14:17:56 CST(-0600)] <serac> We should anticipate making a strong argument for this.
[14:18:00 CST(-0600)] <battags> this is where co-located design sessions would come in handy
[14:18:16 CST(-0600)] <serac> But folks want LPPE, so maybe we can use that as a concrete feature to justify some API changes.
[14:18:23 CST(-0600)] <battags> I'm trying to convince my wife we should install a really big whiteboard in the house
[14:18:34 CST(-0600)] <serac> I won that one for about 6 months.
[14:18:39 CST(-0600)] <serac> Then wife won.