jasig-cas IRC Logs-2011-11-25

Owned by Apereo Infrastructure
Last updated: Nov 25, 2011Version comment
10 min read

[10:32:44 CST(-0600)] <ries> Cool I have CASified Jahia (smile)

[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 (wink)

[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> (wink)

[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 (wink)

[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 (wink)

[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 (wink)

[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 (wink)

[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.

[14:19:05 CST(-0600)] <battags> unfortunately her job doesn't require a whiteboard

[14:19:13 CST(-0600)] <serac> I can imagine.

[14:19:16 CST(-0600)] <serac> Can we continue later?

[14:19:24 CST(-0600)] <serac> Or another day? Time is up for me now.

[14:19:24 CST(-0600)] <battags> I'd have to counter-offer with like a CAT scan machine

[14:19:29 CST(-0600)] <serac> haha

[14:19:40 CST(-0600)] <battags> I'll be around sporadically on Saturday and Sunday

[14:19:42 CST(-0600)] <battags> more so on Sunday

[14:19:51 CST(-0600)] <battags> but if you IM me, I now have IRC on my phone (wink)

[14:19:57 CST(-0600)] <serac> Ok, sounds good.

[14:20:08 CST(-0600)] <battags> talk to you later! have a good weekend

[14:20:23 CST(-0600)] <serac> I'll try to hook up with you sometime. You too. Pax.