jasig-cas IRC Logs-2011-10-07

Owned by Apereo Infrastructure
Last updated: Oct 07, 2011Version comment
11 min read

[08:24:40 CDT(-0500)] <kickehy> could the reason that my ldap bind isn't working is because if force ssl on tomcat but don't force ldaps://

[09:57:28 CDT(-0500)] <serac> You listening Eric?

[11:02:54 CDT(-0500)] <foxnesn1> happy friday

[11:03:18 CDT(-0500)] <foxnesn1> is there any easy way to setup a forward url to test out CAS?

[11:03:32 CDT(-0500)] <foxnesn1> right now i have the basic authenticator which includes a login/pass

[11:03:52 CDT(-0500)] <serac> "forward url"?

[11:03:59 CDT(-0500)] <foxnesn1> i would just like to set this test up so that it can forward to our app

[11:04:17 CDT(-0500)] <foxnesn1> yea, is that in pom.xml or in the deployer?

[11:05:06 CDT(-0500)] <serac> You want to test CAS via some client application? Still trying to understand.

[11:05:36 CDT(-0500)] <foxnesn1> sorry. yea, i go to the cas login page and when i enter credentials is imply says you are logged in

[11:05:51 CDT(-0500)] <serac> Need to set up a client.

[11:05:57 CDT(-0500)] <serac> Which one you'd use is up to you.

[11:06:08 CDT(-0500)] <foxnesn1> a cas client?

[11:06:12 CDT(-0500)] <serac> If you have a PHP environment, phpCAS is easiest to set up.

[11:06:38 CDT(-0500)] <serac> https://wiki.jasig.org/display/CASC/Home

[11:08:08 CDT(-0500)] <foxnesn1> i thought that was what the cas server was for...now im confused lol

[11:10:12 CDT(-0500)] <foxnesn1> im reading through the docs and it doesnt actually say what a cas client does compared to the cas server

[11:49:06 CDT(-0500)] <kickehy> foxnesn1: have you delved into the ldap docs yet?

[11:59:06 CDT(-0500)] <foxnesn1> not yet

[11:59:14 CDT(-0500)] <foxnesn1> im still working on our password self service solution

[11:59:45 CDT(-0500)] <foxnesn1> which is just supposed to act as a middleman IF the user needs to update their password and setup their challenge responses

[12:08:48 CDT(-0500)] <foxnesn1> dont most people run cas transparently, meaning users dont know cas is authenticating them?

[12:32:52 CDT(-0500)] <serac> No.

[12:33:21 CDT(-0500)] <serac> The whole point is that there is a single trusted source for authentication that is CAS, although it may be branded as something else by the institution/enterprise.

[12:40:58 CDT(-0500)] <foxnesn1> so the cas/login page would be a substitute for a gateway login?

[12:51:41 CDT(-0500)] <serac> Yes.

[12:56:37 CDT(-0500)] <foxnesn1> well that is eyeopening. thanks for your help

[13:02:37 CDT(-0500)] <apetro> checking in

[13:02:46 CDT(-0500)] <serac> here

[13:03:21 CDT(-0500)] <apetro> foxnesn1 , for a narrow understanding of "gateway", CAS does have a relevant feature for picking up transparent authentication where it can be achieved.

[13:04:21 CDT(-0500)] <battags> hello

[13:04:37 CDT(-0500)] <apetro> but in general, yes, I agree with serac, users are supposed to experience and value their enterprise login and so the branding of "Log in with CAS" (or "Log in with BearID" or however it's been branded) and the centralized login experience is ideally adding value.

[13:04:53 CDT(-0500)] <apetro> greetings, battags

[13:05:47 CDT(-0500)] <apetro> I suspect wgthom is not joining today, what with his travel for Internet2 member meeting and so forth.

[13:05:52 CDT(-0500)] <apetro> Agenda bash?

[13:06:00 CDT(-0500)] <serac> hey battags

[13:06:16 CDT(-0500)] <serac> I have one item: get 3.4.11 RC out today.

[13:06:45 CDT(-0500)] <apetro> a laudable goal

[13:06:52 CDT(-0500)] <apetro> 3.4.11 RC1. Anything else?

[13:07:29 CDT(-0500)] <apetro> Alright, let's talk 3.4.11 RC1 and then re-bash.

[13:07:44 CDT(-0500)] <serac> I'd like to merge in the JPA fix today, then cut release.

[13:07:46 CDT(-0500)] <serac> Any concerns?

[13:08:21 CDT(-0500)] <serac> It would require a mandatory one-line change for deployers.

[13:08:32 CDT(-0500)] <serac> The value of the fix seems well worth that.

[13:08:34 CDT(-0500)] <battags> I have an issue that I need to resolve over teh weekend

[13:08:35 CDT(-0500)] <apetro> Sounds fine to me. Cutting an RC with it should be a good way to ship the code to cause more review / trying out.

[13:08:39 CDT(-0500)] <battags> the*

[13:08:43 CDT(-0500)] <battags> so I am not a go for a RC today

[13:08:51 CDT(-0500)] <serac> Ok.

[13:08:59 CDT(-0500)] <serac> Cut upon completion if your issue?

[13:09:04 CDT(-0500)] <serac> s/if/of

[13:09:08 CDT(-0500)] <battags> yeah

[13:09:17 CDT(-0500)] <battags> are all other issues closed?

[13:09:21 CDT(-0500)] <battags> err resolved?

[13:09:30 CDT(-0500)] <serac> I'll close 1051 upon merging in after dev chat.

[13:10:07 CDT(-0500)] <apetro> battags, what's the other issue that you intend to address this weekend, or do I not want to ask?

[13:10:28 CDT(-0500)] <battags> fix for inspektr and then an inspektr upgrade for us

[13:10:40 CDT(-0500)] <battags> inspektr JDBC audit trail manager affects correct shutdown

[13:10:44 CDT(-0500)] <battags> because of its thread

[13:10:50 CDT(-0500)] <apetro> yup

[13:11:02 CDT(-0500)] <serac> Speaking of...

[13:11:06 CDT(-0500)] <battags> it should be a quick fix

[13:11:09 CDT(-0500)] <battags> speaking of?

[13:11:13 CDT(-0500)] <battags> weekends?

[13:11:13 CDT(-0500)] <serac> I've been on users@tomcat for about a month now.

[13:11:32 CDT(-0500)] <battags> is that a good or a bad thing? (wink)

[13:11:35 CDT(-0500)] <serac> I've read some fairly provocative notes about "proper" thread management that I was totally unaware of.

[13:11:56 CDT(-0500)] <serac> I'll dig the one up in particular. Worth sharing.

[13:12:17 CDT(-0500)] <battags> yeah I'm curious about it

[13:12:49 CDT(-0500)] <serac> I'm not saying no one here has heard of this stuff. I surely hadn't is all.

[13:13:54 CDT(-0500)] <serac> I'll just quote Mark Thomas from the thread:

[13:13:56 CDT(-0500)] <serac> That is asking for a memory leak. There is a simple rule for correctly

[13:13:56 CDT(-0500)] <serac> using a ThreadLocal in a web application.

[13:13:56 CDT(-0500)] <serac> The ThreadLocal must be removed from the thread before the

[13:13:56 CDT(-0500)] <serac> request/response in which it was created completes processing.

[13:14:13 CDT(-0500)] <serac> never heard that before

[13:14:56 CDT(-0500)] <serac> also can't say I understand it

[13:15:23 CDT(-0500)] <apetro> Interesting.

[13:15:28 CDT(-0500)] <serac> Indeed.

[13:15:30 CDT(-0500)] <apetro> stuff worth discussing on cas-dev@ ?

[13:16:14 CDT(-0500)] <serac> I think we've got to try to understand why it's a best practice first. I was too bashful to speak up on that thread, but it's worth bringing up again.

[13:17:01 CDT(-0500)] <apetro> k.

[13:17:07 CDT(-0500)] <apetro> anything else?

[13:17:16 CDT(-0500)] <serac> Here's the thread for context: http://comments.gmane.org/gmane.comp.jakarta.tomcat.user/215139.

[13:17:36 CDT(-0500)] <serac> Yes, one other thing for me.

[13:17:45 CDT(-0500)] <battags> typically for threadlocal you clean it up in the filter

[13:18:11 CDT(-0500)] <serac> The issue about FastBind handler today on cas-user.

[13:18:37 CDT(-0500)] <serac> I spoke with my colleague Daniel about that one. He's got the most JNDI+LDAP experience of anyone I know and he was surprised.

[13:19:01 CDT(-0500)] <serac> Now may be a good time to start leaning on spring-ldap to implement pooling of authenticated connections in PooledContextSource.

[13:19:48 CDT(-0500)] <serac> It's more or less a workaround for that particular fellow's issue, but sure would be generally beneficial. The TLS session cost is most of the cost of a bind operation, so saving that would be substantial.

[13:20:50 CDT(-0500)] <apetro> how to go about that leaning? Is there a Spring JIRA that needs voted on / commented on / something?

[13:21:12 CDT(-0500)] <serac> In my experience they are very slow to implement substantial features.

[13:21:24 CDT(-0500)] <serac> But since Eric is the author of that class, we may have some leverage for sooner than later.

[13:23:44 CDT(-0500)] <apetro> Other stuff: I have little/no incremental progress on manual, been distracted doing other stuff, but intend to loop back to that, and ClearPass maintenance, promptly.

[13:24:06 CDT(-0500)] <serac> On ClearPass....

[13:24:24 CDT(-0500)] <serac> It's on the roadmap. Are we in agreement on that?

[13:24:29 CDT(-0500)] <serac> If not what are concerns?

[13:26:01 CDT(-0500)] <apetro> I think we're in agreement on that. Pull in valuable feature, reduce adopter integration pain, ease ongoing maintenance. Off by default to reduce security concerns. So, I like the roadmap. (smile)

[13:27:30 CDT(-0500)] <serac> battags?

[13:29:37 CDT(-0500)] <battags> I'm currently not in agreement on it

[13:29:48 CDT(-0500)] <serac> Let's talk it out.

[13:31:03 CDT(-0500)] <battags> (a) I'm not sure I'm comfortable with it included in a security product and (b) its been slightly neglected in terms of maintenance (which if that gets resolved which it seems like it might be then we can remove that concern)

[13:31:18 CDT(-0500)] <battags> I'm also not sure we have an idea of how many people actually use it

[13:31:27 CDT(-0500)] <battags> as a total percentage of Maven2 downloads it wasn't very large

[13:31:32 CDT(-0500)] <battags> but then I'm not sure that's a valuable sample

[13:31:33 CDT(-0500)] <battags> (smile)

[13:31:54 CDT(-0500)] <serac> I'd like to propose the following assumption for the roadmap:

[13:32:08 CDT(-0500)] <serac> If you've got your name on a piece of functionality, you also own the maintenance.

[13:32:41 CDT(-0500)] <serac> So that means Andrew owns both initial inclusion and maintenance.

[13:32:51 CDT(-0500)] <serac> Does that make you feel any better?

[13:35:19 CDT(-0500)] <battags> on the maintenance issue, sure.

[13:35:33 CDT(-0500)] <serac> Good. Making progress.

[13:35:53 CDT(-0500)] <battags> well so its important that Andrew agrees to that also (smile)

[13:35:54 CDT(-0500)] <serac> I think your concerns about security are justifiable.

[13:36:01 CDT(-0500)] <apetro> (for reference, this previous discussion looks relevant https://wiki.jasig.org/display/CAS/jasig-cas+IRC+Logs-2011-06-17 )

[13:36:34 CDT(-0500)] <apetro> yes, Unicon continues to own maintenance of ClearPass.

[13:36:45 CDT(-0500)] <serac> I'm saying you personally own it.

[13:36:54 CDT(-0500)] <serac> Your name is on the roadmap as developer.

[13:36:59 CDT(-0500)] <serac> We need responsible parties.

[13:37:43 CDT(-0500)] <serac> I know Unicon could conceivably be a responsible party, but for CAS it's better to have individuals IMO.

[13:38:10 CDT(-0500)] <apetro> it's always individuals. I'm the currently tasked individual. My name's on it.

[13:38:25 CDT(-0500)] <serac> I'm just sayin'.

[13:38:49 CDT(-0500)] <serac> So you own it until you delegate to someone else.

[13:39:19 CDT(-0500)] <apetro> Indeed. I own ClearPass.

[13:39:46 CDT(-0500)] <serac> Andrew, what do you say to Scott's concern about the apparent contradiction of ClearPass in CAS?

[13:41:16 CDT(-0500)] <apetro> I'd say I think there's more value in making it more feasible to implement ClearPass correctly to as securely as possible do what it does than there is in keeping that functionality out of the product.

[13:41:30 CDT(-0500)] <battags> curious: are we looking to pull ClearPass in because of its slight maintenance burden w/ each upgrade or because we think it should be included in CAS

[13:41:33 CDT(-0500)] <apetro> That having it off by default (for a strong meaning of off) is sufficient to address the security concern.

[13:42:24 CDT(-0500)] <serac> Seems it's about easing both developer/maint burden and deployer burden.

[13:42:41 CDT(-0500)] <apetro> I'm more concerned about the implementation burden than the maintenance burden, but yes, it eases both, and yes, I think that regardless of that the feature is valid and necessary.

[13:42:51 CDT(-0500)] <apetro> In practice, adopters are using it.

[13:43:00 CDT(-0500)] <apetro> Pepperdine. Sac State.

[13:43:20 CDT(-0500)] <apetro> Let's make their lives easier and court continued / increased involvement.

[13:43:48 CDT(-0500)] <apetro> Manchester.

[13:43:53 CDT(-0500)] <serac> Security question aside, this seems perfectly in line with our practice of pulling in stuff that folks use.

[13:43:55 CDT(-0500)] <apetro> Suppose I should start keeping a list of adopters.

[13:44:02 CDT(-0500)] <serac> And culling stuff that is not used.

[13:44:20 CDT(-0500)] <serac> As long as it's balanced, this seems healthy.

[13:46:41 CDT(-0500)] <apetro> Sounds like I should get it integrated in a github fork and see how people feel about the result.

[13:46:49 CDT(-0500)] <serac> +1

[13:46:57 CDT(-0500)] <battags> that seems reasonable

[13:47:39 CDT(-0500)] <battags> I'm still not convinced on the security issue but an integrated piece is easier to evaluate

[13:47:43 CDT(-0500)] <apetro> Other: bearing in mind that I haven't actually looked into this: know offhand what it would look like to get to a "supported" version of OpenSAML?

[13:47:58 CDT(-0500)] <serac> We absolutely should do that.

[13:48:19 CDT(-0500)] <apetro> Not looking to think about revving the SAML functionality in CAS in any way, just upgrade the OpenSAML dependency.

[13:48:19 CDT(-0500)] <serac> We should be using the 1.1 support in opensaml 2.x.

[13:48:32 CDT(-0500)] <apetro> k

[13:48:50 CDT(-0500)] <apetro> any idea how hard that is?

[13:49:04 CDT(-0500)] <serac> IIRC Scott said the usage patterns were really ugly, but it sounded doable.

[13:49:12 CDT(-0500)] <serac> He'd have to estimate.

[13:49:19 CDT(-0500)] <apetro> alright

[13:49:29 CDT(-0500)] <apetro> that much seems worth thinking about towards 3.5

[13:49:34 CDT(-0500)] <serac> +1

[13:49:34 CDT(-0500)] <battags> so the APIs are not at all compatible

[13:49:38 CDT(-0500)] <apetro> under the general theme of revving dependencies

[13:50:21 CDT(-0500)] <battags> I can take a look at effort

[13:51:56 CDT(-0500)] <apetro> k.

[13:52:21 CDT(-0500)] <serac> Sounds good.

[13:52:24 CDT(-0500)] <serac> On similar note.

[13:52:34 CDT(-0500)] <serac> We should target upgrading webflows to Spring EL for 3.5.

[13:52:41 CDT(-0500)] <serac> Will produce much more readable flows.

[13:53:17 CDT(-0500)] <apetro> k

[13:53:18 CDT(-0500)] <serac> May be pain for deployers like us with complex flow customizations, but now is a good time.

[13:53:25 CDT(-0500)] <apetro> I'm tempted to create JIRA issues to capture these fine ideas.

[13:53:34 CDT(-0500)] <serac> Do it.

[13:53:49 CDT(-0500)] <serac> I was gonna do the Spring EL one anyway.

[13:55:07 CDT(-0500)] <apetro> Spring EL: https://issues.jasig.org/browse/CAS-1053

[13:56:21 CDT(-0500)] <serac> Thanks.

[13:56:57 CDT(-0500)] <apetro> OpenSAML dependency: https://issues.jasig.org/browse/CAS-1054

[13:57:16 CDT(-0500)] <apetro> anything else?

[13:57:19 CDT(-0500)] <serac> "shiny and new"

[13:57:20 CDT(-0500)] <serac> (wink)

[13:57:27 CDT(-0500)] <serac> Not that I can think of.

[13:58:10 CDT(-0500)] <apetro> plans to attend UnConference?

[13:58:33 CDT(-0500)] <serac> It's now looking unlikely for me for financial reasons.

[13:58:51 CDT(-0500)] <serac> Scott, you gonna make it?

[13:59:11 CDT(-0500)] <apetro> https://wiki.jasig.org/display/JCON/Fall+2011+Unconference+Participants

[13:59:50 CDT(-0500)] <apetro> serac , that's unfortunate. Starting to shape up to a few CAS-interested folks there.

[14:00:05 CDT(-0500)] <serac> I'm bummed.

[14:17:05 CDT(-0500)] <battags> I have to look into it. Financially I would be on my own for it

[14:17:13 CDT(-0500)] <battags> unless the ED has a slush fund

[14:17:15 CDT(-0500)] <battags> (wink)

[14:17:24 CDT(-0500)] <serac> Heh, it'd help me out too (wink)

[14:17:58 CDT(-0500)] <battags> @serac with regards to EL, we have some of that work done in cas4 branch (may not be directly convertable)

[14:18:11 CDT(-0500)] <serac> Sounds good.

[14:18:39 CDT(-0500)] <serac> Maybe I'm naive, but I expect it would be pretty straightforward conversion.

[14:18:43 CDT(-0500)] <battags> wait we keep saying 3.5. Did we decide on 3.5 vs. 4.0?

[14:18:55 CDT(-0500)] <battags> I thought we had said if we pull in some of the API changes it would be number 4 ?

[14:19:00 CDT(-0500)] <battags> or am I having memory lapse

[14:19:01 CDT(-0500)] <serac> Correct.

[14:19:17 CDT(-0500)] <serac> Seems reasonable for a 3.5 version, though.

[14:19:21 CDT(-0500)] <battags> if we just used code names this would be so much easier (wink)

[14:19:38 CDT(-0500)] <serac> We've definitely done a version number two-step here to make it confusion.

[14:37:15 CDT(-0500)] <foxnesn1> if i wanted to add a few url links to the /cas/login page which file would i edit?

[14:37:23 CDT(-0500)] <foxnesn1> i see the index.jsp but it has little in it

[14:38:18 CDT(-0500)] <serac> cas-server-webapp/WEB-INF/views/ui/default/casLoginView.jsp

[14:45:46 CDT(-0500)] <EricDalquist> serac: when you moved CAS3 to github did you do any authors translation?

[14:45:54 CDT(-0500)] <serac> Yes.

[14:46:09 CDT(-0500)] <serac> https://wiki.jasig.org/display/CAS/CAS+Developer+Listing

[14:46:30 CDT(-0500)] <EricDalquist> great, I'm going to compile one and stick it in SVN

[14:46:32 CDT(-0500)] <serac> I invited all devs to post their desired email address for use in the mapping.

[14:46:42 CDT(-0500)] <EricDalquist> so as other jasig projects can build on it if/as they move

[14:46:57 CDT(-0500)] <serac> Sounds good. We were such a short list it was easy.

[14:47:11 CDT(-0500)] <serac> Probably value in UP list.

[14:47:17 CDT(-0500)] <serac> So you're definitely moving to github?

[14:47:20 CDT(-0500)] <EricDalquist> yu[p

[14:47:28 CDT(-0500)] <serac> We absolutely love it.

[14:47:30 CDT(-0500)] <EricDalquist> I just need to do all the work of coordinating it

[14:47:33 CDT(-0500)] <serac> Already paid off.

[14:47:36 CDT(-0500)] <EricDalquist> yeah I'm using it for a lot of other work

[14:47:43 CDT(-0500)] <EricDalquist> it makes contributing to other projects SO much easier

[14:47:46 CDT(-0500)] <serac> Transition wasn't as bad as I had feared.

[14:47:51 CDT(-0500)] <serac> Indeed easier.

[15:09:05 CDT(-0500)] <foxnesn1> yay, got one of our web apps to work with the cas

[15:09:25 CDT(-0500)] <foxnesn1> of course just using the most generic user/pass

[15:09:35 CDT(-0500)] <foxnesn1> but now i need to hook the cas up to the AD

[15:09:55 CDT(-0500)] <foxnesn1> so that instead of looking for my premade login/pass it looks at the AD

[15:34:10 CDT(-0500)] <foxnesn1> do i have to add any depencies or anything to the pom.xml file if im setting cas up to link with AD?

[15:35:13 CDT(-0500)] <serac> Yes, cas-server-support-ldap module.

[15:35:18 CDT(-0500)] <serac> Using Maven War Overlay?

[15:35:36 CDT(-0500)] <foxnesn1> yup

[15:35:53 CDT(-0500)] <serac> Should be able to add that as a dependency and you've covered dependency-wise.

[15:38:29 CDT(-0500)] <foxnesn1> so i dont have to add a type or a scope to the dependency then?

[15:39:08 CDT(-0500)] <serac> runtime is fine

[15:52:35 CDT(-0500)] <foxnesn1> do the pool config properties go in the deployer xml as well?

[15:52:58 CDT(-0500)] <serac> They're pulled in some from some properties file.

[15:53:12 CDT(-0500)] <serac> You could add them to cas.properties – that's probably the path of least resistance.